Re: Exim: Different mail retry times depending upon response from remote host...
On Thu, Jan 29, 2004 at 10:58:19AM -0800, Joe Emenaker wrote:
> >why should there be?
> > [...]
>
> Because, like you mentioned later in your message, not all mailers give
> proper responses. For example, I've see a lot of 5xx codes where the verbal
> explanation is that the user is over quota.
well, that's normal (at least, it is not "wrong" to do that). what to do in an
excess-quota situation is a local policy decision. some sites choose 5xx, some
choose 4xx.
> But the *real* problem, I guess, is that I'm seeing so many 5xx's in
> /var/spool/exim/msglog at *all*.
you shouldn't be seeing *ANY* 5xxs in the spool at all. 5xx specifically means
"DO NOT TRY AGAIN". exim should not ever retry delivery on permanent-failure
codes (unless there is some debugging option like postfix's soft_bounce in
effect).
> If the sender address is bogus, the bounce notification just hangs around
> forever, it seems. I'd like to be able to give bounce notifications avout 4
> hours to be delivered and then, buh'bye.
ah, ok. that's a different problem entirely. that's not retrying a 5xx,
that's inability to deliver a bounce.
you need to configure exim to REJECT mail sent to non-existent addresses (or
which fail your anti-spam/anti-virus etc rules) immediately, rather than
accept-and-bounce. that way it is the sending MTA's responsibility to deal
with the problem, rather than yours.
e.g. if a message comes in for nosuchuser@your.domain, don't accept it then
find out that the user doesn't exist, and then bounce it. it is far better to
just reject it during the smtp session with a "550 No such user" response.
that way, the bounce is not your responsibility. The sending MTA is
responsible for dealing with errors. if the sending "MTA" is a virus, then it
probably does nothing - AFAIK, no viruses have bounce-handling code....but it
really doesn't matter what the sending MTA is or what it does, the key point is
that it is *NOT YOUR PROBLEM*, you have not accepted the mail and have not
accepted responsibility for delivering-or-bouncing it.
if you can't reject during the smtp session, then your best option is to
tag-and-deliver (best for spam) or just discard (best for viruses).
IIRC, exim *can* do any or all of these things, depending on how you configure
it. probably some exim expert here can tell you how to do it.
btw, AFAIK, exim doesn't have any option to specify a different retry period
for bounce-messages. that would be a useful feature for dealing with spam and
viruses that get through the filters.
on my own systems, i have inbound MX boxes and outbound mail relays. the
inbound MXs do all the spam & virus filtering, and forward the mail to the
POP/IMAP box. they have a retry period of 1 day. it is set so low to avoid
the queue getting clogged with undeliverable spam bounces (stuff which makes it
through my access maps, but gets caught by amavisd-new/spamassassin/clamav).
the outbound relays are for users to send their mail, and they have a retry
period of 5 days.
> >these sound like 5xx errors, rather than 4xx. exim should be bouncing
> >these, if the remote systems are issuing the correct error codes. if they
> >aren't, there's little you can do about it.
>
> Except write a script, I guess. :)
you're better off not letting these bounce messages get into the queue in the
first place (i.e. "prevention is better than cure"). you don't want them, they
just slow down your machine....reject unwanted mail with 5xx during the SMTP
session wherever possible.
> >one possibility is that there is some error in your configuration which is
> >making permanent errors be treated as temporary (4xx) errors,
>
> Well, I haven't tweaked our config too much... BUT.... it's the config
> file from when we switched to Exim about 4 years ago, and I haven't
> allowed Debian to overwrite it with a new one (lest we lose our mods to
> the config file).
> So, it might be time to get a new config file and move our changes over by
> hand. But... if we're going through that much trouble.... geez... I'd just
> switch to Courier.
why switch to courier-mta when you can switch to postfix? :-)
courier's other tools (maildrop, pop, sqwebmail, etc) work fine with postfix as
the MTA.
courier makes a very nice delivery system for real & virtual users. postfix
makes a very nice MTA (better than anything else, including courier-mta). the
combination works extremely well.
craig
Reply to: