[Mimedefang] Re: Justifying greylisting to management

Tomasz Ostrowski tometzky at batory.org.pl
Fri Mar 3 04:57:27 EST 2006

On Fri, 03 Mar 2006, Tomasz Ostrowski wrote:

> I'm going to send a feature request to
> <sendmail-YYYY at support.sendmail.org>.

----- Forwarded message -----

From: Tomasz Ostrowski <tometzky at batory.org.pl>
Subject: RFE: Tempfail "data" when at least one "rcpt to" tempfailed and none accepted
To: sendmail-YYYY at support.sendmail.org
Date: Fri, 3 Mar 2006 10:51:52 +0100

I'd like to ask for considering my proposal - that "data" requests
would be temporarily rejected (4xx) instead of permanently rejected,
when at least one "rcpt to" request was temporarily rejected and no
"rcpt to" request was accepted.

The developer or MIMEdefang milter (http://www.mimedefang.org/),
"David F. Skoll" <dfs<at>roaringpenguin.com> said on its mailing list
that it has implemented greylisting in a way that tempfails after
"data", not after "rcpt to" command.

The reasoning was:

| Now, there *are* some marginal SMTP servers that fail in the
| following scenario:
| C: HELO myname.domain.com
| S: 250 whatever
| C: MAIL FROM:<foo at domain.com>
| S: 250 2.1.0 go ahead
| C: RCPT TO:<recipient at domain.com>
| S: 451 4.7.1 greylisting; try in 2 minutes
| S: 503 5.0.0 need RCPT!
| (and client bounces message)
| Notice that?  Some marginal clients attempt a DATA even if all
| RCPTs are 4xx'd.  Our solution is to greylist after the DATA phase
| (that is, at the ".") While this wastes bandwidth, it does keep
| those marginal SMTP implementations from failing.

I said that:

| This could be avoided if sendmail would tempfail "data" requests if
| any "rcpt to" request tempfailed and every "rcpt to" request
| tempfailed or permfailed.

David did not like this, because:

1. Sendmail has a right to reject after data phase, because RFC
states, that at least one recipient must be accepted when a client
sends "data". I agree, but it also has a right to tempfail.

2. Sendmail can assume that if a client has broken implementation
which caused this failure, then every subsequent attempts will also
fail, so there's no reason to tempfail. I do not agree - if
there's temporary failure then it should be assumed that the
conditions can change and next time there'll be no reason to
tempfail. If commands are "repeated identically" then they can be
successful, hence proposed 4xx response.

...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
                                                      Winnie the Pooh

----- End forwarded message -----

More information about the MIMEDefang mailing list