Hello members of MARID WG,
I request formal discussion on possibility of replacing current SenderID/PRA
proposal with one that is based primarily on the extended Submitter draft
with additional extension that would involve new Submitted-By RFC2822 header.
In this case, the SUBMITTER SMTP extension would co-exist together with
new Submitted-By header and this allows for quicker adoption allowing
programs that are able to add headers (like software that operates mail
lists and forwarders) to do so without necessarily a need to change how
those programs call MTA program (i.e. it would require new interface
option when calling /usr/bin/sendmail to communicate SUBMITTER value if
it is entirely RFC2821 value). The SUBMITTER parameter of MAIL would also
be set exclusively based on this new header.
The Submitted-By header would have to be added by at least one entity
at each mail network (I defined mail network as "group of one or more SMTP
speakers that know each other and where each SMTP server in the network
has means of identifying SMTP client from the same network") and it
specifies Responsible Submitter entity, i.e. somebody that basicly takes
responsibility for transmission of the email on its network and maybe
contacted in case of problems. If there was reintroduction of email (such
as mail list or forwarder), then this mail list of forwarder is such
responsible party and it is supposed to add Submitted-By header (it may also
add Resent-From or Sender headers if appropriate just like they do now)
For email leaving the first "origin" network, the sender (as usually
listed in "Sender" or "From" headers) is the responsible party and MTA
that received email from MSA is supposed to add this new header
(with value taken out of "Sender:" header if it was present or otherwise
out of "From:"), but MSA itself MAY also add Submitted-By header
directly and is recommended to do so if it is tranmitting message on
behalf of third party (like hotel system or airport email kiosk).
For verification of email by means of SPF protocol, the SUBMITTER
scope would be used and clients that support it would be required
to base their decision based on either SUBMITTER parameter of MAIL
or based on the Submitted-By header if is top-most header in the
email. If it is not top-most header, then client SHOULD find the
first Submitted-By header and attempt to verify that. If it passes,
everything is good, but if it fails it SHOULD NOT immediatly
fail the message but MAY employ other means to attempt verification
including possibility of deriving possible Responsible Submitter
based on other headers (i.e. PRA or some other algorithm).
The results of the verification are to be reported using
"Authentication-Results:" header as to be defined further and based on
the draft-kucherawy-sender-auth-header-00.txt. If this header is present
(and MUA believes it was added by known MTA entity), then MUA program
SHOULD display the Submitted-By header and inform the end-user that it
has been verified. Otherwise, MUAs programs MAY display the first found
Submitted-By header but MUST then inform user that it has not been verified.
--------------
This is a general summary. I believe it represents proposal that achieves
the same goals as current SenderID (and partly based on it) but does not
have the same technical issues and I believe does not have IPR issues.
I note about IPR that the system makes PRA optional rather then required
part of the implementation to be considered consistent with the standard.
Some may still decide to implement PRA in their software and in this
case would need to get license, but opensource programs would be able
to be compliant if they implement checking based only on "Submitted-By:"
or they may choose algorithm other then PRA for deriving possible
Reponsible Submitter value.
Please feel free to comment what you think of these ideas and of possibility
of proceeding with this SUBMITTER scope in place of current PRA.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/