"Seth Goodman" commented in reply to william(at)elan.net:> >
<snip>
There is nothing otherwise that stops MTA from doing this verification
after email has been received and if something is wrong then
attempting to bounce the email (especially since during session it
confirmed by means of SPF the bounce address and knows it to be good).
Its just that most MTAs right now don't look at the headers but this
may well change with introduction of email signatures.
The main thing preventing it from happening is the need to upgrade all MUA
software to do this test. I don't think that is terribly likely, since
there is no reason it needs to be done in the MUA. It's very different from
an S/MIME or PGP signature. Since there is no protocol for an MUA to
request a bounce for a message that already has been delivered to it (we
would be asking the MTA to "un-deliver" the message), even if the required
MUA software existed, how could the MUA initiate a bounce?. I don't think
it is a good idea to permit MUA's to compose and send null-sender messages,
as the abuse potential is incredibly high. Bounces are for non-delivery.
If the MUA already has the message it has been delivered. This is creating
a new class of delivery notification saying, "the message has been
delivered, but the end user doesn't want it". It's certainly outside the
scope of the RFC's, at least as far as I am aware.
Since this test is so easy to do in the MTA, why not do it there and prevent
the user from seeing the forgery in the first place? You can't have
phishing if the message is never delivered to the user's inbox. That would
require zero changes to MUA software, and thus be much more easily deployed.
Email signatures are going to happen, most likely, and MTA's will have to
look at headers, one way or the other.
<snip>
Architecturally, I've been opposed to having transport entities meddle with
contents.
However, I think there's an architecturally-sound way of thinking about this
issue...
Recognise that MTA functionality is about Transfer and MDA functionality is
about Delivery.
The host which holds the user's mail box offers an MTA interface to inbound
mail, but internally has MDA functions - storing mail to await collection by an
MUA (in the most common model).
I think it would be reasonable to argue that the MDA function can act as the
agent of the recipient user and has some sort of policy arrangement with that
user. It is thus reasonable that it may inspect the contents of the message and
decide to reject any phishing (or whatever) it discovers.
The MTA side of its personality can either indicate this rejection at the end of
DATA or subsequently initiate a bounce.
Therefore, architecturally, I would be content to see the end-point MTA+MDA do
this kind of content-related rejection, but not intermediate MTAs.
Chris Haynes