ietf-mxcomp
[Top] [All Lists]

RE: alternate submitter syntax

2004-07-27 23:23:14


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:<bill(_at_)microsoft(_dot_)com>
SUBMITTER=<infectedsucker(_at_)xyz(_dot_)com>
        RCPT TO:<random(_dot_)address(_at_)somewhere(_dot_)com>

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. 





<Prev in Thread] Current Thread [Next in Thread>