RE: [Asrg] Some data on the validity of MAIL FROM addresses

["Tom Thomson" <[e-mail]>]

> An IETF/IRTF working group mailing list is not like netnews or SPAM-L.
> It is not merely a forum for stating positions and exchanging views.
> It is a tool for generating and guaging consensus on technical issues.
> Regardless of heat, this mailing list must address the issue of whether
> filtering SHOULD (in the special meaning of RFC 2119) be done during
> the SMTP transaction.  If we can't reach consensus on such a fundamental
> and simple issue, then this mailing list is distinctly worse than useless.

That's true. Since filtering in some form is probably going to be some part
of any realistic solution we ought to be able to get a handle on how things
behave when a filter intervenes.

I don't think there's a simple answer.  I would like to base the answer
around the idea that some types of filtering can appropriately be treated as
being the same as the end-user discarding the mail from his inbox, while
others are more like the MTA being unable to deliver. But there's also the
question of not sending bounces to forged Mail_From addresses. Here are some
ideas:

We can consider 4 main cases.

1) the filter simply diverts mail into the users junk mail folder, or in
some wasy annotates it so that the MUA will show it as probable spam.  In
this case the MTA must not bounce and must not reject in the SMTP
transaction, since the mail is being delivered correctly.

2) the filter discards mail based on content (including content headers) and
not solely on the envelope. There are a couple of subcases here:
(a) the end-user (envelope recipient) has expressed a desire not to receive
this mail: in this case I can't see that it's any different (so far as the
sender is concerned) from the end user noticing it in his inbox and deleting
it.  The MTA should not reject during the SMTP transaction and should not
generate a bounce.
(b) this is nothing to do with the end user, it's MTA policy - so the mail
was undeliverable by this MTAs rules. Here I think the MTA should generate a
bounce but may reject the mail in the SMTP transaction if the sender is
pipelining - sending the data before knowing whether there is an error.

3) the filter discards mail based on the smtp envelope only. Since the end
user doesn't see the envelope, only the content, there's no way an end user
could base a decision to delete mail from his inbox based on the envelope -
the mail is undeliverable, and the MTA must say so. This should be done
using an error response within the smtp transaction. If the sender is
pipelining and has closed the connection before an error can be raised, a
bounce may be generated.

4) This consideration overrides 2 and 3 above: Because we don't live in an
ideal world, bounce messages may be bad news.  An MTA which can detect
envelope forgery (using RMX or Cryptographic Authentication or HELO domain
non-existence forward Received-From: chain verification or whatever other
future or existing it may have) and discards a message which it knows to be
forged MUST NOT generate a bounce.

Tom

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg