On Wed, 2005-09-21 at 22:25 -0400, Theo Schlossnagle wrote:
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.
And if you could reject it on the basis of its reverse-path and/or
recipients, X-ADAT means you did all that work, and used all that
bandwidth, for nothing. Content scanning is _expensive_ and personally I
_want_ to do it last, after I've tried everything else which might let
me reject the mail. I certainly don't want to end up content-scanning
mail which then turns out to have been addressed to an unknown user.
It's a PITA dealing with per-recipient content policy, but it's not
entirely clear that X-ADAT is the answer even in the general case --
even assuming that the virus engines and spambots are going to adopt it
in their desire to be helpful to content-filtering servers.
Multi-recipient mails where the content fails some but not all
recipients' policies is very much the exception rather than the rule.
It's generally sufficient just to give a 4xx rejection after DATA if
that turns out to be the case (much like greylisting) and then enforce
separate recipients when it's retried by giving 4xx to the second and
subsequent RCPT TO.
But yeah, accept-and-bounce is easier than that, and would probably
happen fairly rarely.
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.
I'm not sure about 'absolutely necessary' but certainly there are corner
cases there it's just too much of a PITA to avoid it. Phrase it like
that and I'd agree with what you say.
My systems may accept-and-bounce in the case where they're acting as
backup MX for a primary which is down, for example. They check recipient
addresses by SMTP callouts, which obviously doesn't work if the primary
is actually not responding. But it's far from the common case, so I
choose to accept the possibility. It would be too complicated to attempt
to synchronise user lists in any other way with certain domains for
which I provide MX backup. I wouldn't say that this behaviour is
"absolutely necessary", but I certainly can't be bothered to fix it.
--
dwmw2
-------
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