Subject: RE: alternate submitter syntax

From: "Terje Petersen" <[email-masked]>
Date: Wed, 28 Jul 2004 16:23:11 +1000

On Wed, Jul 28, 2004 at 11:22:14AM +1000, Terje Petersen wrote:
| 
| What your example suggests to me is that you want SUBMITTER to work
| differently to what I understand. 
| 
| It seems to me that you want the MAIL FROM parameter to be the bounce
| address only if there is no SUBMITTER parameter. If there is a
SUBMITTER
| parameter then the bounce address is specified by SUBMITTER. 

No, I expect the bounce address to always be MAIL FROM.

I expect the subject of SPF checking to be SUBMITTER if it
is present, and MAIL FROM if it is not.

| You want the meaning of MAIL FROM to change to being equivalent to the
| RFC.2822 FROM address. 

No, I don't.

===================================
=== TERJE RESPONDS BELOW      =====
===================================

Okay. Well that does take the whole thing a very long way from where I
understood it to be. 

So if we can summarise what you are saying we have this:-

SCENERIO-A:	SUBMITTER parameter NOT supported on MTA.

	MAIL FROM     =   BOUNCE ADDRESS (SPF TESTED)
	SUBMITTER     =   NOT APPLICABLE 
      RFC.2822.FROM =   REPLY ADDRESS  (NOT SPF TESTED)

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've read the proposed standard, however what
your saying sounds very different to what I understood. Based on what I
now think you are saying I am left asking myself what is the point of
SUBMITTER. I can no longer see any reason for its existence. 

And if when there is a SUBMITTER parameter you no longer test the
validity of the BOUNCE address then isn't that just another loophole to
allow denial of service attacks. 

For instance a virus sends itself as follows:-

	MAIL FROM:<[email-masked]>
SUBMITTER=<[email-masked]>
	RCPT TO:<[email-masked]>

The SUBMITTER address may pass the SPF check but down the track all the
non deliverable mail all bounces back to poor old bill. 

You seem to be giving up one of the prime benefits of SPF classic.

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 28 Jul 2004 15:45:34 -0400

On Wed, Jul 28, 2004 at 04:23:11PM +1000, Terje Petersen wrote:
| 
| And if when there is a SUBMITTER parameter you no longer test the
| validity of the BOUNCE address then isn't that just another loophole to
| allow denial of service attacks. 
| 
| For instance a virus sends itself as follows:-
| 
| 	MAIL FROM:<[email-masked]>
| SUBMITTER=<[email-masked]>
| 	RCPT TO:<[email-masked]>
| 
| The SUBMITTER address may pass the SPF check but down the track all the
| non deliverable mail all bounces back to poor old bill. 
| 
| You seem to be giving up one of the prime benefits of SPF classic. 
| 

If SUBMITTER appears on your whitelist, then you are
[email-masked], and can presumably do something
about it.

If SUBMITTER does not appear on your whitelist, then you can
reject the message even if the SPF check passes.