Subject: Sender-ID and last hop validation

From: "Nate Leon" <[email-masked]>
Date: Wed, 18 Aug 2004 16:13:47 -0700

Do I understand correctly that Sender-ID only authenticates the most
recent hop?  In the simple case, this is the domain where the client
lives that sent the message.  But in the more complex case, there may be
forwarding hosts in the middle.

i.e. my receiving MTA will authenticate the SMTP client delivering the
message to me. Specifically, it will ask, is the IP address connecting
to me authorized to send mail for the domain listed in the Purported
Responsible Address?

Or in example form... Some Guy at Yahoo! sends a msg to my Pobox.com
account (assuming I had one :-) which in turn, forwards the message to
MyWork address.  Thus, the MTA at MyWork will see the msg coming from
Pobox.com and validate that the Source IP address of the incoming
message is authorized to send mail for the Pobox.com domain.  The
receiving MTA at MyWork.com does not authenticate anything about the
yahoo.com domain.

Simple illustration:
   [email-masked] ---> [email-masked] ---> [email-masked]

Gory detail example...

   EHLO host.yahoo.com
   MAIL FROM:<[email-masked]>
   RCPT TO:<[email-masked]>
   DATA
      Subject: let's do lunch
      ...
      From: [email-masked]
      To: [email-masked]
      ...

Hopefully, the MTA @ pobox.com validates against yahoo.com
Pobox pre-pends a new header, and delivers the message to MyWork...

   EHLO host.pobox.com
   MAIL FROM:<[email-masked]> SUBMITTER=<[email-masked]>
   RCPT TO:<[email-masked]>
   DATA
      Subject: let's do lunch
      Resent-From: [email-masked]
      ...
      From: [email-masked]
      To: [email-masked]
      ...

Finally, the MTA @ MyWork validates against pobox.com (and not
yahoo.com)

So Sender-ID relies on the MTAs at each hop to do the authentication?

If I was using P-U-box.com (instead of POBox.com) and the MTA at P-U-box
didn't know about Sender-ID, I could receive junk at MyWork with an
SPF/PASS. (assuming P-U-box did publish SPF records)  Then I would
obviously change my service provider, or yell at them until they
implemented Sender-ID. :)

Please correct any mis-understandings!

TIA,
Nate

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 18 Aug 2004 22:06:06 -0400

"Nate Leon" <[email-masked]> wrote:
> recent hop?

  Any recipient looking at SMTP traffic must, by it's very design,
look only at the most recent hop (i.e. the information it has, and can
determine for itself).  However, as the message traverses a series of
MTA's to get to a final mailbox, the message must (by definition)
traverse *all* of those MTA's.  It can only do that if, at each hop,
the message passes whatever checks are implemented by that hop.

> receiving MTA at MyWork.com does not authenticate anything about the

  If pobox has claimed responsibility for the message via the fields
used by PRA, then the MyWork MTA can verify that the message passes
the rules published by pobox.com.

  If pobox does not claim responsibility, and just forwards the
message without touching the PRA fields, then the message must pass
the rules published by the responsible domain as determined by PRA.
Odds are, because the message now comes from pobox, that it won't.

  Whether this means that such forwarding is wrong, or Sender-Id is
wrong, is an exercise left for the reader.

  Alan DeKok.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 19 Aug 2004 00:07:00 -0700 (PDT)

> to me authorized to send mail for the domain listed in the Purported

You understand correctly. MARID/SenderID and any similar technology (RMX, 
SPF, CSV, etc) based on concept of MTA IP authorization are alaways going
to be one-hop only authentication. And there is nothing that can be done 
about that, since what is being authenticated is the ip address of the
mail server in the current email hop. 

In order to do authentication of hop not directly preceding current one 
in email path, you must have an identity that comes from that hop that
you can trust and verify to have been added during that hop and could
not have been added (forged) by anyone else. This basicly means it has
not be a cryptographic signature based verification. This is probably
going to be focus of MASS IETF WG. I have also some slides at
 http://www.elan.net/~william/asrg/SecuringEmailPath.htm
(its reworked version of previously published presentation), that show 
how in my view MARID (rather Unified SPF, as what is improperly listed in 
slides as MARID is really unified SPF) fit into securing email system.

What is not clearly listed in slides, in that MARID work offers good features
for internet mail system because of its low computational overhead. I've 
ran some tests on how much  computational work is involved in different 
authentication methods. The results are not unexpected - first its clear 
that any cryptographic based signature verification (s/mime compared to 
yahoo dk for example) requires about same amount of work, or more precisely
the computation work required is dependent on the size of the public key 
and if RSA or Diffie-Helman is used but not really dependent on the method
of how signature is included and this computational work is even with low
384k keys is 10 times the work necessary to do most email body transformations
or 20 times or more what it takes to just extract simple one-line header from
the body. At the same time, the work necessary to actually go through email
body text (and dely necessary before you can do it), is also not 0 compared
to what happens when you re able to judge authenticity of email.

The scale of computation work that exist is probably something like:
  1      : Envelope-only check during transmission (RMX, SPF Classic, CSV)
  5-10   : Quick body context check (known bad and good "From: header address
           from your personal list, reject based on known bad Subject phrase) 
  20-50  : Body context full check (spamphrase in body, boesian filters)
  40-100 : Encryption based checks (S/MIME or PGP, Yahoo DK, etc)

From all this and from common sense, clearly the quicker you can decide on 
validity of email and reject bad ones, the better. And in my view MARID 
goal is to provide lightweight mechanism with low computational overhead 
to be able to reject bad emails during SMTP transmission. Its a first step 
that may not be able to reliable authenticate sender in complex path, but 
at the same time 50% of emails are personal one sent person-person with 
basicly only one hop and there it can work perfectly (i.e. direct path 
cases from sender ISP MTA to recepient ISP MTA; sometimes sender may have 
multiple servers involved in transmission and recepient too may have 
filtering server, but these are "intranet" servers where no authenticaion 
is necessary - its the step from two independent networks that we need to 
be worried about). In such view if we create mechanism that works for 50% 
of current email cases with low computation overhead and avoids necessity 
to do more complex  check that requires 20% more computational complexity, 
then we have done a lot of good towards authenticated email (this is alike
RBL checks and email content checks - I use both with SBL and 5 other RBL 
checks during email transmission and afterwards sending email through
spamassisin for more complex checks).

Now to be able to authenticate sender several hopes away is what we'll 
need cryptography for. I do note that one highly publicided proposed 
cryptography method - yahoo dk - does not fit well into this because by 
its design (signature for entire body of email which can only be checked 
if that body does not change; but headers do change by email servers, 
forwarders or new ones added or additional body added to the end of email)
it can also only work reliably for direct next hop check and that that is 
not what we want for cryptography to be used for when 20 times less 
computational method is available (I hope MASS IETF group will see it 
despite pressure of corporate interests involved and what will be 
developed is something for point-point authentication where points are 
expected to be MTAs that are often several hops away in email path).

Now one last thing, is that BATV proposal (which proposes encryption of 
envelope mail from) is also cryptography based and that means it has a 
lot highier overhead then something like RMX or SPF Classic. But it does 
mean it will work reliably for multiple hopes, rather then just one hop. 
My view of this is that RMX or SPF Classic mail-from mechanisms should 
not be discarded (as they seem to be currently as part of MARID) but 
should be used as whitelisting mechanisms to avoid necessity to do more 
complex cryptographic verification - that is if RMX fails, the email 
should not be rejected, but instead its BATV signature should be checked 
in that case if it exists.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Graham Murray <[email-masked]>
Date: Thu, 19 Aug 2004 08:21:24 +0100

> Odds are, because the message now comes from pobox, that it won't.

So what happens if someone sets up a phisher friendly forwarding
system which does not perform PRA tests on incoming mail but which
generates valid PRA on the outgoing mail (ie adds a Resent-From:
and SUBMITTER)? This mail would pass all the tests but still be a
forgery.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Aug 2004 10:50:59 -0400

> and SUBMITTER)? This mail would pass all the tests but still be a

  Then that forwarding server would be publicly recognized as claiming
accountability for the mail.

  Alan DeKok.