Problem statement
------------------
A shared MTA has to be trusted to have ensured that the sender is authorised to
use the Mail-From address. There is no indication in the SMTP protocol, or in
the message headers, that this verification is actually taking place on a
message-by-message basis.
Mis-configurations, operational errors, changes in policy, etc., could mean that
the tests at the shared MTA have temporarilly ceased, yet the node is still
being trusted.
Senders who have declared their trust in the MTA by listing it with a '+' may
have their trust betrayed; under these abnormal conditions the MTA may permit
other users of the shared MTA to forge the mail-from address.
This should be of particular concern to those senders who use a shared outbound
MTA not under their administrative control (e.g. customers of most ISPs).
New keyword
--------------
We define an SMTP service extension which uses the keyword "VERIFIED"
When an MTA is offering a verified message to a receiver which supports VERFIED,
it MUST include the parameterless keyword VERIFIED in the MAIL FROM command.
Example: MAIL FROM: fred(_at_)example(_dot_)com VERIFIED
Actions by sending MTA
------------------------
To verify the mail-from address the sending MTA MUST perform at least one of the
following two tests:
1) It MAY verify the mail-from address using its own Sender-ID.mail-from test,
and the test result MUST NOT be a 'fail' or,
2) It MAY receive the message through some other mechanism by which it has
ensured that the entity which supplied it with the message was authorised to use
that mail-from address.
(Example : it could have perfomed SMTP AUTH and then checked in its own database
that this authenticated entity is authorised to use that specific mail-from
address).
Messages which are not verified by at least one of the above two tests SHOULD
NOT be offered for onwards transmission.
If, they fail the verification but are nevertheless offered for onwards
transmission, the "VERIFIED" keyword MUST NOT be used in the MAIL-FROM command.
Actions by receiving MTA
--------------------------
When the message is offered the receiving MTA SHOULD undertake the
Sender-ID.mail-from tests in the usual way.
If the VERIFIED keyword is not present, and the Sender-ID.mail-from test result
was 'pass', the receiving MTA MUST downgrade the mail-from test result to
'neutral' ('?') before any further use is made of that test result.
=================
This proposal covers the need to protect the sender's interests against
operational errors, equipment failures, mis-configuration of MTA, policy
changes etc. etc. at the site of the shared MTA.
It does not protect against sites which are prepared to lie - but this should
have been taken into account when the sender decided how much trust to have in
that MTA when she formulated her SPF policy.
It would also IMHO be a useful addition even when the outbound MTA is not shared
and is within the sender's organisation.
My advice to senders would be to only list as '+' those trusted MTAs which have
committed to the use of VERIFIED.
Indeed, the effect of my proposal is that messages sent through MTAs which do
not yet support VERIFIED can NEVER be given a '+' test result - there MUST be a
VERIFIED keyword present to achieve a '+' mail-from test result.
Chris Haynes