Subject: Another question on draft-ietf-marid-submitter-02

From: Hadmut Danisch <[email-masked]>
Date: Wed, 4 Aug 2004 10:05:31 -0700

Hi,

another question about draft-ietf-marid-submitter-02:

e.g. the message is sent with

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

then bounce messages etc. are sent to [email-masked], isn't it?

Is that what it is supposed to be?

regards
Hadmut

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 4 Aug 2004 13:27:47 -0400

On Wed, Aug 04, 2004 at 10:05:31AM -0700, Hadmut Danisch wrote:
| 
| e.g. the message is sent with
| 
| MAIL FROM: <[email-masked]> SUBMITTER=[email-masked]
| 
| then bounce messages etc. are sent to [email-masked], isn't it?
| 
| Is that what it is supposed to be?
| 

yes, that is correct.

if SUBMITTER is provided, you do an SPF query against it;
only a PASS result is acceptable; if you get anything else,
you reject.

if SUBMITTER is not provided, you fall back to the MAIL FROM
value; if you get a FAIL result, you reject.  You do the
fallback because you expect that the sender is in fact
SUBMITTER aware but because the PRA == MAIL-FROM the sender
chooses to reduce
  MAIL FROM:<K> SUBMITTER=<K>
to just
  MAIL FROM:<K>.

SUBMITTER was considered superior to SRS because it was
expected to be easier for forwarders.

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 4 Aug 2004 10:37:11 -0700

> | Is that what it is supposed to be?

So I will still receive thousands of bounce messages because spammers
are abusing my address for sending messages?

Until now they used

MAIL FROM: <[email-masked]>

from now on they will use

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

and I'll still receive all that bounce rubbish?

Wasn't this all supposed to solve this problem?

Hadmut

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Aug 2004 18:37:09 +0100

> expected to be easier for forwarders.

SUBMITTER requires more invasive changes than SRS.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Aug 2004 18:49:42 +0100

> are abusing my address for sending messages?

Not if you use BATV.

Tony.

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 4 Aug 2004 13:55:18 -0400

On Wed, Aug 04, 2004 at 10:37:11AM -0700, Hadmut Danisch wrote:
| 
| So I will still receive thousands of bounce messages because spammers
| are abusing my address for sending messages?
| 
| Until now they used
| MAIL FROM: <[email-masked]>
| from now on they will use
| MAIL FROM: <[email-masked]> SUBMITTER=[email-masked]
| 
| and I'll still receive all that bounce rubbish?
| 

IF the strategy for SUBMITTER is "assume innocent until
proven guilty", then the answer (crossing your fingers) is
that RHSBLs will list [email-masked] quickly.

I would prefer the following:

IF the strategy for SUBMITTER is to limit its use to
forwarding scenarios ONLY --- and I am going farther than
Harry Katz's presentation --- then a receiver can in theory
define a whitelist of recognized aliases for a given RCPT.
Any SUBMITTER address that is not in that list can be
rejected.

This strategy means that mobile scenarios, etc etc can NOT
do

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

they MUST do

  MAIL FROM:<[email-masked]>

The [email-masked] is a sender-side alias for
[email-masked].  I would prohibit sender-side
aliasing for SUBMITTER.

I would prefer to only allow receiver-side aliasing for
SUBMITTER:

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

I would like to see a world where SUBMITTER if present is
ALWAYS a forwarding alias recognized by the RCPT.

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 19:55:08 +0200

> SUBMITTER requires more invasive changes than SRS.

Yes, it does.

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 4 Aug 2004 14:01:08 -0400

On Wed, Aug 04, 2004 at 06:49:42PM +0100, Tony Finch wrote:
| 
| On Wed, 4 Aug 2004, Hadmut Danisch wrote:
| >
| > So I will still receive thousands of bounce messages because spammers
| > are abusing my address for sending messages?
| 
| Not if you use BATV.
| 

The argument for BATV/SES in more detail is this:

There will always be some fraction of non-compliant
receivers.

Even if 90% of the world does the right thing and rejects
correctly if the MARID check fails, thus abating the bounce
blowback problem,

there will still be 10% who are oblivious to all the work we
are doing and will continue to do the blowback thing,

which suggests that if a sender is really concerned about
blowback they will do something unilaterally, orthogonal to
MARID,

and that unilateral thing looks like SES which has been
reinvented as BATV.

An implementation of SES is described here.

http://asarian-host.net/srs/sendmailsrs.htm

If you take SRS, remove the idea that only forwarders have
to do it, and add the idea that senders always do it, you
get SES.

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 20:20:27 +0200

> to do it, and add the idea that senders always do it, you

I had suggested a couple of days ago by private mail to one of the SRS 
developpers that, before SRS gets widely implemented, we might want to 
redesign it slightly to allow shorter, and more "human-understandable" 
Return-Path for mail that we would SRS and that is not actually a forward, 
but comes straight out of our own domain.

The current scheme is :

- One forwarding hop => SRS0
- 2 or more forwarding hops => SRS1

But if we SRS mail coming straigth out of our own domain, this currently 
produces a MAIL FROM which is both redundant, inelegant and not very 
readable, such as :
SRS0=k0kO=K2=bouissou.net=[email-masked]

So I suggest that we might want to add an additional SRS type for "0 
forwarding step"

I would suggest to renumber for being more logical, and use

SRS0 : 0 Forwarding step
SRS1 : 1 Forwarding step (would be the equivalent of current SRS0)
SRS2 : 2 or more forwarding steps (would be the equivalent of current SRS1)

If we were to renumber SRS, now would be the good time to do it, as there are 
quite probably very few implementations on production in the field.

The syntax for an SRS0 address would be the same as for an SRS1 address, 
except that the domain would be ommited from the LH part (being redundant), 
and the hash would be calculated over the complete address (not on the LH 
part alone)

That would give SRS0 addresses of the form:
SRS0=k0kO=K2=[email-masked]

Shorter, and easier to read.

This would'nt add much complexity, proceeding as follows:

- Forward SRS :
- Processing an address which is not already SRSn: If the sender's MAIL FROM 
domain equals our own domain, create an SRS0 address, otherwise create an 
SRS1 address.

- Processing an address which is already an SRSn address: Create an SRS2 
address (using the same system as in use for current SRS1)

- Reverse-SRS : Decode according to SRSn type.

Comments ?

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 4 Aug 2004 13:55:06 -0700 (PDT)

> expected to be easier for forwarders.

This is not as defined in the Submitter specification with respect to
error results.  The Submitter draft does not indicate a fall-back to MAIL
FROM.  It only requires Submitter, if the PRA is different than the MAIL
FROM and Submitter is supported.  This Fall Back can only make this
assumption if Submitter is supported, but then it is not a suggested mode.

Submitter is not superior to BATV.

If the outcome of arm-twisting MTAs into publishing Sender-ID records, the
only logical recourse would be to include a Resent-From header to permit
customers to continue their normal practices. If that becomes the normal
case, then using and exposing the EHLO domain to the user from the
Received header would be of equal user value to that of a PRA identity. 
CSV would also give enforcement the domain of where to make a request for
a log.

The advantage to switching to the CSV EHLO domain would be a deterministic
load on the receiver (no additional DNS query), and the ability to
accredit the machine that allowed the mail to be sent.  Only a single
identity could be selected, as opposed to the PRA algorithm which could be
one of many, where only one may normally be seen.

(I would suggest some character used to terminate the EHLO domain to
indicate a successful authentication and authorization process.  There is
some general text within the CSV Intro draft to this respect, but it
should be made specific.)

-Doug