Subject: Request discussion about using SUBMITTER (together with new Submitted-By RFC 2822 header) as basis for futher work

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Sep 2004 06:38:39 -0700 (PDT)

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: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Sep 2004 16:45:12 +0200

On Mon, Sep 13, 2004 at 06:38:39AM -0700,
 william(at)elan.net <[email-masked]> wrote 
 a message of 76 lines which said:

> 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.

I agree with the idea but, to be sure we understand each other, may I
add some details? Tell me if I am on the right track.
 
> 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)

Do note that, in the pure forwarding case (use of Unix .forward), no
header is added by sendmail and a custom header is added by Postfix
(unlike what -core says in 7.2). Seeing the discussions about
"forwarding" (a very loose word here and not really clearer in RFC
2822), it would be better to specify it.

> 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
> first Submitted-By header

First in message order, meaning last in time order.

> and attempt to verify that. If it passes,
> everything is good,

Do not forget that the client MUST check that SUBMITTER agrees with
Submitted-by.

> "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.

The MUA MAY does its own SenderID check on the submitted-By header it
found.

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Sep 2004 08:33:45 -0700 (PDT)

> add some details? Tell me if I am on the right track.
Ok.
  
> 2822), it would be better to specify it.

It is difficult to write good description of what forwarding is
(part of what is there I already posted when quiting 2822 yesterday).
But I do think it is intent of this WG to specify case of forwarding
in its documents. In fact core draft does it already in section 7.2
and submitter draft provides example of forwarding. 

It is most likely that section from core draft would have to be moved
and modified to be in submitter draft (in addition to example that will
also stay). Perhaps case of forwarding with .forward can be mentioned 
separately too or possibly an example added for that.

> First in message order, meaning last in time order.

Correct.
 
> Do not forget that the client MUST check that SUBMITTER agrees with

Yes. 
Like with current SUBMITTER draft, at the end after data is received,
the MTA must also double-check that SUBMITTER MAIL parameter value
corresponds properly with RFC2822 headers, i.e. that first Submitted-By
header in email is the same.

> The MUA MAY does its own SenderID check on the submitted-By header it

The problem is that MUA does not know for certain ip address of SMTP
client that it needs to authorize. It must rely on the Received headers
for that and they maybe forged along with submitted-by. So I would be
very carefull on MUA doing this kind of verification and if it is
mentioned, a separate security section about possibility of special
type of forging that could pass MUA vericiation must also be present.

---