Subject: RE: (DEPLOY) In Support of Sender ID

From: "Ryan Malayter" <[email-masked]>
Date: Thu, 2 Sep 2004 15:01:42 -0500

[Kevin Peuhkurinen]
>To my mind, there are ZERO hinderences to Microsoft 
>adopting SPF, but there are plenty of hinderences 
>for most everyone else to adopt the encumbered 
>Sender-ID.

SPFv1 does not address email header forging at all. So SPFv1 does very
little to prevent forging of the "from" addresses seen by the user in
99% of MUAs. SPFv1 therefore does very little to prevent phishing scams.
This is why Microsoft came up with CallerID for email, and why Meng and
MS decided to merge the best parts of SPF and Caller ID into SenderID
approaches.

So yes, there are very big hinderances to MS and everyone else adopting
SPF classic - it doesn't solve a big part of the email forging problem.

Even "Unified SPF" still defines the PRA algorithm for use in verifying
mail headers, and therefor is also incumbered by the Microsoft IP.

--
Ryan

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2004 13:36:27 -0700

> mail headers, and therefor is also incumbered by the Microsoft IP.

I have introduced the MPR draft to illustrate how to arrive at either
the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building
upon the CSV standard to achieve the same goals as both SPF and
Sender-ID.  This does not use the PRA algorithm, as it expects From
restriction to be made for exceptional uses.  This also overcomes
problems of the indeterminate and potentially very high DNS overhead,
replication of DNS addresses, "open" lists creating spam exploits,
dangers of harm by misapplication of reputation, and removes an ability
to hide listing by way of macros.  One fundamental difference is the
treatment of reputation as a separate function from that of mailbox
domain to outbound server association.

-Doug

---

From: "Michael R. Brumm" <[email-masked]>
Date: Thu, 2 Sep 2004 15:27:47 -0600

>MS decided to merge the best parts of SPF and Caller ID into SenderID

SPF protects envelope forging correctly. SenderID doesn't.

While SPF doesn't prevent forging of 2822 addresses seen by 99% of MUAs, the
same could be said of SenderID. I don't know of any MUAs which display the
PRA as described by SenderID.

So, either way, it means upgrading all the MUAs. IMHO, if we are going to
upgrade the MUAs to prevent phishing, we should look towards a stronger
crypto/signing solution, not the flimsy solution provided by SenderID.

Michael R. Brumm

---

From: wayne <[email-masked]>
Date: Thu, 02 Sep 2004 17:08:07 -0500

In <[email-masked]> "Ryan Malayter" <[email-masked]> writes:

> This is why Microsoft came up with CallerID for email,

Yeah, but SenderID doesn't protect the From: header in any critical
situation.  It protects the nearly invisible Resent-Sender: header.

>                                                        and why Meng and

I have had lots of conversations with Meng and his usual reason for
supporting the merger was because he felt that MS would promote
deployment.  He is now very actively promoting Unified-SPF.

> SPF classic - it doesn't solve a big part of the email forging problem.

SPF-classic goes a long way of solving the forging of the
2821.MAILFROM identity.  SenderID does not do much of anything to
solve the problem of forging the 2822.From: identity.

> mail headers, and therefor is also incumbered by the Microsoft IP.

And the PRA part of Unified-SPF is optional.

-wayne

---

From: Rand Wacker <[email-masked]>
Date: Thu, 2 Sep 2004 15:06:49 -0700 (PDT)

> PRA as described by SenderID.

As I said before, there is a large majority of mail that goes from large
commercial sites (or consumer ISPs) merely one hop to another large
commercial ISP, so the From: header will be successfully authenticated.

Due to the fact that there will be a small number of messages that *will*
take multiple forwarding or other hops, IP-based authentication of headers
won't work for those with existing mail clients, and all IP auth solutions
have the potential of causing false positives if the interim forwarding
hops aren't upgraded.

For this reason, it may end up being the case that Sender ID can not
reliably prevent spoofing for messages that take complex paths; but there
is some solace in that these complex paths are usually managed by the
*receiver*.

SPF, while authenticating something that does not give you a positive
value for the first case I stated, also has the potential to change a very
fundamental part of the mail channel in trying to work around the problem
of the second case.

(And yes Dave Crocker, I am simplifying the "one hop" idea in my first
paragraph, but from what I've seen so far it looks like that idea holds
for large Enterprise-to-ISP or ISP-to-ISP communication in a majority of
cases :)

-Rand

---

From: "Michael R. Brumm" <[email-masked]>
Date: Thu, 2 Sep 2004 19:32:15 -0600

> commercial ISP, so the From: header will be successfully authenticated.

The problem with SenderID I mentioned is that most of the other PRA fields
(besides From:) are invisible in most MUAs, and therefore allow forgers to
spoof the From field anyway. The solution to this problem is, of course,
upgrading MUAs to display the PRA field. But according to Ryan, SenderID's
improvement over SPF was that MUAs didn't need to be upgraded.

I'm not sure how the number of hops or the business model used by the MTAs
affects this.

In any case, if we are talking about upgrading MUAs en-masse to combat 2822
header forging and phishing, then I think the only good solution is
cryptography and signing. However, this is probably outside the scope of
MARID.

Michael R. Brumm

---

From: Graham Murray <[email-masked]>
Date: Fri, 03 Sep 2004 06:25:21 +0100

> commercial ISP, so the From: header will be successfully authenticated.

In the case of sending from a large ISP (and that includes commercial
sites who outsource email) that is not true. Unless the ISP does
additional checking then Sender-ID (and SPF) still allows a customer
of the ISP to forge the mail as coming from any other customer of that
ISP.

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 3 Sep 2004 02:42:13 -0400

On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote:
| 
| Rand Wacker <[email-masked]> writes:
| 
| > As I said before, there is a large majority of mail that goes from large
| > commercial sites (or consumer ISPs) merely one hop to another large
| > commercial ISP, so the From: header will be successfully authenticated.
| 
| In the case of sending from a large ISP (and that includes commercial
| sites who outsource email) that is not true. Unless the ISP does
| additional checking then Sender-ID (and SPF) still allows a customer
| of the ISP to forge the mail as coming from any other customer of that
| ISP. 

My read of most ISPs is that they are willing to move in
this direction if it proves necessary.  Many ISPs are
beginning to roll out (mandatory) SMTP AUTH.  With that in
place, halting cross-customer forgery becomes a much more
likely proposition.

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 3 Sep 2004 11:15:59 +0100

> commercial ISP, so the From: header will be successfully authenticated.

You're talking about the positive evaluation proposition of Sender-ID - 
that the From address is authenticated. Yet both Cyphertrust and 
SpamAssassin's stats show that the spammers are more on top of this 
than the legit mailers. This indicates to me that we need to be looking 
towards the negative evaluation proposition (i.e. the value in 
rejecting mail) that Sender-ID and/or SPF gives us, rather than hoping 
that a Sender-ID approved mail actually provides us with any benefits.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 3 Sep 2004 08:43:10 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Meng Weng Wong
> Sent: Friday, September 03, 2004 2:42 AM
> To: [email-masked]
> Subject: Re: (DEPLOY) In Support of Sender ID
>
While SMTP AUTH will help ISPs manage access to their MTAs, it doesn't help
them with the policy and procedural issues of managing lists of domains that
different users may legitimately send from.  I believe that these types of
issues are ultimately a greater deterrent to large scale prevention of
cross-customer forgery than the particular method of MTA access
authentication.

As I've said before,

http://www.imc.org/ietf-mxcomp/mail-archive/msg04034.html

I think the simplest way all around (assuming we go forward with Sender-ID
in some form) is to have ISPs use Submitter.  That way they don't have to
manage lists of domains that customers have access to.  Any messages coming
from the ISP MTA are checked under Sender-ID against the ISP spf2 pra
record.  I don't think it changes in any significant way what they will
already have to do to support Sender-ID anyway.

For those of us without the resources to operate our own MTA, the potential
for cross customer forgery is a huge issue.

Scott Kitterman

---

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 08:54:07 -0700 (PDT)

> of the ISP to forge the mail as coming from any other customer of that

Sorry, I should have said "the domain of the From: header"  Such is the
limitation of doing domain-based auth.  The limitation of doing user-based
auth is a high barrier to deployment.

-Rand

---

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 12:16:56 -0700 (PDT)

On Fri, 3 Sep 2004, Matt Sergeant wrote:

> > As I said before, there is a large majority of mail that goes from
> > large commercial sites (or consumer ISPs) merely one hop to another
> > large commercial ISP, so the From: header will be successfully
> > authenticated.
>
> than the legit mailers.

*NO*.  I am talking about using authentication status as the basis for a
new set of checks such as whitelisting.  I have been saying since the
beginning that spammers would authenticate their outbound mail in hipes
that someone would make the brain-dead assumption that "authenticated" ==
"wanted".

> This indicates to me that we need to be looking towards the negative
> evaluation proposition (i.e. the value in rejecting mail) that Sender-ID
> and/or SPF gives us, rather than hoping that a Sender-ID approved mail
> actually provides us with any benefits.

Sender ID approved mail provides you with the benefit in that it is
authenticating a well-comprehended user address, the From: header.  This
is something that's easy for users and admins to comprehend and whitelist.
Whitelisting of the envelope is more complex and won't be understood by a
large portion of users out there.

Everyone on this list has also admitted that *no* IP-based scheme can
authenticate more than one hop prior to when you receive a message, and we
all seem to agree that the right long term approach is a crypto-based
solution.  Sender ID gives you a nearer-term benefit for large
business-to-ISP or large ISP-to-ISP mail delivery, where you /can/
authenticate the from header (stuff that goes through forwarding hops be
damned seems to be the consensus of anyone pushing *any* IP-based
solution).

Sender ID also has a more graceful workaround for the forwarding hops that
want to become compliant.  SRS has some severe technical failings, so
much so that source routing was completely abandoned 15 to 20 years ago as
unworkable.

Everyone knows that there are limitations to what Sender ID can do, but it
brings a good enough benefit to a large enough percentage of mail that it
is worth moving forward with (as long as the licensing issues can be
worked out).  SPF solves a different problem and brings a whole host of
other technical issues to the table.

-Rand

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 15:48:28 -0400

> that someone would make the brain-dead assumption that "authenticated" ==

It can also serve as a basis for reputation and accreditation systems.

Remember that spam is multipronged, and this is another tool in the 
toolbox. No one is talking about this as the final solution for spam.

Yakov

---

From: "Mark C. Langston" <[email-masked]>
Date: Fri, 3 Sep 2004 13:03:11 -0700

> toolbox. No one is talking about this as the final solution for spam.

It's important to realize that there is no one single "solution for
spam".  Much like the security arena, any successful anti-spam strategy
will need to take a "layered onion" approach:  multiple, diverse tools
and techniques, none sufficient on their own, that provide a
comprehensive solution when deployed together.  This means that a robust
anti-spam solution will encompass authentication, reputation,
acceditation, whitelisting, blacklisting, filtering, and other
techniques, at various points in an organization's infrastructure.

There is no anti-spam magic bullet, nor a simple, all-in-one appliance
with a single management interface that'll solve all your spam problems.
A single firewall does not a security strategy make; a single anti-spam
tool does not an anti-spam strategy make.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: "Michael R. Brumm" <[email-masked]>
Date: Fri, 3 Sep 2004 14:42:37 -0600

Rand Wacker wrote:
> want to become compliant.

Yes, and the "graceful workaround" is also an open backdoor for injecting
forged DSNs. That is a technical failing.

Rand Wacker wrote:
> SRS has some severe technical failings, so much so that source routing
> was completely abandoned 15 to 20 years ago as unworkable.

SRS has no technical failings AFAIK, and it is being used successfully by
quite a few people on several MTA platforms. It isn't aesthetically
pleasing, but that isn't a technical fault. And your reference to source
routing makes me doubt you even understand what SRS is... How is source
routing relevant to SRS?

Rand Wacker wrote:
> worked out).

The MARID charter is "authenticate mail transfer".

The MARID charter isn't "make the largest percentage of existing mail
transfer appear to be authenticated".

There is a big difference between these two. The former means that an MTA
implementing MARID will be able to authenticate all mail from a domain
publishing MARID, now and in the future.

SenderID currently falls in the latter. An MTA implementing SenderID will
receive some types of mail which appear authenticated, but are not. In my
experience, partial protection is no protection at all.

Michael R. Brumm

---

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 13:50:05 -0700 (PDT)

> The MARID charter is "authenticate mail transfer".

Interesting, I went back to read the charter and notice that MARID has no
binding to do IP-based authentication (although it could be read that
way).  Maybe we *should* just go straight to a crypto-based solution.
That would seem to get around a lot of the disagreement currently on the
list.

-Rand

---

From: Daniel Senie <[email-masked]>
Date: Fri, 03 Sep 2004 11:02:07 -0400

>place, halting cross-customer forgery becomes a much more

To be a little more accurate, SMTP AUTH does not prevent customers of an 
ISP or hosting company spoofing one another, but it does provide an audit 
trail, so the person doing the spoofing can easily be identified from log 
entries.

The real point (which I think Meng was trying to make) is that if we use 
whatever this WG produces (assuming something useful is produced) a 
mechanism that gets us back to the originating ISP, abuse at that level can 
and should be handled by that ISP. It may be beyond the scope of this WG to 
solve the internal abuse issues within an ISP.

---

From: George Schlossnagle <[email-masked]>
Date: Fri, 3 Sep 2004 17:19:42 -0400

On Sep 3, 2004, at 11:02 AM, Daniel Senie wrote:

> To be a little more accurate, SMTP AUTH does not prevent customers of 
> an ISP or hosting company spoofing one another, but it does provide an 
> audit trail, so the person doing the spoofing can easily be identified 
> from log entries.

It can.  There are MTAs which support only using a set envelope sender 
after SMTP AUTH.

George

---

From: "Michael R. Brumm" <[email-masked]>
Date: Fri, 3 Sep 2004 15:18:50 -0600

>That would seem to get around a lot of the disagreement currently on the

Well, I think the IETF should tackle crypto-based solutions after we have
the IP-based authentication standard well on its way. MARID's charter might
allow this.

IP-based authentication on MTAs has been seen as the first step because it
has a smaller deployment and a smaller performance cost than the
crypto-based solutions. And, surprisingly robust authentication can be done
with IP-based authentication, if the 2821 HELO and/or MAIL FROM are used.

Crypto-based solutions can be applied later (after the IP-based
authentication), because it has a larger deployment (modification to message
re-writers like mailing lists, and normally also modifications to MUAs) and
a much larger performance cost.

Michael R. Brumm

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 17:48:16 -0400

> a much larger performance cost.

See:

http://www.imc.org/ietf-mailsig/index.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Sep 2004 14:55:29 -0700

> solve the internal abuse issues within an ISP.

Any process which authenticates the MTA, including CSV, would allow such
a method of tracing.  With Sender-ID or SPF, those administering the
policy for the MTA remain anonymous.  Unlike CSV, the Sender-ID or SPF
name is not safely used for doing reputation assertions.  After a name
for an MTA is established, prescribing an association of the mailbox
domain to a set of MTAs can be done using a simple list of names.  With
a name list, no subsequent lookups are required.

-Doug

---

From: Paul Iadonisi <[email-masked]>
Date: Fri, 03 Sep 2004 18:07:20 -0400

On Fri, 2004-09-03 at 17:19, George Schlossnagle wrote:

[snip]

> It can.  There are MTAs which support only using a set envelope sender 

  I'm actually doing this with some simple rulesets in sendmail on my
personal domains.  I even do 2822.from header checking to prevent
forging the 2822.from address beyond issued aliases for a given username
(my usernames are [email-masked]).  I currently don't support
Resent-* headers (From: header is always checked) and don't know that I
ever will.
  Point being that although SMTP AUTH doesn't require limiting users to
specific 2821.from and/or 2822.from addresses, it certainly makes it
possible, and in fact is trivial to add in at least some MTAs/MSAs.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

---

From: Mark <[email-masked]>
Date: Fri, 03 Sep 2004 22:14:09 GMT

Rand Wacker wrote:

> Sender ID also has a more graceful workaround for the forwarding hops
> that want to become compliant. SRS has some severe technical
> failings, so much so that source routing was completely abandoned 15
> to 20 years ago as unworkable.

There are, as far as I know, no outstanding issues with SRS. I have been
using it almost since day one, on my own server (and implemented SRS
functionality in spf-milter, for instance). It has no technical failings;
let alone "severe" ones. In the very early days of SRS, addresses could
become too long. Ever since SRS1, that problem has long since been solved,
and people have upgraded both their SRS implementations and their knowledge
of SRS.

- Mark

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Sep 2004 16:28:15 -0700

> It can also serve as a basis for reputation and accreditation systems.

For an identification to useful for reputation assessment, there needs
to be certainty this identity has not been spoofed.  This is not
achievable with Sender-ID.  There are many scenarios where Sender-ID can
be spoofed, as the mail channel is not secure.

It is possible to establish an authenticated name for the MTA however,
and then assert a mailbox domain relationship with MTA names.  The MTA
name, as the stronger identification, and not the mailbox domain, could
be used for reputation assessment.  The use of the mailbox/MTA
relationship would be helpful in lowering odds of being tagged by a
filter.  This type of arrangement overcomes the high DNS overhead
problem plaguing Sender-ID.  This arrangement is no worse than endemic
use of Resent-From headers for administrators to understand, and it has
far less overhead to implement than Sender-ID.
 
-Doug

---

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 3 Sep 2004 22:25:33 -0400

> [mailto:[email-masked]]On Behalf Of Daniel Senie
> Sent: Friday, September 03, 2004 11:02 AM
> To: Meng Weng Wong; [email-masked]

> solve the internal abuse issues within an ISP.
Currently Sender-ID only gets us back to the ISP if the PRA is an address in
the ISP's domain.  In the case of a single hop, non-forwarded message from
the ISP, if from: is a different domain than the ISP's, PRA will resolve to
the from: domain and not the ISP: domain.  While the from: domain could
report any complaints to the ISP, by the time the matter was resolved, the
from: domain might already be blacklisted (assuming domain name based
blacklists again become popular).

I think it would be much better to insist that in this case the ISP domain
be the PRA by adding an appropriate 2822 header as I suggested earlier:

This gets us directly back to the originating ISP and also place the risk of
blacklisting where it belongs.  Since it would be the ISP's reputation that
would be at stake, they would also be more likely to be motivated to limit
cross-customer forgery in the first place.

Scott Kitterman

---

From: "jpinkerton" <[email-masked]>
Date: Sun, 5 Sep 2004 10:37:01 +0200

I have about 20 domains, most with multiple, active e-mail facilities, and
with many more on many sub-domains.

I will not be using Sender-ID because :-

1.    There is no means by which Sender-ID identifies the originating
server, IP or domain for e-mails in a multi-hop transmission, thereby
allowing me to be confident that the mail is from who it claims to be from,
and allowing me to check it against white/black lists, reputations, etc.

2.    There is insufficient proof that the technology will be free of legal
encumberances for me to implement, modify and pass on to other implementors.
In fact there are three legal opinions that I have seen on this list stating
the opposite.

I am an active member a co-operative group owning 5 server boxes at
different locations, we have something in the region of 1,000 domains
between us.

I will be recommending that Sender-ID is NOT implemented by the members of
the co-operative.  I will be recommending alternative solutions to add to
our existing anti-spam efforts.

Kind regards,

John Pinkerton.
[email-masked]
ICQ 313355492

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 6 Sep 2004 11:02:42 +0100

> large portion of users out there.

Unfortunately whitelisting and blacklisting of addresses happens today 
(in most MTAs that I'm aware of) on the envelope address, not the 
headers, and since a whitelisting has to override a blacklisting you're 
suggesting a significant shift in operating procedure (from rejection 
at MAIL FROM to rejection at EODATA). As someone responsible for 
anti-spam for billions of mails per month I can't imagine that's a 
change we'd want to make lightly, especially given the increased cost 
of holding off the rejection until EODATA.

Another thing to remember is that the people at the coal face of spam 
attacks don't want to be able to whitelist more. They want to get rid 
of more spam. Those who want to be able to improve whitelisting have 
something to sell you (this isn't necessarily bad, but it tends to be 
true). Some have argued that being able to validate and accredit 
domains will allow you to turn up the strength of your spam filters, 
but anyone who has worked on real world spam filters (SpamAssassin and 
a commercial filter here) will be able to tell you that this is very 
much non trivial.

We would make the change if it had a significant benefit to our 
customers, but in this thread there has already been what I consider 
strong enough proof (in response to your large bank example) that 
everything we need for whitelisting even complex mail routing is 
possible using the envelope address anyway.

While today there are a number of MUAs that don't display the envelope 
address, the MUAs will have to change to display whichever of the MAIL 
FROM or the PRA we're validating.

Furthermore, almost none of the businesses we work with allow their 
users to whitelist addresses of their own choosing, at least not with 
without admin approval. This stuff happens today on the envelope, and 
while it has taken some training it is not a significant barrier.

I agree with you that we should move forwards with Sender-ID assuming 
Microsoft can fix their license issues. Certainly one of the benefits 
of moving forwards is to approve -protocol, which is the real meat of 
Unified SPF and will bring us gains when we come to implementing crypto 
validation.

Matt.

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 6 Sep 2004 11:04:08 +0100

> tool does not an anti-spam strategy make.

I don't think anyone on this list needs to be reminded of this, at 
least not those participating.

Matt.