spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Anyone Got an Explanation?

2005-09-21 19:26:38

On Sep 21, 2005, at 7:10 PM, David Woodhouse wrote:

On Wed, 2005-09-21 at 16:47 -0400, Dick St.Peters wrote:

DSN generation is an MTA function.  You're right that what the Clamav
milter calls a bounce is actually a reply, but it has little choice.
As a milter, it can return a status telling sendmail to accept or
reject the mail, but there's no "accept and bounce" status defined in
the milter API. If a milter returns a reject status, sendmail rejects
the mail, leaving DSN generation up to the client MTA (which in the
case of a Clamav milter reject is often a virus SMTP engine).


Yes, and that's absolutely how it _should_ be. You should never
accept-and-bounce; you should reject at SMTP time. If it's a legitimate
sender with a false positive, they'll get a DSN. If it's a virus SMTP
engine, it'll just move on to its next victim.

Multi-recipient mail is an exception here. If I send a complaint mail that violates corporate policy to abuse(_at_)domain and user(_at_)domain, then I can't reject it at SMTP time (abuse wants it) and I can't not generate an MDN as I had given user(_at_)domain a 250 during RCPT TO and had to 250 the body to deliver it to abuse(_at_)(_dot_) Since I accepted it, and did _not_ send it to user(_at_)domain as I had promised, I must generate an MDN or the sender will be very very confused.

X-ADAT solves this, but no mail servers seem to support it :-(

Now consider a 600MB avi file as an attachment (which perfectly legal) and the content analysis takes 20 minutes to run on it, I can't keep the remote MTA on the line without timing out. So X-ADAT doesn't even solve that scenario.

It _does_ have a choice. It can do the right thing, and either reject or
accept the mail. The fact that it has to go out of its way to do the
_wrong_ thing (accept-and-bounce) ought to have been a fairly good
hint :)

Accept and bounce should be avoided (and in the _vast_ majority of cases it car), but there are cases where it is absolutely necessary.


// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com