On 9/2/06, Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
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.
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?
> 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.
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.
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.
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.
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 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.
> 1st - If implemented will it actually stop spam?
"Works after worldwide deployment" - one of the FUSSP points.
I've already gone over in detail that "worldwide deployment" is completely
unnecessary
> 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.
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.
> 4th - Is it unacceptably burdensome to third parties?
"42 of 43 challenges are unsolicited" wouldn't be good enough.
see above
Thank you for your input
Michael
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg