Subject: RE: Does marid-submitter-02 really make sense?

From: "Harry Katz" <[email-masked]>
Date: Mon, 9 Aug 2004 14:09:57 -0700

On Monday, August 09, 2004 10:24 AM [email-masked] wrote:

> First, I am not proposing anything here. Not only is 
> SUBMITTER not my idea, I have been quite clear that I am 
> ambivalent about its inclusion in MARID.
> 
> Second, the optimization in case 1 isn't a failure case but a 
> success case.
> There may be a throughput improvement in some MTAs if the 
> check can be done sooner. Mind you, I'm not saying there is 
> guaranteed to be such an improvement
> - just that it is a possibility. Actual implementation 
> experience would be needed to tell for sure.
> 

Ned is exactly correct here.  The purpose of SUBMITTER is to allow early
(i.e. at 2821-time) verification of the sender's identity, namely the
PRA.  At the IETF meetings last week there was some discussion of
whether this would result in bandwidth saving, throughput improvement,
or no benefit at all.  I tend to think there will be modest throughput
improvement, but agree with Ned that we need to verify through testing.

---

From: Shevek <[email-masked]>
Date: Tue, 10 Aug 2004 00:48:55 +0100 (BST)

> improvement, but agree with Ned that we need to verify through testing.

This is incorrect. At 2821 time, we know only who the sender CLAIMS to be
via SUBMITTER. It's not until after 2822 time, when we can compare the
SUBMITTER value to the PRA value computed from the 2822 headers that we
have verified the identity of the sender.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---

From: Philip Miller <[email-masked]>
Date: Mon, 09 Aug 2004 20:40:25 -0400

> have verified the identity of the sender.

The idea is that the DNS lookup and check can be parallelized with the continuation of the 
mail transaction, and then the final response to the DATA payload will be sent when the 
PRA matches the SUBMITTER and the SUBMITTER is allowed by its domain's DNS record.

Philip Miller

---

From: "Chris Haynes" <[email-masked]>
Date: Tue, 10 Aug 2004 02:47:05 +0100

> have verified the identity of the sender.

The situation is actually rather amazing, AFAICT.

So long as a client has a SUBMITTER domain which can pass the receiver's
2821-time test, it will so arrange things that it will_never_ fail the SUBMITTER
== PRA? test undertaken at 2822 time.

The reason:

Section 4.1 of submitter-02 states that clients
"...MUST if necessary, insert ... RFC 2822 headers ... to .[make the PRA] ..
match the SUBMITTER address".

Now, if you look at step 1 of the PRA algorithm in core-02, the first non-empty
Resent-Sender header can supply the PRA.  There may be any number of subsequent
Resent-Sender headers - the first one wins.

So, if I were a client wishing to avoid the 'hassle' of bounces I would just
automatically prepend all messages I sent with a Resent-Sender header containing
the same as my SUBMITTER address.  The PRA algorithm will always deduce this to
be the PRA and so the 2822-time test will always be passed.

It would not matter what the 'real' headers were in the message I was asked to
send - I can always trump them with my SUBMITTER address in a leading
Resent-Sender field.

OK - this does not sound honest.

But look again at section 4.1 of submitter-02.  It *requires* the client to
adjust the headers so that SUBMITTER and PRA match, and I have shown above that
this can *always* be done.

A rather smarter / honest / helpful client could use the PRA algorithm in
reverse and try adding a From, or a Sender, or a Resent-From header in order to
pass the PRA test in preference to just going straight for a Resent-Sender
header. But why should it bother, and on what semantic basis should it / could
it choose any of the other available headers to use?

So, it appears to me that the two drafts combine to ensure that clients which
can pass the SUBMITTER test at 2811 time should *never* fail the  2822-time
test.

In fact, a client which sends a message which then fails a  2822-time test  is
non-conformant to the drafts!

HTH

Chris Haynes

---

From: "John Glube" <[email-masked]>
Date: Mon, 9 Aug 2004 22:57:57 -0400

I have a couple of concerns and perhaps people can clarify
matters.

Based on my understanding of what transpired at last week's
MARID WG meeting one of the issues surrounding Sender-ID is
the implementation of Submitter in the 'wild.' 

My concern is whether in how we are approaching the problem
we are creating a potential security issue for ourselves.

Let me explain.

My premise is that the spammer's objective is to find a
security hole, be it at the authentication stage, (which
may also include reputation and accreditation checks), or
at the filtering stage and to exploit these gaps to allow
for message delivery, while hiding his, her or its identity.

This raises a number of problems:

* Until the Submitter extension is widely implemented,
those relying solely on PRA checks will have nothing to
check, unless one allows for checking SMTP mail from in the
absence of the Submitter extension.

* Sending direct from the IP address to the recipient MX is
the way a lot of spoofed and phishing messages are sent. 

This happened with the US Bank phish coming from a Chinese
IP address, which was discussed at length on the MARID
mailing list.

Until the Submitter extension is widely implemented, those
relying solely on PRA checks, would not have verified
whether the SMTP mail from is malformed and so would have
failed to reject this type of message during the
authentication stage.

(This is a short list. I know there are many more issues.)

As a result:

* By not checking whether the SMTP mail from is properly
formed, and

* By not checking the SMTP mail from and/or EHELO address
for spoofing during the data transfer stage, 

Does this create a security problem, unless one says, we
will reject email without a Submitter extension. 

Why? I go back to my original premise. A spammer who sends
spoofed email or wants to go phishing has no interest in
complying with the rules we write. 

Rather, he or she is seeking to utilize any 'security
holes' we allow for message delivery.

The problem? We can't say we will reject email without a
Submitter extension because an implementation time frame is
required.

The argument has been put forward, yes but the gap is
filled with the use of reputation and accreditation
services.

The concern is that reputation and accreditation services
are not designed to thwart spoofing and the use of other
technical means to hide a spammers identity, but rather to
deal with whether the sender does or does not have a good
reputation.

A reputation service says in essence, this sender whom we
can identify, based on past mailing practices has a good
reputation.

An accreditation service says in essence, based on our
review of this sender's actual or proposed practices, we
are satisfied this sender either: (i) has honourable
intentions, if it is a market newcomer; or (ii) has a good
history and in either case we are prepared to vouch for
this sender whom you can identify. 

Oh and by the way, should it turn out this sender does not
live up to his, her or its commitments, and we find out,
either through our own means, or based on relationships we
have, we will 'tar and feather the person':-)

Without the ability to specifically identify the sender,
are we not into blacklisting and filtering, along with the
related collateral damage, which is a concern for the
sending community and makes email unreliable for users.

As such until:

* there is sufficient implementation of Submitter in the
wild; or

* the receiving community says, want to send us email, you
must use the Submitter extension, 

without calling for the use of a malformed SMTP mail from
check, a spoofed SMTP mail from and an EHELO check, my
concern is we have not moved towards the underlying
objective of sender authentication which is to thwart
spoofing and the use of other technical means to hide
identity.

The other concern involves the less developed parts of the
world, and the use of the Internet infrastructure in these
communities by spammers to play havoc.

Do we know whether these communities can bear the cost if
any of Submitter implementation?

If we can rely on accreditation and reputation services to
fill the gap, do we know whether 'legitimate' senders in
under developed countries can realistically bear the cost
of accessing accreditation services?

Do we have any idea of a realistic time frame to allow for
sufficient implementation of Submitter in these parts, so
that receivers can fairly say, "we will require all email
sent to us to have a Submitter extension by such and such a
date?"

I am not saying based on all these concerns this means we
should reject Sender-ID.

(In my view, crunch time will likely occur when MS comes
forward with any IPR disclosure and the form of license, if
any it may require and how this pans out.)

What I am saying is either:

* Allow for a draft of marid - core to come forward which
takes these concerns into consideration; or,

* If it is felt the better course is to keep the marid
drafts pure, which is understandable, then we need to
quickly move ahead with review and implementation of
proposals like CSV and any others which directly confront
these gaps. 

This will allow the receiving community if it wishes to
receive a full stream of data sets and achieve the
underlying objective of sender authentication, being to
thwart spoofing and the use of other technical means to
hide identity, while allowing prudent senders to clearly
know and comply with the agreed rules.

John Glube
Toronto, Canada
 
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004

---

From: Michael Thomas <[email-masked]>
Date: 11 Aug 2004 08:14:07 -0700

> improvement, but agree with Ned that we need to verify through testing.

  The issue that I have here is that the optimization is
  misplaced engineering at best, and possibly the victim
  of unintended consequences at worst. The ultimate
  optimization is for spammers to not send _any_ packets at
  all. One thing that we know is that if we close off one
  avenue, spammers will shift their attention to other lines
  of attack. Thus if the base level check prevents forgery,
  they'll switch to a line of attack that doesn't use
  forgery. Creating a lot of infrastructure to optimize for
  a likely deprecated behavior doesn't strike me as an
  especially worthwhile use of engineering resources.

  On the harmful front, I have lingering doubts and worry a
  lot about what the consequences for mischief of
  introducing yet another identity -- and what exactly it
  means. I don't think we should take that lightly; if it
  has utility on its *own* merits, fine, but as currently
  instantiated as an optimization for MARID, it seems rather
  useless since spammers will simply never use this
  extension.
-- 
Michael Thomas	([email-masked] http://www.mtcc.com/~mike/)

---

From: Andrew Newton <[email-masked]>
Date: Wed, 11 Aug 2004 11:58:21 -0400

On Aug 11, 2004, at 11:14 AM, Michael Thomas wrote:

> Thus if the base level check prevents forgery,
>   forgery.

At that point, our job is done.

Not meaning to single out Michael, but a lot of the traffic on this 
list lately has been arguments about stopping spam.  This working group 
is not chartered to stop spam.

-andy

---

From: Michael Thomas <[email-masked]>
Date: 11 Aug 2004 10:46:22 -0700

> At that point, our job is done.

Then what is the point of putting through an optimization
like SUBMITTER? Especially since it seems to not optimize
the cases that you'd hope it would optimize?
 
> list lately has been arguments about stopping spam.  This working
> group is not chartered to stop spam.

_I_ haven't said anything about stopping spam. But surely
it's not off limits to talk about how the people who use
forgery as an attack vector will react in the face better
forgery protection.
-- 
Michael Thomas	([email-masked] http://www.mtcc.com/~mike/)
Fell to the Fog/Oak to Oakland
Pine to the Pacific/Bush in the Bay