Subject: RE: alternate submitter syntax

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

-----Original Message-----
From: Meng Weng Wong [mailto:[email-masked]] 
Sent: Tuesday, 27 July 2004 11:37 PM
To: Terje Petersen
Cc: IETF MARID WG
Subject: Re: alternate submitter syntax

On Tue, Jul 27, 2004 at 03:42:53PM +1000, Terje Petersen wrote:
| 
| Okay so let's see if I understand you correctly. 
| 
|    a represents  friend@ hotmail
|    b represents  bob @ work
|    c represents  bob @ home
| 
| And the MTA at B talks to the MTA at C as such:-
| 
|   Eg MAIL FROM: <[email-masked]> SUBMITTER=<[email-masked]>
| 
|   Eg MAIL FROM: <friend@hotmail> SUBMITTER=<bob@work>
| 

Yes, that is the intent of SUBMITTER.

| 
| Given that [email-masked] is unlikely to have published SPF records
| that authorise the MTA at B to make this claim to the MTA at C 
| then its only going to work if the MTA at C has some rule to bypass 
| SPF checking for email from the MTA at B. Otherwise such an SPF test
| would fail to pass the bounce address. 
| 
| The MTA at C can do this if it trusts that B has already made the 
| relevant checks already and is itself trustworthy.
| 
| In effect the MTA at C must whitelist email from the MTA at B.  
| 

If receivers are explicitly aware of their expected
forwarding, abuse of SUBMITTER can be strongly limited.
In other words, any SUBMITTER not whitelisted can be
rejected, if receiver MTAs know what forwarding
relationships to expect.

| 
| However we could instead constructed a command sequence
| such as:-
| 
|   Eg MAIL FROM:<[email-masked]> SUBMITTER=<[email-masked]>
| 
|   Eg MAIL FROM:<bob@work> SUBMITTER=<friend@hotmail>
| 
| Which would seem altogether more reasonable and logical to me. 
| 
| And in this case [email-masked] is the reply address. Ie REPLYTO.
| 

OK, can you explain how this is better than the current
SUBMITTER proposal?

Also, I hope you are clear about the difference between the
envelope address used for bounces, and the header address
used to tell an MUA where to reply.

=================================================
=== Terje's Detailed Responds Below           ===
=================================================

I believe that I am clear on the difference between the bounce address
and the header address used for reply. 

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. 

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

So we have two scenarios:-

SCENERIO-A:	SUBMITTER parameter NOT supported.

	MAIL FROM     ->   BOUNCE ADDRESS
	SUBMITTER     ->   NOT APPLICABLE
      RFC.2822.FROM ->   REPLY ADDRESS

SCENERIO-B:	SUBMITTER parameter IS supported.

	MAIL FROM     ->   must equal RFC.2822
	SUBMITTER     ->   BOUNCE ADDRESS
      RFC.2822.FROM ->   REPLY ADDRESS

In other words the location of the BOUNCE ADDRESS moves in the syntax.
And we could have had a parameter called BOUNCETO instead of SUBMITTER. 

    Eg MAIL FROM:<friend@hotmail> BOUNCETO=<bob@work>

Is this a correct interpretation of what you are suggesting?

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 28 Jul 2004 01:35:10 -0400

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.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 29 Jul 2004 22:49:12 +0200

> is present, and MAIL FROM if it is not.

Let's see, I'm a spammer and have several hundreds of cheap
domains and thousands of spamcast zombies.  Today I would
point one of my domains to the IP where I host redirections
to my spamvertized pages, and then let my zombies send spam
MAIL FROM:<forged@xyzzy> From:<forged@xyzzy> Subject: Viagra

With classic SPF this will FAIL, no spamcast IP is allowed
to use a forged@xyzzy address.  Therefore I'm forced to use
other addresses.

With Sender-Id I'd also use one of my cheap domains per spam
run (to be burnt with SURBL) _and_ add a sender policy for it:

cast.example TXT "v=spf1 +exists:{ir}.cast.blackholes.us -all"

Then I let my spamcast zombies fire:

MAIL FROM:<forged@xyzzy> SUBMITTER=[email-masked]
From: forged@xyzzy
Sender: [email-masked]
Subject: Viagra

Sent from any spamcast zombie this should pass a Sender-Id test,
and therefore it's not necessarily rejected immediately by the
MX of the recipient.  If it's bounced later it would go to
forged@xyzzy.

In <[email-masked]>
Terje wrote:

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

That's also my impression.

You answered in <[email-masked]>:

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

What's this "whitelist" used with a SUBMITTER ?  In my example
the throw-away domain cast.example isn't on any "whitelist", it
only exists for a single spam run of 10 million spam mails, the
same idea as today with spamvertized domains.

                        Bye, Frank