Subject: marid-submitter-02: Recipient's point of view

From: Hadmut Danisch <[email-masked]>
Date: Thu, 5 Aug 2004 10:05:54 -0700

Hi,

sorry, to flood you with questions, but another one of 
my yesterday's questions. It hasn't been answered yesterday.

Imagine this:

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

Of course, superphishing.any would cover the sending MTA's IP address, 
so the message would be accepted by the receiving MTA.

But how could the human reading the message tell that it came from 
superphishing.any and not from the bank? Today's MUAs are not ready
for this extensions and I do not see how the SUBMITTER value would
find it's way to the human reader.

So forging and cheating is still possible, isn't it?

regards
Hadmut

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 5 Aug 2004 13:28:18 -0400

On Thu, Aug 05, 2004 at 10:05:54AM -0700, Hadmut Danisch wrote:
| 
| MAIL FROM: <[email-masked]>  SUBMITTER=[email-masked]
| 
| But how could the human reading the message tell that it came from 
| superphishing.any and not from the bank? Today's MUAs are not ready
| for this extensions and I do not see how the SUBMITTER value would
| find it's way to the human reader.

You are correct that MUAs will need to change.

The SUBMITTER draft assumes familiarity with the core/PRA
document.  Section 7.5 of that document reads:

  7.5  MUA Implementers

     When displaying a received message, an MUA SHOULD display the
     purported responsible address as defined by this document whenever
     that address differs from the RFC 2822 From address.  This display
     SHOULD be in addition to the RFC 2822 From address.

     When a received message contains multiple headers that might be used
     for the purported responsible address determination, an MUA should
     consider displaying all of them. That is, if a message contains
     several Resent-From's, a Sender and a From, an MUA should consider
     displaying all of them.

http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt

I think we all agree that the above argument as an
antiphishing device is weaker than next-generation
cryptographic solutions.

The rationale was this: preferring the SUBMITTER value over
the MAIL FROM value was seen as making life easier for
forwarders.  Requiring a PASS on SUBMITTER was seen as
making it possible to quickly attach reputation to bad
spammers.  (In other words, a reputation system would be
expected to quickly list superphishing.any.  This
expectation is justified by the fact that DNSBLs seem to
respond quickly, and RHSBLs should be able to respond just
as quickly.)

The common case is expected for SUBMITTER to not be present
in most spam, and so the check would operate against MAIL
FROM.

This reasoning is justified by:

4.1 Setting the SUBMITTER Parameter Value

   SMTP clients that support the Responsible Submitter
   extension MUST include the SUMBITTER parameter on all messages where
   the purported responsible address, as defined in section 4 of
   [SENDER-ID] differs from the MAIL FROM address.  This includes
   messages where the MAIL FROM address is empty or "<>".

http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt

I understand that to mean that the sending MTA has reduced
  MAIL FROM:<K> SUBMITTER=<K>
to
  MAIL FROM:<K>
and therefore a SPF check on K before DATA is sufficient.

The next sentence in the draft says:

   SMTP clients SHOULD include the SUBMITTER parameter on
   messages where the purported responsible address is the
   same as the MAIL FROM address.

I move to rephrase that as:

   SMTP clients MAY include the SUBMITTER parameter on
   messages where the purported responsible address is the
   same as the MAIL FROM address.

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 5 Aug 2004 10:49:09 -0700

> You are correct that MUAs will need to change.

It is far from reality to assume that sufficient many MUAs will 
change within 1-2 years.

>      SHOULD be in addition to the RFC 2822 From address.

This does not answer the question.

How does the information find it's way to the MUA? The SUBMITTER is
not an RFC2822 information. Were does it find it's place in a standard 
Unix mbox file without changing the mbox file format? How does IMAP
support this? POP? What about UUCP? How should a MUA be able to display an
information as long as there is no defined way how the MTA should 
pass the information to the MUA?

How many protocols, file formats and software do you intend to change?

Has anyone ever implemented this?

Hadmut

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Aug 2004 15:03:14 +0200

On Thu, Aug 05, 2004 at 10:49:09AM -0700,
 Hadmut Danisch <[email-masked]> wrote 
 a message of 35 lines which said:

> not an RFC2822 information. Were does it find it's place in a
> standard Unix mbox file without changing the mbox file format?

They way I understand draft-ietf-marid-submitter-02, it is the
opposite. The SMTP client must derive the submitter from the
2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and
4.3). So, there is no need to send SUBMITTER back into 2822-headers
(just a check, described in 4.3).

> How should a MUA be able to display an information as long as there
> is no defined way how the MTA should pass the information to the
> MUA?

See above. For instance, I quote  draft-ietf-marid-submitter-02, 4.3 :
 
This should involve no information loss, since the SUBMITTER parameter
is required to contain information derived from the message headers.

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 6 Aug 2004 09:29:30 -0400

On Fri, Aug 06, 2004 at 03:03:14PM +0200, Stephane Bortzmeyer wrote:
| On Thu, Aug 05, 2004 at 10:49:09AM -0700,
|  Hadmut Danisch <[email-masked]> wrote 
|  a message of 35 lines which said:
| 
| > How does the information find it's way to the MUA? The SUBMITTER is
| > not an RFC2822 information. Were does it find it's place in a
| > standard Unix mbox file without changing the mbox file format?
| 
| They way I understand draft-ietf-marid-submitter-02, it is the
| opposite. The SMTP client must derive the submitter from the
| 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and
| 4.3). So, there is no need to send SUBMITTER back into 2822-headers
| (just a check, described in 4.3).

I want to comment on how the phrasing above frames the
relatioship between PRA and SUBMITTER.

Alan Kay said: The best way to predict the future is to
invent it.

In the same way, sometimes the best way to "derive the
submitter from the 2822-headers" is to assign it.

If you have a given block of headers, you can derive the PRA
by examining the headers according to the algorithm
described in core (now moving to a separate document).

But you can also cheat.  You can simply prepend a
Resent-Sender or Resent-From header to the existing block.
Because you know what you prepended, you can assign that
value directly to the PRA variable.  That way you don't need
to look at the existing block of headers at all.  SUBMITTER
and PRA are synonyms.

In the above paragraph, who is "you"?  The current thinking
represented by the current drafts says "you" is the SMTP
client.

Niels Bohr said: The opposite of every great idea is another
great idea.

Suppose we turn things around and set "you" to be the SMTP
server.

It is possible to construct an equivalent operation in which
the SMTP sender system *does not* prepend a PRA to the
headers, but instead only assigns SUBMITTER.  In that world,
the SMTP *receiver* system is responsible for taking the
given SUBMITTER value and prepending it to the headers as a
Resent-* field.  SMTP receivers already do this --- "MAIL
FROM" turns into the Return-Path, so why shouldn't
"SUBMITTER" turn into Resent-From?  It is not a technical
challenge.

If the algorithm by which PRA is derived from the headers
turns out to be encumbered, the above workaround offers all
the functionality of the PRA/SUBMITTER system but without
the heartache.  It is, as it were, an independent
implementation, written without reading the original source
code, that offers the same feature set.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Aug 2004 17:04:56 +0200

On Fri, Aug 06, 2004 at 09:29:30AM -0400,
 Meng Weng Wong <[email-masked]> wrote 
 a message of 61 lines which said:

> In the same way, sometimes the best way to "derive the submitter
> from the 2822-headers" is to assign it.

Isn't it a violation of the current protocol:

   If the receiving SMTP server allows the connecting SMTP client to
   transmit message data, then the server SHOULD determine the purported
   responsible address of the message by examining the RFC 2822 message
   headers as described in [SENDER-ID]. If this purported responsible
   address does not match the address appearing in the SUBMITTER
   parameter, the receiving SMTP server SHOULD reject the message and
   when rejecting MUST use "550 5.7.1 Submitter does not match header."

?

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 6 Aug 2004 11:18:06 -0400

On Fri, Aug 06, 2004 at 05:04:56PM +0200, Stephane Bortzmeyer wrote:
| 
| Isn't it a violation of the current protocol:
| 

If by "violation" you mean "one possible suggested
alternative to", then yes.

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 6 Aug 2004 09:25:44 -0700

> (just a check, described in 4.3).
...
> is required to contain information derived from the message headers.

HELLLOOOO. Wake Up! We are not playing card games here. 

  *** This is about _security_! ***

We try to defend against attackers here. Spammers, cheaters,
criminals. What makes you think that they will comply to this
requirement?  Expecting the sender to behave well and to provide
redundant information consistently is naive and opening the door to
attacks.

May I ask who in this working group has experience in designing
security protocols?

Hadmut

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 6 Aug 2004 10:04:08 -0700 (PDT)

> (just a check, described in 4.3).

Misreading the draft as to the significance of Submitter is a reason for
not introducing this field.  A Should must be a Must check.  The general
goal was to protect the RFC 2822 headers.  To neglect checking RFC 2822
headers would remove this protection without any record of this lapse.

> is required to contain information derived from the message headers.

The claimed optimization depends upon a spammer being behind the curve. 
The receiving MTA must check both the Submitter and RFC 2822 headers, but
Submitter may allow this header check to be skipped.  Do not expect
Submitter parameters to fail acceptance to any degree, once its use
becomes prevalent.  Submitter acceptance can be accomplished any number of
ways, many without requiring an administrative relationship to various DNS
records.

I would not expect any optimization likely, but rather an added security
flaw is created.  There is also the opportunity for differences in the PRA
checks between two systems to then force rejection of messages.  The
errors may provide clues, but could become a mysterious problem, as what
is being asserted is not recorded.

Going down this path seems to be based upon an assumption spammers will be
thwarted by this check.  It is more likely this check will benefit
spammers and make support more difficult.

-Doug

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Aug 2004 22:06:11 +0200

On Fri, Aug 06, 2004 at 09:25:44AM -0700,
 Hadmut Danisch <[email-masked]> wrote 
 a message of 30 lines which said:

> HELLLOOOO. Wake Up! 

Not at this time of the day.

> May I ask who in this working group has experience in designing

Not me. Now, what's the security problem? The draft says that the
*client* SMTP must derive SUBMITTER from the 2822 headers and that the
*server* SMTP should check that they still match.

Besides a lazy server which understands SHOULD as "if you please", can
you present a scenario where SUBMITTER fails, because the bad guy
forged the 2822 headers (something which is easy to do, we know it, no
need to be a security expert)?