Re: Exim: Different mail retry times depending upon response from remote host...
On Fri, 30 Jan 2004 05:58, Joe Emenaker <[EMAIL PROTECTED]> wrote: > 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. 5xx is the correct thing to do when the quota is exceeded. Some ISPs I know of have customers who remain over quota for YEARS! If the customer keeps paying their bills then the ISP administrators can not delete the messages that cause the quota to be exceeded or remove the account. As there is little chance of the situation changing the only thing to do is to send a 5xx. If you have an over-quota situation that is likely to be fixed in a short period of time then you probably have a bigger problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Exim: Different mail retry times depending upon response from remote host...
On Fri, 30 Jan 2004 05:58, Joe Emenaker <[EMAIL PROTECTED]> wrote: > 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. 5xx is the correct thing to do when the quota is exceeded. Some ISPs I know of have customers who remain over quota for YEARS! If the customer keeps paying their bills then the ISP administrators can not delete the messages that cause the quota to be exceeded or remove the account. As there is little chance of the situation changing the only thing to do is to send a 5xx. If you have an over-quota situation that is likely to be fixed in a short period of time then you probably have a bigger problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 [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 codebut 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 machinereject 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
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 [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 codebut 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 machinereject 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]
Re: Exim: Different mail retry times depending upon response from remote host...
Craig Sanders wrote: On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. 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. But the *real* problem, I guess, is that I'm seeing so many 5xx's in /var/spool/exim/msglog at *all*. 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. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. 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. :) 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. - Joe
Re: Exim: Different mail retry times depending upon response from remote host...
Craig Sanders wrote: On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. 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. But the *real* problem, I guess, is that I'm seeing so many 5xx's in /var/spool/exim/msglog at *all*. 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. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. 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. :) 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. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Exim: Different mail retry times depending upon response from remote host...
On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: > You don't have to be a rocket scientist to realize that the following > remote mailer messages give varying degrees of optimism regarding future > delivery: > >550 Requested action not taken: mailbox unavailable >452 Mailbox full >452 Insufficient disk space; try again later >421 Too many concurrent SMTP connections; please try again later. > > With the first, you're pretty sure that the problem is *not* going to be > corrected in the next few days. Meanwhile, the others give you some hope > in waiting. > > Unfortunately, I haven't seen anything in Exim that lets you customize > it's retry behavior based upon this. It does offer an "error" field in > the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. > So, I wrote a little script that goes through all of the msglog files and > finds good candidates to toss (ie, "No such user", "Account Terminated", > etc.). With just a day's worth of tweaking the script, I've managed to get > the pending queue down to about 1/3 of what it was. 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. one possibility is that there is some error in your configuration which is making permanent errors be treated as temporary (4xx) errors, similar to postfix's "soft_bounce" feature...a useful feature while testing and debugging, but not what you want for normal use. i don't know what this option is called in exim (it's been a few years since i did much with it). > But I figured I'd ask... does anybody already have a script for doing this > (or maybe a better way altogether, since this script has to be explicitly run > periodically)? it shouldn't be necessary. craig
Re: Exim: Different mail retry times depending upon response from remote host...
On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: > You don't have to be a rocket scientist to realize that the following > remote mailer messages give varying degrees of optimism regarding future > delivery: > >550 Requested action not taken: mailbox unavailable >452 Mailbox full >452 Insufficient disk space; try again later >421 Too many concurrent SMTP connections; please try again later. > > With the first, you're pretty sure that the problem is *not* going to be > corrected in the next few days. Meanwhile, the others give you some hope > in waiting. > > Unfortunately, I haven't seen anything in Exim that lets you customize > it's retry behavior based upon this. It does offer an "error" field in > the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. > So, I wrote a little script that goes through all of the msglog files and > finds good candidates to toss (ie, "No such user", "Account Terminated", > etc.). With just a day's worth of tweaking the script, I've managed to get > the pending queue down to about 1/3 of what it was. 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. one possibility is that there is some error in your configuration which is making permanent errors be treated as temporary (4xx) errors, similar to postfix's "soft_bounce" feature...a useful feature while testing and debugging, but not what you want for normal use. i don't know what this option is called in exim (it's been a few years since i did much with it). > But I figured I'd ask... does anybody already have a script for doing this > (or maybe a better way altogether, since this script has to be explicitly run > periodically)? it shouldn't be necessary. craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Exim: Different mail retry times depending upon response from remote host...
You don't have to be a rocket scientist to realize that the following remote mailer messages give varying degrees of optimism regarding future delivery: 550 Requested action not taken: mailbox unavailable 452 Mailbox full 452 Insufficient disk space; try again later 421 Too many concurrent SMTP connections; please try again later. With the first, you're pretty sure that the problem is *not* going to be corrected in the next few days. Meanwhile, the others give you some hope in waiting. Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. But I figured I'd ask... does anybody already have a script for doing this (or maybe a better way altogether, since this script has to be explicitly run periodically)? - Joe
Exim: Different mail retry times depending upon response from remote host...
You don't have to be a rocket scientist to realize that the following remote mailer messages give varying degrees of optimism regarding future delivery: 550 Requested action not taken: mailbox unavailable 452 Mailbox full 452 Insufficient disk space; try again later 421 Too many concurrent SMTP connections; please try again later. With the first, you're pretty sure that the problem is *not* going to be corrected in the next few days. Meanwhile, the others give you some hope in waiting. Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. But I figured I'd ask... does anybody already have a script for doing this (or maybe a better way altogether, since this script has to be explicitly run periodically)? - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
