[Top] [All Lists]

Re: Sieve reject at SMTP time possible with which implementations?

2003-10-31 20:13:37

Thanks, Mark, Nigel for comments, and Kjetil for a template (though I'll probably use RFC3285's, which I just became aware of). Alexey and I plan to co-author the I-D.

On 10/31/2003 10:06 AM, Mark E. Mallett sent forth electrons to convey:

On Fri, Oct 31, 2003 at 05:30:37PM -0000, Nigel Swinson wrote:
The problem with filtering before storing in the end users mailbox is as Ned
says, the concept of the mail envelope.  At the SMTP level, the envelope
probably has many recipients,
s/probably/very occasionally/, so it's not as much of an issue. I think a 'refuse' that works perfectly as long as there aren't multiple *envelope* recipients (which, keep in mind, is much rarer than multiple recipients of any kind) ( and handles the special case by causing an MDN to be sent on behalf of the rejecting recipients) is much better than no 'refuse' at all.

A LONG and often technical discussion of issues you needn't read if you're not comfortable with the above: In my proto-draft (security section), I suggest this be handled as follows: "Sieve evaluation as typically implemented requires having the entire message on hand. In SMTP this means the only response code that's left is the final one, where the server accepts or rejects the message on behalf of all recipients. This becomes a problem when there are multiple recipients and some reject the message and some do not. In this case, reject MUST cause an MDN to be sent on behalf of the rejecting recipients. (Idea: allow MTA to tempfail the rejecting recipients and accept the others, until all recipients are rejecting the email; then it can be refused.)" [I now reject that latter idea:] Is the additional complexity introduced by specifying how the tempfail would work to make SMTP rejects work even in the relatively rare case of multiple recipients on the envelope really worth it? Making this mandatory would make the implementation of this spec considerably more work, I think. I don't want to make it optional, I'd rather leave it out than make it optional. (By the way, tempfail means to send a 4xx SMTP response code) It would work as follows: when there are multiple recipients and some reject the message and some do not, a tempfail response code is sent. The recipient server has to maintain state about the message so it can recognize it when (if) delivery is reattempted. (some spamware never reattempts delivery!) When delivery is reattempted, the rejecting recipients are tempfailed, but the others aren't. (This is perfectly acceptable, per RFC2821.) When the third delivery attempt is made, the previously rejecting recipients are not tempfailed and (assuming) all the recipients in this delivery are confirmed to be rejecting recipients, the whole email can be permanently refused. (Unfortunately, some spamware reattempts delivery even after permanent failures!) I'd be surprised if a spec requiring this would be broadly implemented, even though I think it would reliably provide the desired result. I don't want to write a Standards Track document that never gets past the I-D stage!

so who's configuration do you use?  It's only
when you are about to put a message in a users INBOX will you know that you
can take action on behalf of all the recipients (cos there is only one).
Hence when MailSite rejects a message at the SMTP level it is using a global
server level script.
(And technically violating the RFC - but I'm NOT complaining about that! - it's effectively crying out for this extension.)

Yeah- what one would need to do is do an attempted delivery for
each SMTP "mail to" recipient and deal with rejections based on
that attempt.  You would have to have access to each individual's
filter program to do this.  Furthermore you would need something
other than SMTP, since once you have said "OK" to the "mail to"
you can't take it back later.
No.  Actually RFC2821 specifies when the server takes responsibility:
"In sending a positive completion reply to the end of data indication, the receiver takes

  full responsibility for the message (see section 6.1).'
Until then, the server can drop the message and connection and be RFC 
compliant, even if it has said OK to all the recipients.
Also there is no such thing as a "mail to" command; I assume you mean 'rcpt to'.

 Or you would have to have a way
of enforcing only one recipient per SMTP session.  (accepting
the first "mail to" and giving 4xx responses for each subsequent
one would be very hackish.)
I would be open to something like: an implementation MAY tempfail recipients after the first one to facilitate per-user 'refuse' actions. An implementation could, for example choose to do this for mail from any blacklisted IPs, and safely do so even using aggressive blacklists that list IPs that send both ham and spam. It's not clear whether this would violate any RFCs. RFC 2821 does not allow "Rejection of messages (for excessive recipients)" < 100 but a 450 rejection of that sender because the mailbox is unavailable for policy reasons seems acceptable to my reading.

Here it would be great to have an SMTP
enhancement allowing post-DATA rejections.
SMTP already allows this. It's clearly permitted by RFC 2821 to send a negative completion reply to the end of data indication. Were it not, this I-D would be a non-starter!

A comment on your I-Draft.  I've never heard of "joe-job spam".  Now I know
I only code mail servers, not use them, so perhaps I'm just ignorant, but
I'm wondering if "joe-job spam" is a well established enough term to be
using without describing what it means?  I see you do describe it
eventually, but wonder if you can avoid the term completly in the I-Draft.

JoeJob is a very common term referring to forging somebody else's
address as a return address, so that unfortunate victim gets bounces.
It's a googlable term.
I'll be sure that it's clear if we use it.