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)
SCENERIO-B: SUBMITTER parameter IS supported on MTA.
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:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
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.