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 [EMAIL PROTECTED], 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]