[RndTbl] Shaw dropping on greylist?

[Gilbert E. Detillieux]

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