I have an apparent greylisting issue with Shaw. I wonder if anyone else has noticed this. Shaw's mail server appears to only try either a few times or for a limited amount of time and then give up. I get lots of logs like the following (names have been changed to protect the guilty). After that, no further hits from that from address.
I had my greylisting time set to 29mins, but have now changed it to 15mins to try to get within the Shaw window.
Anyone else with a >16 min greylist delay might want to check their logs for similar behaviour, and/or take reports of missing emails more seriously. Please report back if you see similar behaviour.
Thanks!
Jan 20 17:51:35 pog milter-greylist: o0KNpZhm012547: addr idcmail-mo2no.shaw.ca[64.59.134.9] from bobo@clown.com to me@mine.com delayed for 00:29:00 Jan 20 17:51:35 pog sendmail[12547]: o0KNpZhm012547: from=bobo@clown.com, size=5720, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=idcmail-mo2no.shaw.ca [64.59.134.9] Jan 20 17:52:37 pog milter-greylist: o0KNqbE4012577: addr idcmail-mo2no.shaw.ca[64.59.134.9] from bobo@clown.com to me@mine.com delayed for 00:27:58 Jan 20 17:52:37 pog sendmail[12577]: o0KNqbE4012577: from=bobo@clown.com, size=5720, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=idcmail-mo2no.shaw.ca [64.59.134.9] Jan 20 17:54:41 pog milter-greylist: o0KNsfrZ012640: addr idcmail-mo2no.shaw.ca[64.59.134.9] from bobo@clown.com to me@mine.com delayed for 00:25:54 Jan 20 17:54:41 pog sendmail[12640]: o0KNsfrZ012640: from=bobo@clown.com, size=5720, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=idcmail-mo2no.shaw.ca [64.59.134.9] Jan 20 18:00:54 pog milter-greylist: o0L00sXO012857: addr idcmail-mo2no.shaw.ca[64.59.134.9] from bobo@clown.com to me@mine.com delayed for 00:19:41 Jan 20 18:00:54 pog sendmail[12857]: o0L00sXO012857: from=bobo@clown.com, size=5720, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=idcmail-mo2no.shaw.ca [64.59.134.9] Jan 20 18:06:36 pog milter-greylist: o0L06ahf013092: addr idcmail-mo2no.shaw.ca[64.59.134.9] from bobo@clown.com to me@mine.com delayed for 00:13:59 Jan 20 18:06:36 pog sendmail[13092]: o0L06ahf013092: from=bobo@clown.com, size=5720, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=idcmail-mo2no.shaw.ca [64.59.134.9]
A 29 minute grey list!? Are the people using this server really ok with a minimum 30 minute delay in getting their mail?
Given that mail zombie's usually only try once for each email address, I have mine set to 30 seconds.
Granted, the bots are getting more sophisticated and sometimes try more often but it's still effective.
On 2010-Jan-29 09:13, John Lange wrote:
A 29 minute grey list!? Are the people using this server really ok with a minimum 30 minute delay in getting their mail?
I had my personal mail server set to 2hrs in the very recent past, but with reasonably extensive whitelisting.
Given that mail zombie's usually only try once for each email address, I have mine set to 30 seconds.
Granted, the bots are getting more sophisticated and sometimes try more often but it's still effective.
Switched to postgrey, which had a default of 5 minutes, and noticed that such a short delay was permitting an awful lot of spam. Boosted it to 10 minutes, which cut things back down again (in combination with policyd-weighted, anyway).
Considering that e-mail was never meant to be near-real-time in the first place... it wasn't so long ago that sendmail's default operation mode was queued-only on a 30-minute (or longer!) interval from cron.
Heck, it wasn't even all that long ago that I got mail whenever I connected to my ISP and did an ETRN, twice a day.
So a 30-minute delay in receiving mail seems perfectly fine to me. Plus, I would MUCH RATHER people believe that e-mail does NOT reach me immediately; the expectation of immediate delivery - implying immediate action, immediate comprehension and immediate reply - has been shown in multiple studies to destroy worker productivity.
-Adam
On 2010-01-29 10:59, Adam Thompson wrote:
On 2010-Jan-29 09:13, John Lange wrote:
A 29 minute grey list!? Are the people using this server really ok with a minimum 30 minute delay in getting their mail?
I had my personal mail server set to 2hrs in the very recent past, but with reasonably extensive whitelisting.
I for one welcome a return to delayed e-mail delivery!... ;)
Given that mail zombie's usually only try once for each email address, I have mine set to 30 seconds.
Granted, the bots are getting more sophisticated and sometimes try more often but it's still effective.
Switched to postgrey, which had a default of 5 minutes, and noticed that such a short delay was permitting an awful lot of spam. Boosted it to 10 minutes, which cut things back down again (in combination with policyd-weighted, anyway).
Considering that e-mail was never meant to be near-real-time in the first place... it wasn't so long ago that sendmail's default operation mode was queued-only on a 30-minute (or longer!) interval from cron.
I'm not sure what's typical these days, but I would assume 15 minutes or so would be a fairly common retry interval. That's why I set my greylisting delay on the CompSci mail server to 14 minutes. (And that's with a default whitelist policy, so it only affects particular addresses which are more likely to be spam senders or recipients.)
On the MUUG server, I caved to pressure from some mailing list subscribers, and reduced the delay to 4 minutes (i.e. just under the 5 minute retry interval of some more aggressive mail servers). This seems to be working reasonably well.
I've found that some spambots don't retry at all, in which case even a small delay is sufficient; some seem to retry quite persistently, in which case even a larger delay won't help. However, there is a 3rd type, which will retry for a short while before giving up. (We see these in our logs with a retry interval of a minute or less sometimes.) It's for that 3rd type that the retry delay will be more critical. In any case, I wouldn't see any need for a delay of more than 14 minutes.
Heck, it wasn't even all that long ago that I got mail whenever I connected to my ISP and did an ETRN, twice a day.
So a 30-minute delay in receiving mail seems perfectly fine to me. Plus, I would MUCH RATHER people believe that e-mail does NOT reach me immediately; the expectation of immediate delivery - implying immediate action, immediate comprehension and immediate reply - has been shown in multiple studies to destroy worker productivity.
A valid point, but I don't think I'd want to use greylisting delays to try and enforce this sort of productivity enhancement. :)
On Fri, 2010-01-29 at 10:59 -0600, Adam Thompson wrote:
Considering that e-mail was never meant to be near-real-time in the first place... it wasn't so long ago that sendmail's default operation mode was queued-only on a 30-minute (or longer!) interval from cron.
Heck, it wasn't even all that long ago that I got mail whenever I connected to my ISP and did an ETRN, twice a day.
So a 30-minute delay in receiving mail seems perfectly fine to me. Plus, I would MUCH RATHER people believe that e-mail does NOT reach me immediately; the expectation of immediate delivery - implying immediate action, immediate comprehension and immediate reply - has been shown in multiple studies to destroy worker productivity.
All perfectly logical; Next time a client calls complaining mail delivery is slow, I'll be sure to say:
"Stop complaining! Heck, it wasn't so long ago that sendmail's default operation mode was queued-only on a 30-minute (or longer!) interval from cron!"
That'll shut them up ;) heh.
In all seriousness, _lots_ of clients have mail forwarded to mobile devices and they expect delivery to be nearly instantaneous. A 30+ minutes delay would never fly.
It also tends to make troubleshooting mail delivery very difficult. (Tech in the field sends test email to client account, has to wait up to an hour to confirm if it's working or not).
On 2010-01-28 18:56, Trevor Cordes wrote:
I have an apparent greylisting issue with Shaw. I wonder if anyone else has noticed this. Shaw's mail server appears to only try either a few times or for a limited amount of time and then give up. I get lots of logs like the following (names have been changed to protect the guilty). After that, no further hits from that from address.
I had my greylisting time set to 29mins, but have now changed it to 15mins to try to get within the Shaw window.
Anyone else with a >16 min greylist delay might want to check their logs for similar behaviour, and/or take reports of missing emails more seriously. Please report back if you see similar behaviour.
As I pointed out in another posting, I've got a maximum delay of 14 minutes on one mail server, and less elsewhere. I don't see much to be gained with a larger delay than that.
I'm not sure this is relevant to your problem, but we've seen another issue with greylisting, e.g. in trying to accept mail from gmail.com servers. The problem there is that they don't necessarily (or even typically) retry from the same client IP address, so auto-whitelisting doesn't help, and you're almost always telling them to come back again later. We've had to whitelist entire IP ranges for gmail to get around this problem.
In any case, there are a lot of "legit" mail servers out there that don't seem to handle greylisting well, which is why the default configuration with milter-greylist comes with a whole list of "broken mta" address ranges to whitelist. Perhaps you'll just need to do the same for Shaw?
-
Adam Thompson -
Gilbert E. Detillieux -
John Lange -
Trevor Cordes