[RndTbl] Shaw dropping on greylist?
Gilbert E. Detillieux
gedetil at cs.umanitoba.ca
Fri Jan 29 11:52:00 CST 2010
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. :)
--
Gilbert E. Detillieux E-mail: <gedetil at muug.mb.ca>
Manitoba UNIX User Group Web: http://www.muug.mb.ca/
PO Box 130 St-Boniface Phone: (204)474-8161
Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609
More information about the Roundtable
mailing list