Subject: RE: alternate submitter syntax

From: "Daryl Odnert" <[email-masked]>
Date: Wed, 28 Jul 2004 10:24:17 -0700

> SCENERIO-B:	SUBMITTER parameter IS supported on MTA.
>
>	MAIL FROM     =   BOUNCE ADDRESS  (NOT SPF TESTED)
>	SUBMITTER     =   OTHER ADDRESS   (SPF TESTED)
>     RFC.2822.FROM =   REPLY ADDRESS   (NOT SPF TESTED)
>
>
> And in this second scenario I think you are saying that the addresses
> can all be different. Which does not seem to solve the phishing problem.
> So what am I missing here?

I think what you're missing is this, from draft-ietf-marid-submitter-02.txt:

   If the receiving SMTP server allows the connecting SMTP client to
   transmit message data, then the server SHOULD determine the purported
   responsible address of the message by examining the RFC 2822 message
   headers as described in [SENDER-ID].  If this purported responsible
   address does not match the address appearing in the SUBMITTER
   parameter, the receiving SMTP server SHOULD reject the message and
   when rejecting MUST use "550 5.7.1 Submitter does not match header."

Daryl Odnert
Tumbleweed Communications
Redwood City, California

---

From: "Terje Petersen" <[email-masked]>
Date: Thu, 29 Jul 2004 16:22:14 +1000

Meng etc,

I have reviewed the slide show before. However it was good revision to
read it again so thanks for suggesting it. 

With the understanding I now have under my belt I can happily concede
that SUBMITTER is appropriately named given the intent (although I do
think the draft standard on SUBMITTER is unclear in so far as it
presumes prior understanding of too much). 

In any case I still have issues. 

Let me see if I can summarise the standard correctly in my own words.

The PRA ADDRESS is one of the following.

RFC.2822.RESENT-FROM or
RFC.2822.SENDER or
RFC.2822.FROM

In that order of preference. 

QUESTION 1: Is it always the PRA address that is displayed in MUAs as
being the FROM or REPLY ADDRESS? Are some MUAs compliant and others not
compliant?

QUESTION 2: If the answer to the first question is NO then how is this
going to solve PHISHING?

With the above definition for PRA the following would apply.

SCENERIO-A:	SUBMITTER parameter NOT supported on MTA.

	MAIL FROM     =   BOUNCE ADDRESS  (SPF TESTED??)
	SUBMITTER     =   NOT APPLICABLE 
      PRA ADDRESS   =   MUA REPLY ADDRESS?? (SPF TESTED)

	MAIL FROM     =   BOUNCE ADDRESS  (NOT SPF TESTED??)
	SUBMITTER     =   OTHER ADDR      (SPF TESTED)
      PRA ADDRESS   =   MUA REPLY ADDRESS?? (NOT DIRECTLY SPF TESTED)
      PRA ADDRESS   =   SUBMITTER       (TESTED) 

QUESTION 3: Why is the bounce address not also SPF tested in this second
scenerio?

Assuming that the bounce address is not also tested it still leaves the
ability to write viruses that send email from the infected parties
machine (as an SPF authorised address of the infected party) with a
false bounce address. This means that some third party owner of the
bounce address could be victimised. When the virus is successful in
sending itself then the infection spreads. When the virus email is
bounced by antivirus gateways it annoys the hell out of some innocent
party. Surely this is a security loophole even if not as big as the
current SMTP security loophole.

QUESTION 4. If the bounce address was always SPF checked and confirmed
valid then could we not leave the confirmation that RFC.2822.PRA =
SUBMITTER as an MUA function? 

Regards,
Terje. 

-----Original Message-----
From: Meng Weng Wong [mailto:[email-masked]] 
Sent: Thursday, 29 July 2004 3:23 PM
To: Terje Petersen
Cc: IETF MARID WG
Subject: Re: alternate submitter syntax

On Thu, Jul 29, 2004 at 12:07:53PM +1000, Terje Petersen wrote:
| 
| However Meng seems to be saying that SUBMITTER does not need to match
| the header in RFC.2822 that is presented to the end users MUA as the
| FROM address. He is quite adamant that the SUBMITTER address need not
be
| the address that the end user is presented with. 
| 

Yes, if you read the core spec that describes PRA you will
see this.

Perhaps the slideshow which starts at
http://spf.pobox.com/slides/thenewspf/0010.html will be more
informative.  I apologize for the naming, but the slideshow
was drawn before the name Sender ID was chosen.