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.
http://members.cox.net/joejob/
mm