[Cadre-politics] forward: note re SMTP connection rejection

[Dan MacNeil]

Thanks for the thoughts and the prod to our thoughts.

We've been running postgrey for a little while now, It works really well.

 > greylisting). Explaining the inbound delay issue versus the benefits
 > of greylisting (dramatic decrease in spam) requires marketing (or at
 > least proactively "selling" the solution to your users before
 > implementing it).

For those too lazy to follow the link, greylisting means your smtp 
(email) server says: "try again in 5 minutes" to everyone the first time 
  it sees an email from them. Zombies don't follow the rules, regular 
email servers do and try again in five minutes. If our smtp server has 
seen your email address before, it lets the message through w/o delay.

When we started we got a lot of complaints from compulsive social worker 
types that their mail was taking 5 to 15 minutes to reach co-workers 
when it used to get through instantly. We kept telling them it would get 
better as soon as their correspondents were in the whitelist. Things got 
better and they stopped bugging us.

Hindsight being 20/20 we should have run postgrey in "learning mode" 
first. In learning mode it builds the whitelist w/o imposing the delays.

We do have two problems with greylisting.

Sometimes email clients connect directly to our smtp server (for webmail 
and inside the lab). The client (thunderbird, icedove, etc)  can't 
handle the temporary failure.  --The solution is probably dedicated 
outgoing SMTP (auth) server.

Some mailing lists track "soft bounces" or "temporary failures" When 2-3 
  messages are greylisted. They assume there is a problem with your 
email address and suspend your list membership until they can get a 
probe email through to you.

Thanks again for making us think of these things again.

Stéphane Alnet wrote:
 >> Below is a strong argument for rejecting mail at SMTP time, not
 >> accepting the message in the first place. The problem (as Craig Sanders
 >> points out in a different thread on debian-isp) is that we lose the
 >> ability to queue.
 >
 > One option that cuts down on spam at the SMTP level without requiring
 > much processing power is greylisting. Postgrey[1] is a good
 > implementation if you are using postfix. Greylisting is basically
 > targetted at disrupting email bots but keep regular, SMTP-compliant
 > MTAs happy. One can combine greylisting with further (existing) spam
 > control in the back as usual.
 >
 > [1] http://isg.ee.ethz.ch/tools/postgrey/
 >
 > One argument _against_ greylisting that was given to me by an ISP
 > friend (and given that CSL is an ASP I think this could be a valid
 > concern) is that emails get delayed significantly the first time a
 > legitimate, external sender emails a given recipient (using
 > greylisting). Explaining the inbound delay issue versus the benefits
 > of greylisting (dramatic decrease in spam) requires marketing (or at
 > least proactively "selling" the solution to your users before
 > implementing it).
 >
 > Just a thought,
 > Stéphane
 >