Subject: Re: [Asrg] A Technique for Universal Authentication

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Aug 2006 21:31:04 -0700

Michael Kaplan wrote:
> I have a design for a system that allows for universal email 
> authentication by improving upon an anti-spam concept that I introduced 
> earlier.   Any email may be authenticated, including mail not 
> authenticated by existing schemes such as DKIM.  This system does not 
> require email users to change their behavior.

I sent a message to you and cc it to John Levine.

What value is put into the rfc2822.from field, the subaddress for mail 
to you or the one for John Levine?

Further, if it is the subaddress tailored for you, then I cannot receive 
a reply from John.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 1 Sep 2006 00:44:06 -0400

In your scenario a unique sub-address would be sent to myself and to John
Levine, although it would also be quite acceptable to dispatch the same
sub-address to each of us.

Anyone can use any sub-address.  You would receive John's email but as
demonstrated in Figure 5 you would know that John replied to you using the
sub-address that was originally sent to me.

John would only need to use a sub-address if his email received a poor
rating from a Bayesian filter.

Michael Kaplan

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Aug 2006 22:07:38 -0700

Michael Kaplan wrote:
> In your scenario a unique sub-address would be sent to myself and to 
> John Levine, although it would also be quite acceptable to dispatch the 
> same sub-address to each of us.

The main point of my questions was to raise the question of creating and 
tracking combinatorials, or else the problem of replies among groups.

As the combinatorials of interaction increase, so will the complexity of 
keeping track of all the addresses.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 1 Sep 2006 05:39:02 -0000

>I have a design for a system that allows for universal email authentication
>by improving upon an anti-spam concept that I introduced earlier.

Per-correspondent subaddresses are a rather old idea.  The idea was
popularized by Zoemail in 2001 but it goes way back, at least as far
as the CMU Andrew system in 1990 or 1991.

All of the subaddress schemes appear to try to turn the spam problem
into the introduction problem.  That is, if we can recognize mail from
people we already know, then we can do something more aggressive to
mail from strangers like hashcash, C/R, or cranked up filters, and if
a stranger jumps through our hoops, then add them to the list of known
people.

Recognizing mail from known correspondents is a very thoroughly solved
problem.  If I were doing it, I would use S/MIME, not because I am
particularly fond of S/MIME, but because it is already implemented in
all the popular MUAs, so you can skip the "if only the six largest
mail vendors implemented it" stuff, they already do.

But the spam problem is not the same as the introduction problem.  They
are somewhat related, since it is certainly true that people who have a
history of sending non-spammy mail will probably continue to do so,
but there's all sorts of real but complex situations that it doesn't
deal with at all well, with discussion lists like this one leading
the pack.

R's,
John

---

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 1 Sep 2006 11:19:27 -0400

On 1 Sep 2006 05:39:02 -0000, John Levine <[email-masked]> wrote:

> problem.

I agree, yet my system is designed to recognize mail from unknown sources.
Strangers will frequently send mail without using a sub-address.  This mail
will only get bounced if it receives a poor score via a filter.  If the
stranger is using a popular MUA then the bounce is resent and successfully
received without either party being aware that it was bounced in the first
place (assuming that the popular MUAs have updated their software).

As a last resort the stranger can manually 'Reply' to the bounce if his MUA
isn't updated.  This situation, however, is unlikely as there is an
amazingly minuscule number of popular MUAs.

> deal with at all well, with discussion lists like this one leading

Again, updates by a minuscule number of MUAs effectively eliminates the
introduction problem for this system.  Discussion lists like this one would
never face the introduction problem if the administrator used one of the
popular MUAs (again assuming that the popular MUAs have updated their
software).

Regarding an earlier question of creating and tracking combinatorials:
individual systems can decide for themselves if it is too complex to send
multiple sub-addresses to the recipients of a group email.  The efficacy of
this system will not suffer much if only one sub-address is sent out with a
group email.  Tracking all of the sub-addresses does not strike me as a
strenuous task in an age where we have email systems that hash every email.

Michael

---

From: John Levine <[email-masked]>
Date: 1 Sep 2006 15:50:01 -0000

>I agree, yet my system is designed to recognize mail from unknown sources.

I don't see you proposing anything that S/MIME doesn't do better.  If
you S/MIME sign all your mail, each message has the key that
recipients need to recognize future mail from you, and existing MUA
address books already support it.

>> But the spam problem is not the same as the introduction problem. ...

>popular MUAs

Right, so if I am a spammer, I need only subscribe to high-traffic lists,
collect the subaddresses as they come by, and then blast away.

> Tracking all of the sub-addresses does not strike me as a

This might be a good time to review the difference between O(N) and O(N^2).

Incidentally, if you think this is such a good idea, why don't you
write a Thunderbird add-in to support it?  It's all open source, you
know.

R's,
John

---

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 1 Sep 2006 14:46:21 -0400

> address books already support it.

I will illustrate by example.  You receive an email from a stranger.  As is
often the case the email is not authenticated by DKIM or Sender ID, it isn't
S/MIME signed, and it isn't using a sub-address.  Your filter rates this
email as having an intermediate risk for being spam.

Under my system this email would be bounced back to the sender along with a
sub-address.  The sender's MUA will likely be updated to resend this bounce,
but if it isn't then all is not lost as the sender has the opportunity to
manually resend the bounce.  The stranger's email is now authenticated.  I
don't think that S/MIME is able to reproduce these functions.

> collect the subaddresses as they come by, and then blast away.

Life would be good if I knew that all of the spam I received was the result
of my belonging to a single discussion list.  I might demand that the list
operator not publicly disclose any of my sub-addresses.  There are many
other viable ways to address the continued harvesting of emails from a
single clearly identified source.  The list operator may find his domain on
the suspicious list if he continually supplies spammers with sub-addresses.

Michael

---

From: "David Nicol" <[email-masked]>
Date: Fri, 1 Sep 2006 14:49:37 -0500

> don't think that S/MIME is able to reproduce these functions.

A shared centralized challenge-response system, which could be the beginning
of the reputation infrastructure that gets talked about here, would do the same
thing with fewer steps for the senders and no software upgrades required.

As I understand it, any proposal that requires some kind of zero-day
during which
everyone on the internet is mandated to upgrade their MUAs in order for it
to work is a non-starter.

Is your work a step towards a distributable reputation infrastructure?

Please refer to http://www.rhyolite.com/anti-spam/you-might-be.html

---

From: John Levine <[email-masked]>
Date: 1 Sep 2006 20:19:18 -0000

>> >I agree, yet my system is designed to recognize mail from unknown

It's the same problem -- the mail that's not from known correspondents is
from unknown sources.

>I don't think that S/MIME is able to reproduce these functions.

S/MIME recognizes the known corrspondents.  You've added on a C/R
layer for everyone else.  See the ASRG archives for lengthy
discussions of all the reasons that C/R is a bad idea.

R's,
John

---

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 1 Sep 2006 16:56:48 -0400

On 9/1/06, David Nicol <[email-masked] > wrote:
>
> On 9/1/06, Michael Kaplan < [email-masked] > wrote:

This proposal does not require any kind of zero-day.  It combines the
advantages of a Bayesian filter and a sub-address based email system to
ensure that challenges are only seen sent for a small fraction of legitimate
mail.  Updating the MUAs is only essential to make this system universally
transparent.

Ideally it would be great if the 10 largest MUA developers made this rather
simplistic upgrade, then maybe a year later this system would be deployed.
This system would not be a C/R system for any of the vast majority of people
with an updated MUA.  It would not be a C/R system for anyone sending
non-spammy email.

Again, I contrast the tremendous ease of deploying Auto-Reply software with
the impossible task of the near universal deployment of DKIM or SPF.  The
challenge will only apply to the ever diminishing number of emails that fall
through the cracks.

C/R systems are not desirable, but I argue that there comes a point where if
the challenge becomes so infrequent (1 out of 200 legit email?) that the
undesirability of C/R fades along with the appropriateness of calling it
C/R.  The question is can this system block spam and make challenges so
infrequent that we have reached the point where it is desirable.

Michael

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 23:27:59 +0200

Michael Kaplan wrote:

> I will illustrate by example. You receive an email from a
> stranger. As is often the case the email is not authenticated
> by DKIM or Sender ID, it isn't S/MIME signed, and it isn't
> using a sub-address. Your filter rates this email as having
> an intermediate risk for being spam. Under my system this
> email would be bounced back to the sender

That's technically impossible, unless you forgot to mention
that it had an SPF PASS.  Otherwise you participate with over
95% probability in DDoS or other net abuse, sending mails to
innocent bystanders.

---

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 1 Sep 2006 21:39:59 -0400

> 95% probability in DDoS or other net abuse, sending mails to

Your argument is not unique to my proposal but it is directed against all
bounces, vacation messages, etc.  It is certainly not technically
impossible, but I assume you mean undesirable.  Existing methods such as
BATV can easily protect mail systems from this problem.  The Auto-Reply
update to MUAs will block erroneous bounces for almost the entire global
email population.

It is highly unlikely that email with an SPF PASS would get bounced.

The receipt of erroneous bounces would annoy some (mostly victims of Joe
jobs) but, ironically, it would accelerate the adoption of BATV and the
Auto-Reply update for MUAs.

I suggest that when debating an anti-spam proposal we should answer
questions in a certain order:
1st - If implemented will it actually stop spam?
2nd - Is it practical to implement?
3rd - Is it unacceptably burdensome to the sender/recipient?
4th - Is it unacceptably burdensome to third parties?

Thank you for your input,
Michael
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 2 Sep 2006 02:39:15 -0000

>Your argument is not unique to my proposal but it is directed against
>all bounces, vacation messages, etc.

Right.  You don't want to send a response unless you know a message
isn't spam, but if you already know it's not spam, there isn't much
point in sending a C/R challenge, is there?

Incidentally, it occurs to me that S/MIME addresses the introduction
problem at least as well as your hack.  Remember that S/MIME uses
hierarchical signed certificates just like SSL, and MUAs typically
have a list of well-known S/MIME signers just like the list of well
known SSL signers, more often than not the same list.  All of the
signers make some desultory effort to ensure that that they only sign
certs that belong to the address on the cert, typically by mailing out
a token that you need to use to claim your cert.

Anyone with a signed cert has jumped through a hoop at least as
difficult as responding to a C/R challenge.  If you whitelist all mail
with signed certs, and tell people to get an S/MIME cert if they want
to talk to you (they're free, after all), that solves the same
problems as your scheme, with added benefits of preventing snooping in
transit in the common case that the sender knows your cert, too.  And
it's already available in Outlook, Outlook Express, Eudora,
Thunderbird, and probably lots of other MUAs I haven't looked at.
What are you waiting for?

> Existing methods such as BATV can easily protect mail systems from
> this problem.  The Auto-Reply update to MUAs will block erroneous
> bounces for almost the entire global email population.

You keep waving your hands and assuming that everyone will implement
your stuff.  I think BATV is swell, and I've been running it longer
than anyone else, but I am under no illusions about how slow its
uptake has been.  If I were king and could demand that everyone in the
world implement my favorite mail hacks, I would mandate a whole lot
more interesting stuff than some subaddresses and C/R challenges.

R's,
John

---

From: "Michael Kaplan" <[email-masked]>
Date: Sat, 2 Sep 2006 01:35:06 -0400

> point in sending a C/R challenge, is there?

My website states that the bounce would only be sent to email that has an
intermediate risk of being spam.

> What are you waiting for?

I support any means by which MUAs can be used to authenticate email, and it
would be fantastic to see S/MIME signing.  Obviously any signed email would
almost certainly bypass the need for a challenge and successfully reach the
inbox.  There are two main reasons why I promote issuing bounces with
sub-addresses as described on my site:

1) Multiple senders can use the same sub-address thus reducing the frequency
with which bounces are issued.  I can send an email to
[email-masked] I may get a reply from
[email-masked].  [email-masked] is a stranger yet the his email
will almost certainly reach my inbox unimpeded as he is using the valid
sub-address issued to Support.  As my site states "Experience with other
sub-address generating systems suggests that 90-97% of all legitimate email
uses a sub-address that is not used by spammers."  Spammers will acquire
only a fraction of issued sub-addresses.

My system is not identical to other sub-address based systems but the
principle is the same.  A single one of my sub-address can be forwarded to
multiple strangers who can use it to email me.  It is highly unlikely that
emails from these strangers will generate a bounce.

2) Correspondents with MUAs that lack Auto-Reply can manually resend the
bounce, thus authenticating their email.  There is no zero-day when every
single MUA in the world must be updated for this system to work.  This
system can authenticate every email from day one.  The level of
participation for MUAs only effects the transparency of this system.

So S/MIME is good, but I'm not sure that it can substitute the above.  I'm
also not sure how the mechanism of "tell people to get an S/MIME cert if
they want to talk to you" would work.

C/R systems are extraordinarily effective at eliminating spam yet they are
equally annoying.   I've tried to preserve as much of efficacy of C/R as
possible and yet with a combination of Bayesian filters, sub-addresses, and
Auto-Reply I've tried to produce a system that will challenge so
infrequently that its deployment is justified.  A respectable Bayesian
filter might have a 0.5% false positive rate.  Under this system 0.5% of
correspondents might see a bounce/challenge while almost completely
eliminating spam.  If this were to happen then the annoyance of this "C/R"
system would certainly be less than the status quo.

---

From: "Michael Kaplan" <[email-masked]>
Date: Sat, 2 Sep 2006 11:09:05 -0400

On 9/2/06, Jeff Macdonald <[email-masked]> wrote:
>
> On Thu, Aug 31, 2006 at 11:43:25PM -0400, Michael Kaplan wrote:
> >    [1]http://home.nyc.rr.com/spamsolution/UniversalAuthentication.htm
>
> So am I missing something, why doesn't a MTA/MDA need to be changed to
> support sub-addresses? Isn't every sub-address a new mailbox?

As with existing sub-address systems any network that wants to take
advantage of this system (PER-CORRESPONDENT ADDRESS combined with
CHALLENGE/RESPONSE subflavor MUA
AUTO-RESPONSE as it has been called) will need to install it on an
individual basis.  My hope is that this system will be so effective and
non-disruptive that an increasing number of mail systems will choose to
implement it.

When I said that this system "does not require email users to change their
behavior" I was referring to the average user, not the system administrator
who would obviously need to install it.

Michael

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 03 Sep 2006 00:37:49 +0200

Michael Kaplan wrote:

 [bounced back to the sender == technically impossible]
> Your argument is not unique to my proposal but it is directed
> against all bounces, vacation messages,

Yes, almost all auto-replies covered by RFC 3864, unsolicited
DSNs, the works.

> It is certainly not technically impossible, but I assume you
> mean undesirable.

No, I meant "impossible", because you don't know who the sender
is.  If you got an SPF PASS (or any equivalent indication that
the Return-Path is no nonsense) that person might consider your
procedure as "undesirable", but that's nobody else's business.

For your case "unknown stranger" the default is that you just
have no clue who the sender is.  At that point you've already
filtered your inbox, all "known good guys" either made it, or
you reject it as trivial forgery.  Let's say 80% of your ham.

All "more than intermediate spam likelihood" is also out, that
is 50% of your spam.   So if your inbound is 5% ham, 84% spam,
and 11% misdirected bounces, then your filtered inbound is:

1)   4% "identified ham"  (80% of  "5"), already in your inbox
2)  42% "identified spam" (50% of "84"), dropped or rejected
3)  11% "misdirected bounces", let's say you drop this unread
4)  42% "unidentified spam" (rest of 84) gets a challenge
5)   1% "unidentified ham" (rest of 5) also gets a challenge

Therefore about 42 of 43 challenges hit innocent bystanders.

Smart spammers probably abuse "plausible" Return-Paths, with
"plausible" = survives call-back-verification (tests arriving
as apparently empty spam), and they might also avoid SPF FAIL
paths.

If they're not so smart they probably ended up in your first
42% of "identified spam", because you could as well test this.

If the ratio is 42 of 43, or only 40 of 43, whatever, you end
up with huge amounts of spam (unsolicited challenges are spam)
sent by you.

The typical plan B for those who think that SPF is not really
necessary would be a separate IP used to send your backscatter.

If that IP is blocked your challenges will be rejected on their
way (maybe including the one you're really interested in), and
the problem is solved.

I don't see a working system here, same problem as in RFC 2821.

> Existing methods such as BATV can easily protect mail systems
> from this problem.

BATV works if a Return-Path is bound to mailouts and MXs in the
same mail originating / receiving network.  The relevant MXs
have to know which Return-Paths were created by corresponding
mailouts.  BATV is a kind of hardcore SPF, the senders enforce
their own policy wrt bounces.  Or rather the MDA has to know
which Return-Paths were actually sent, anything else can be
dropped.  Reject at the MX might be better, but not required.

If your system is "BATV-ready" it MUST use an empty Return-Path
in its challenges, the other methods mentioned by RFC 3864 work
only after DATA in SMTP (or after HEAD if that draft makes it).

A system only working if the whole world deploys BATV or SPF
(if you take the latter into account in your filtering) is IMHO
premature.  You'd have to wait until you get a ratio "1 of 43"
instead of "42 of 43", and then the "1" is still an unsolicited
challenge.

> It is highly unlikely that email with an SPF PASS would get

That's no real problem, after all an SPF PASS is a guarantee
that bounces won't hit innocent bystanders.  If the sender does
not like your challenge (s)he can "just hit del" and be done
with it.

> The receipt of erroneous bounces would annoy some (mostly
> victims of Joe jobs)

Let's reserve the term "Joe Job" for something more serious
than "84% of mail are spam with plausible forged Return-Paths",
that's the reason for "11% of mails are misdirected bounces".

I'd wish I could remember where I read this 84+11+5 = 100, it
was this year, and not a too obscure source (e.g. not nanae).

> but, ironically, it would accelerate the adoption of BATV

I doubt it.  Folks thinking that SPF is too restrictive won't
like the more restrictive BATV.  If you can identify BATV or
SPF PASS, and limit your bounces to these cases, you won't run
into trouble.

Maybe SPF should offer a BATV flag:  "All Return-Paths with
this domain are BATV-protected (and anything else is forged)".

But actually the BATV-sender knows which local parts are okay,
a sender policy "v=spf1 exists:%l.%d -all" or similar allows
receivers to get a clear PASS or FAIL (without any forwarding
issues).  Anybody supporting BATV could also support this kind
of sender policy (IIRC that was the or a part of the SES idea).

But that's not yet the case, and it could take a decade until
deployment allows you to ignore "the rest of the world".  With
a good chance that it will never happen.

> 1st - If implemented will it actually stop spam?

"Works after worldwide deployment" - one of the FUSSP points.

> 2nd - Is it practical to implement?

If that boils down to "can receivers identify BATV local parts
with sufficient certainity" I can't tell.  Identifying an SPF
PASS is a solved problem.

> 3rd - Is it unacceptably burdensome to the sender/recipient?

Some don't like BATV and/or SPF.  In your original article you
mentioned other schemes (SenderID PASS + DKIM PASS) where you
never send a bounce (?).  Maybe it's acceptable that senders
pick one or more of these schemes as it pleases them.

> 4th - Is it unacceptably burdensome to third parties?

"42 of 43 challenges are unsolicited" wouldn't be good enough.

Frank

---

From: der Mouse <[email-masked]>
Date: Sun, 3 Sep 2006 00:30:36 -0400 (EDT)

> For your case "unknown stranger" the default is that you just have no
> clue who the sender is.

If I might be forgiven a slight nitpick, you actually have a 20% chance
of knowing who the sender is (assuming an 80% spam figure).

I call this a nitpick because while it is definitely better than having
"no clue", it is not good enough to be useful in a practical sense.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Michael Kaplan" <[email-masked]>
Date: Sun, 3 Sep 2006 16:25:34 -0400

> Yes, almost all auto-replies covered by RFC 3864, unsolicited

I accept the fact that many individuals feel very passionately about the
auto-reply issue but I hope you would acknowledge that your sentiment is a
minority position not shared by a vast number of reputable top email
companies that frequently enable it in one fashion or another.  Officially
the IETF does not consider the auto-reply provisions of RFC 3864 abuse
either.  Rather than reiterate the concept of "any system that employs any
automated response is absolutely unacceptable" I'd like for us to look
beyond that for now - we know that the major email companies will certainly
look beyond it.  Can we at least look beyond this issue for arguments sake?

> Therefore about 42 of 43 challenges hit innocent bystanders.

I think you underestimate the discriminating power of Bayesian filters.
Check out the last figure on the SpamBayes website:

http://spambayes.sourceforge.net/background.html

As you can see almost all ham is unambiguously classified as ham, while
almost all spam is unambiguously classified as spam.  So 50% of spam is not
given an intermediate rating; the figure is no where even close to that.
The intermediate rated email between the two extremes makes up a small
percentage of the total volume of email.  This is the small percentage that
I would bounce.

I don't believe that everyday filter data produces results as distinct as
seen on the SpamBayes website, but the general concept holds.  How about if
we bounce the 10% least spammy mail that otherwise would have gone to the
junk folder as well as 5% of the most spammy mail that would have gone into
the inbox?  I won't say that this will result in a final result of 0% false
negatives and positives, but I argue that it will yield a final false
negative and false positive rate substantively better than you would get
just by using a filter.

Your calculation also assumes that 100% of spam spoofs a real email
address.  A substantial amount (the vast majority??) of spam uses randomly
generated addresses.

> instead of "42 of 43", and then the "1" is still an unsolicited

I suggested BATV as part of 'belt and suspenders' approach to distribution
of auto-reply software.  As I stated distribution of Auto-Reply will be more
effective when done at the level of the MUA.  Every MUA has filtering
ability, so I suggest correlating incoming bounces with recent outgoing mail
and filtering bounces that don't correspond.

> that's the reason for "11% of mails are misdirected bounces".

I used the term Joe Job because I suspect that the problem of erroneous
bounces is exaggerated.  I say this because of the dearth of literature
(beyond anecdotal reports) that even mentions it as a problem.  I see tons
of reports such as the follow recent addition:

http://weblog.infoworld.com/techwatch/archives/007730.html

I've never seen a breakdown that included a category for erroneous bounces.
I know that John Levine has been plagued by this issue, but I would classify
his problem as Joe Jobbing.  I suspect that much of the foot dragging on
BATV is because it addresses a problem that most people don't have.  If you
can site any literature on this issue then I would certainly appreciate it.

> "Works after worldwide deployment" - one of the FUSSP points.

I've already gone over in detail that "worldwide deployment" is completely
unnecessary

> pick one or more of these schemes as it pleases them.

Again my system is primarily focused on authenticating email that has no
authentication.  I (and almost every major company) disagree with the
concept that you can't send an automated response to an email unless that
email was authenticated.  Given this I propose sending an auto-reply in the
most selective fashion possible.

> "42 of 43 challenges are unsolicited" wouldn't be good enough.

see above

Thank you for your input
Michael

---

From: John Levine <[email-masked]>
Date: 3 Sep 2006 22:09:02 -0000

>companies that frequently enable it in one fashion or another.

No, we will not acknowledge that because it is not true.  We all know
that Exchange has a widely despised "I'm out of the office so come rob
my house" feature, but it's hardly the only bad idea you'll find in
Microsoft's mail software.

AOL has spent quite a lot of time and money reworking their mail
system so it does NOT send bounces and other auto-response messages,
but instead rejects undeliverable mail with SMTP 5xx codes.  This is
precisely because of the spam blowback problems we have all been
telling you about.

In any event, as you surely know, the IETF's motto is rough consensus
and running code.  Go write some running code and tell us how it
works.  I hear that Thunderbird plugins aren't all that hard to write.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 04 Sep 2006 02:24:35 +0200

Michael Kaplan wrote:

> I hope you would acknowledge that your sentiment is a
> minority position not shared by a vast number of reputable
> top email companies that frequently enable it in one fashion
> or another. Officially the IETF does not consider the 
> auto-reply provisions of RFC 3864 abuse either.

Apparently we have a communication problem here:  I support
RFC 3864, it's one of the best RFCs I know, and I seriously
hope that it progresses to a full Internet standard.

It does however (like all non-delivery reports) depend on a
single premise:  Return-Paths must be no nonsense.  For the
old (pre-1123) SMTP that was "guaranteed" by design - as far
as those guarantees go, in theory it was a sound design.

Certainly the "SPF FAIL or PASS" folks including me are a
minority.  But without it stuff like RFC 3864 (incl. your
proposals) and NDRs can't work anymore, because the flood of
unsolicited auto-replies (incl. bounces) forces receivers to
block or drop them.

Anybody who used mail in one of the more obscure positions
like an unofficial UUCP link five hops from the Internet or
a Fido node behind various gateways to the rfc822-world,
would tell you that (store and forward) mail cannot work
without error reports (NDRs).

As soon as bounces are dropped wholesale the complete system
breaks together, mail vanishes in black holes.  SMTP is too
"simple" to work without error reports.  Today it's already
almost normal to confirm the arrival of important mail by
phone calls.  This is worse than a decade ago, where I could
trust that the Fido-gateway or UUCP-link might be slow, but
generally reliable.

So in other words I strongly believe in "good bounces", and
an SPF PASS is not only a permission to send eror reports if
necessary, it's a plea.  Like the opposite SPF FAIL is not
only a permission to reject forged mails.  Anybody seriously
considering SPF FAIL as an indicator to drop mails missed the
point.  Reject and drop are different.

> I'd like for us to look beyond that for now - we know that
> the major email companies will certainly look beyond it.

As far as I'm concerned you can get it right, do whatever you
like if you get an SPF PASS, and reject FAIL.  For BATV I've
no clue how you identify it, or how you could know that it's
missing.  But as you said those are minorities today, for the
vast majority sending challenges to unverified Return-Paths
won't fly.

A system that works only if the whole world uses BATV or SPF
is exactly as relevant as a system assuming that the whole 
world implements STD 10 verbatim (without the RFC 1123 bug):
It's a wrong premise.

> I think you underestimate the discriminating power of

Possible.  Feel free to fix the numbers, raw 5+11+84, filtered
(4+1)+11+(42+42).  If your definition of "intermediate spam
likelihood" is 25:75 instead of 50:50 you get (4+1)+11+(63+21).

With that you'd arrive at 1+21 challenges (21 unsolicited).
42 of 43 was 97%, 21 of 22 is 95%.  I've offered 40 of 43 (93%)
in the same article where I arrived at 42 of 43.  And der Mouse
has proposed 80%, that's conservative, showing that the details
don't matter:  80% unsolicited challenges won't work.  You'd be
blocked, and then your other challenges never make it.

> How about if we bounce the 10% least spammy mail

With the same scenario in permille that's (10+40)+110+(756+84)
for 84 unsolicited challenges of 94, you're down to 89% spam.
If that's realistic for your case I'm fine with these numbers,
but 89% of all challenges unsolicited is still quite a lot UBE.

> Your calculation also assumes that 100% of spam spoofs a real
> email address. 

Yes, if you use call-back-verification other addresses never
come near to your C/R system.  And if you don't do it the smart
spammers have done it.  Completely bogus addresses aren't very
interesting, you only need some disk space for your send queue
while you try (in vain) to send challenges to these addresses -
no problem.

> A substantial amount (the vast majority??) of spam uses
> randomly generated addresses.

That doesn't match my obsevations (catchall vanity domain):
The vast majority are parts of or complete Message-IDs, local
parts generated by Sober and other mail worms, and similar
cases, not completely random 1*63(ALPHA / DIGIT / "-" / more).
Any longer addresses I see are almost always real Message-IDs.
 
> I suggest correlating incoming bounces with recent outgoing
> mail and filtering bounces that don't correspond.

That's the BATV idea in a nutshell, doing it at the MUA has
its own challenges (not everybody can create Return-Paths on
the fly, other matching methods are tricky, and last but not
least ifit hits the mailbox before POP3 or IMAP the battle is
already almost lost, V90 users note it immediately, others
see it on their invoice if they pay by volume).

> I used the term Joe Job because I suspect that the problem of
> erroneous bounces is exaggerated.

I disagree.  Anybody who doesn't drop bounces unread has a
serious problem.  Less so for SPF FAIL folks, and almost ideal
for BATV users, but even then there are many "wannabe-bounces",
crap like Mailer-Daimon@ (sic).  In 2004, when SpamCop did not
allow to report bogus bounces, I tried to filter such crap for
some months, it was a PITA.  Since about two years my spammers
mainly got the idea of SPF FAIL, therefore it's under control
from my POV.

But I did note the two weeks in 2005 when they tested again to
forge my addresses.  Even today I'd still note it if there are
1000 bogus bounces per day in addition to the "normal" spam -
but fortunately (or thanks to SPF FAIL) that's not the case.

> I know that John Levine has been plagued by this issue, but I
> would classify his problem as Joe Jobbing.

He told us that he uses BATV, and I'd be very surprised if the
professional spammers don't read this list to stay up to date
(among a few others).  No "Joe Jobbing" in my book, an attempt
to (ab)use the reputation of abuse.net maybe.  

Without SPF FAIL the receivers can't identify "missing BATV" or
"invalid BATV", they'd need CSV or an emulation of it to reject
bogus "EHLO abuse net" sessions.  If that's what his box says,
...checking, no, not necessarily, it can be "EHLO iecc.com".  I
forgot the details how to check CSV for this.

> I suspect that much of the foot dragging on BATV is because
> it addresses a problem that most people don't have.

You'd only see it with a domain, on other addresses (no vanity
domain) I've seen it only in conjunction with mail worms (the
worms forged my address, and I got the backscatter), not spam.

> If you can site any literature on this issue then I would
> certainly appreciate it.

You might find some links in the related Wikipedia articles:
<http://en.wikipedia.org/wiki/Category:E-mail_authentication>
Caveat:  I had my fingers in some of those Wikipedia articles.

The most often quoted source I'm aware of is the Spamcop FAQ:
<http://www.spamcop.net/fom-serve/cache/329.html>

<http://www.clickz.com/showPage.html?page=3602516> quotes
Ironport, Messagelabs, and Postini, and if that's the source
where I saw 84% I wonder where I got the 11% - this article
says 9% misdirected bounces.  I'm too lazy to dig for the
original Ironport report, if you find it please post a link.

> "worldwide deployment" is completely unnecessary

Good.  You did however hint that anybody who doesn't like the
unsolicited challenges can deploy BATV, and I doubted that.

> I (and almost every major company) disagree with the concept
> that you can't send an automated response to an email unless
> that email was authenticated.

I guess we disagree about this, but as long as you reject all
SPF FAIL it won't affect me personally.  I won't mind if you
challenge an SPF PASS from me, I'm free to ignore it or to
answer it - depends on what I want, I answer challenges from
say ICANN or IANA (again and again... so far ;-).

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 04 Sep 2006 02:41:35 +0200

s/3864/3464/g  I also like 3864, but here I meant 3464, sorry.

---

From: "David Nicol" <[email-masked]>
Date: Mon, 4 Sep 2006 23:18:29 -0500

> this domain are BATV-protected (and anything else is forged)".

or BATV could declare a syntax to include in TXT records.  SPF is
too old by now to add features to, but I believe (could be wrong) that
it can co-exist in a TXT record with other things; if not example.net
coul declare its BATV record in -batv.example.net or something
although there's some BCP that gets violated when you start mandating
parts of names.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Sep 2006 08:58:06 +0200

David Nicol wrote:
 
> BATV could declare a syntax to include in TXT records

Yes.

> SPF is too old by now to add features to

No, you can add "modifiers", stuff like batv=what.ever.syntax

New "mechanisms" as in batv:syntax.ever.what would require a
new version, in essence a new tag at the begin of the TXT, as
in v=spf1 vs. spf2.0/pra.
 
> I believe (could be wrong) that it can co-exist in a TXT
> record with other things

Yes, a separate TXT or SPF record with its own tag.  You'd be
limited by the q=txt (or q=spf) response, the complete set has
to fit, same idea as for q=mx and several MX records.

Reviving the old SES idea could be fully integrated into SPF,
it can use its exists: mechanism (for that the sender needs a
name server answering queries about wannabe SES/BATV local
parts, forged or valid).  The BATV senders can identify valid
local parts (otherwise they couldn't reject bounces to forged
Return-Paths), but sharing that knowledge via DNS SPF exists:
with arbitrary receivers might be difficult...  or interesting
for bad actors, how can they abuse this.

With mail it's probably a good idea to write all new protocols
directly for the main mail users, the spammers.  With the less
frequent legit cases as (desired) side effects.

> there's some BCP that gets violated when you start mandating
> parts of names.

Maybe draft-iab-dns-choices-03.txt, but that's not yet a BCP.

The SRV records have name conventions, and IDNA uses xn-- and
reserves similar prefixes.  I can't tell how mandatory that is,
maybe I'm still free to create a label xn--what-ever, or this
depends on the TLD.  An interesting question... :-)

Frank

---

From: "Michael Kaplan" <[email-masked]>
Date: Sun, 10 Sep 2006 22:15:58 -0400

> say ICANN or IANA (again and again... so far ;-).

Thank you for the feedback.  Misdirected indiscriminant bounces are a major
problem, so it is natural to presume that a widely enacted anti-spam system
based on bounces would be absolutely disastrous.  But what if bounces were
not indiscriminant but were instead highly selective as I propose in a
system that has been referred to as PER-CORRESPONDENT ADDRESS combined with
CHALLENGE/RESPONSE sub-flavor MUA AUTO-RESPONSE?

I call attention to the Ironport report on bounces.  It provides the most
useful data on the bounce problem that I've seen so far.  The report is free
from:

http://www.ironport.com/company/ironport_pr_2006-04-24.html

To summarize the hard data:

-9% of global email traffic is misdirected bounce mail, 71% is
spam/viruses/phishing, and 20% is legitimate.

-Less than 0.5% of bounce messages make it through to the end user.

-20% or more of what a spammer sends is bounced because of invalid addresses

-55% of fortune 500 companies have experienced partial or total disruptions
of service due to bounce caused DDoS

-There are 4.5 billion misdirected bounce messages per day.  10% of these
have valid addresses resulting in 450 million reaching mailboxes each day.

For my system to be highly effective I will assume that one of the better
email filters is being used and that 4% of spam and 4% of ham gets bounced.
I pick these numbers as the graphs of filter performance at:

http://sam.holden.id.au/writings/spam2/

Allowing a 4% bounce rate of suspected ham and spam transforms the top
performing spam filters into nearly perfect filters.  Keep in mind that the
data from the above website was generated prior to current email
authentication practices, and of course it doesn't take into account the
fact that the use of sub-addresses on incoming mail will further improve
filter performance.  Filter performance would therefore likely be superior
when used for my proposed system.

The following is an analysis of how a properly implemented bounce based
anti-spam system would impact the areas that are of the most concern when we
think of misdirected bounces:

*Effect on global email traffic*
I will assume that 50% of global email accounts are protected by this
system.

(4% spam bounced)*(71% global spam)*(50% participation) = 1.42%

(4% ham bounced)*(20% global ham)*(50% participation) = 0.4%

50% of the global email population is almost totally protected from spam at
the cost of a 1.82% absolute increase in global email traffic.

*Effect on DDoS*
Currently if a spammer sends 100 million spam emails using the return
address of a single company then 20 million misdirected bounces would hit
that company's system.  We will generously assume that 80 million of these
spam emails target real addresses.  Assuming 50% of the global population
uses this system then:

(80 million)*(50%)*(4%) = 1.6 million additional emails will hit the
company's system resulting in a total of 21.6 million, an 8% increase in
bounce volume.

This 8% increase in volume during a DDoS is should be weighted against the
benefit of nearly totally blocking spam to 50% of the global population.

Actually a good filter is unlikely to mistake an unauthenticated email sent
from a dubious server with a legitimate email from a Fortune 500 company.
The true increase in the volume of bounce DDoS attacks for large companies
is likely much less or almost non-existent.

*Effect of diverting spam on the inboxes of third parties*
Again assuming 50% of the global population uses this system:

(50%)*(4%) = 2% relative increase in the amount of "spam" sent globally.

(2%)*(10% of spam that spoofs an existing 'From' address) = 0.2% relative
increase in global spam directed at real addresses.

50% of these misdirected spam bounces will target users of this system.
Since the sub-address reproduces the benefit of BATV users of this system
will be perfectly protected from these bounces.  So only the remaining 50%
of the global email population will face a 0.2% increase in the amount of
spam.

This also assumes that the third parties are not using other mechanisms,
such BATV, to stop bounces.  This bounce spam will still need to face all of
the anti-spam mechanisms of the third party; content filters will still be
able to evaluate the spammy material in the bounce.  The bounce will contain
the IP of the server that originated the spam so that the bounce recipient's
filter can evaluate its reputation.

On average we have at most a 0.2% increase in the average spam burden among
nonusers of this system.  As with DDoS attacks a small number of individuals
may be disproportionately affected, but as with the DDoS example above these
individuals will face at most an 8% increase in the amount of bounce spam.
This slight increase in the amount of spam received by a small fraction of
users is again weighted against the benefit of 50% of the population being
free of spam.

Michael Kaplan