Subject: I-D ACTION:draft-ietf-marid-submitter-02.txt

From: [email-masked]
Date: Tue, 20 Jul 2004 16:16:17 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF.

	Title		: SMTP Service Extension for Indicating the Responsible 
			  Submitter of an E-mail Message
	Author(s)	: E. Allman, H. Katz
	Filename	: draft-ietf-marid-submitter-02.txt
	Pages		: 13
	Date		: 2004-7-20
	
This memo defines an extension to the Simple Mail Transfer Protocol 
   SMTP) service, which allows an SMTP client to specify the responsible 
   submitter of an e-mail message.  The responsible submitter is the e-
   mail address of the entity most recently responsible for introducing 
   a message into the transport stream.  This extension helps receiving 
   e-mail servers efficiently determine whether the SMTP client is 
   authorized to transmit mail on behalf of the responsible submitter's 
   domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-marid-submitter-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-marid-submitter-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Terje Petersen" <[email-masked]>
Date: Thu, 22 Jul 2004 21:55:03 +1000

-----Original Message-----
From: Roy Badami 
Sent: Thursday, 22 July 2004 6:51 PM
To: Terje Petersen
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt

>>>>> "Terje" == Terje Petersen  writes:

    Terje>    When a SUBMITTER parameter is provided then receiving
    Terje> MUAs SHOULD display the SUBMITTER parameter as the sender
    Terje> of the email instead of the original FROM address in the
    Terje> RFS 2822 headers; otherwise an attacker can trivially
    Terje> defeat the algorithm by providing a different SUBMITTER and
    Terje>    FROM address.

But SUBMITTER is a parameter to an SMTP command.  How would the MUA
get to see it?

    -roy

~~~~~~

It would be written in the headers by the most recent MTA to receive the

e-mail. 

Currently if you can send an email with no headers then the receiving 
MTA will take the MAIL FROM address and add it as a FROM address in the 
headers so it becomes available to the MUA. The same would be true for
the 
SUBMITTER parameter which is written to the header also. All be it using
a 
slightly different syntax.

MUAs already have to grovel in the headers to find the FROM address.
Making
the MUA grovel for the SUBMITTER address is not really that different.

---

From: "Terje Petersen" <[email-masked]>
Date: Fri, 23 Jul 2004 11:07:45 +1000

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Friday, 23 July 2004 5:03 AM
To: Terje Petersen
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-marid-submitter-02.txt

Terje,

TP> When a SUBMITTER parameter is provided then receiving MUAs SHOULD
TP> display the SUBMITTER parameter as the sender of the email instead
TP> of the original FROM address in the RFS 2822 headers; otherwise an
TP> attacker can trivially defeat the algorithm by providing a different
TP> SUBMITTER and FROM address.

SUBMITTER is related to rfc2822.Sender, not rfc2822.From.

The concern for display to the user is certainly valid.  However
bypassing the From field creates more problems than it solves.

Dave Crocker --
--------------------

TP> My understanding is that in all properly formed email the 
TP> SUBMITTER address MUST equal rfc2822.From. 
TP> That being the case there should be no problem displaying
TP> SUBMITTER as the from address. 
TP> If they are not equal the email is malformed and displaying
TP> SUBMITTER just compensates for the malformed trick that the 
TP> sender is trying to conduct.