Subject: Re: [Asrg] Please critique my anti-spam system

From: "Michael Kaplan" <[email-masked]>
Date: Fri, 07 Jan 2005 11:30:48 -0500

> > No innocent user will ever get an erroneous bounce if a few of the
> > large consumer ISP adopt the system;
> 
> I must admit I find this statement utterly incomprehensible - or more
> precisely, I find the idea that anyone of your obvious intelligence
> could believe it utterly incomprehensible.  How will - how *could* - "a
> few of the large consumer ISPs" adopting your system, or any other,
> prevent a small site handling its own mail in, say, San Jose, from
> sending an erroneous bounce to a user at a small site handling its own
> mail in, say, Ottawa?

I was unclear.  What I meant was that it would be a simple matter for
and email provider to recognize a bounce sent via my system.  The email
provider could then check to see if the recipient had previously sent out
an email to the supposed source of the bounce.  If the recipient had not
sent out this earlier email then the bounce that is coming in must obviously
be an erroneous bounce and it would then be blocked.  Now there is no chance
that anyone would receive an erroneous bounce.  In your example above the
small site in San Jose would still send out the erroneous bounce, it's just
that the small site in Ottawa would filter it out before the user ever saw it.

If my system is used on a small scale then I would not expect any email
provider to lift a finger to adjust their system to filter out these erroneous
emails.  If, however, some of the large consumer email providers used this
system then I believe that most other email providers would recognize this 
system and begin filtering out erroneous bounces as described above.

Michael Kaplan
-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 7 Jan 2005 12:03:17 -0500 (EST)

"Michael Kaplan" <[email-masked]> wrote:

> I was unclear.  What I meant was that it would be a simple matter
> for and email provider to recognize a bounce sent via my system.
> The email provider could then check to see if the recipient had
> previously sent out an email to the supposed source of the bounce.

How could panix check to see if I've sent email, using my
[email-masked] address, via some other MTA (not in Panix's network)?
I certainly _can_ do that (though SPF would fail).

Seth

---

From: Richard Welty <[email-masked]>
Date: Fri, 7 Jan 2005 19:20:15 -0500 (EST)

> I certainly can do that (though SPF would fail).

i happen to agree with seth, and don't think there's a good way of
handling this, but supposing you could, there's still another one that
comes next.

for a sufficiently large ISP (think AOL, or a cable modem business),
keeping track of the tuples of <sender, recipient> for any length of time
will require a _substantial_ database infrastructure.

i was going to do some back-of-envelope computations on sizing, but
this is your proposal, mitch, so why don't you do them and share the
results with us.

richard
-- 
Richard Welty                                         [email-masked]
Averill Park Networking                                         518-573-7592
    Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

---

From: der Mouse <[email-masked]>
Date: Fri, 7 Jan 2005 17:05:10 -0500 (EST)

>> [???]
> and email provider to recognize a bounce sent via my system.

Yes, though it's questionable whether anyone would want to implement
special-case recognition for every new C/R challenge out there.  I
certainly am not interested in doing so.

Perhaps this needs to be another FUSSP criterion: "it assumes it's the
only system in use, or at least that everyone will be willing to add
special cases for it".

> previously sent out an email to the supposed source of the bounce.

So, no more road-warrior outgoing email?  All must be tunneled back to
home?  (Nothing wrong with that per se, but it certainly could be made
clearer, as it will be an important caveat.)

> If the recipient had not sent out this earlier email then the bounce
> that is coming in must obviously be an erroneous bounce and it would
> then be blocked.  Now there is no chance that anyone would receive an
> erroneous bounce.

Well, no.  Not anyone.  Only people behind such checks.

> If my system is used on a small scale then I would not expect any
> email provider to lift a finger to adjust their system to filter out
> these erroneous emails.  If, however, some of the large consumer
> email providers used this system then I believe that most other email
> providers would recognize this system and begin filtering out
> erroneous bounces as described above.

Yes - but that can be done without needing your system.  My mailer
already rejects most bounces of mail I didn't send.  ("Most" because
the check it does is a relatively weak one and every once in a while it
mistakes a forgery for mail I sent.  So far this has not happened
frequently enough to make me soup up the check.)  Of course, this
depends on all mail I send exhibiting certain characteristics, which I
make sure it does.

/~\ 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: Seth Breidbart <[email-masked]>
Date: Fri, 7 Jan 2005 20:02:31 -0500 (EST)

> this is your proposal, mitch, so why don't you do them and share the

Under 1K of data.  Remembering stuff is doing it the hard way.  Create
the lhs of the Message-ID signed with a private key that changes
daily.  If the "response" doesn't have one you could have generated
recently, it's bogus.

Seth

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 8 Jan 2005 13:15:07 +0100

On 2005-01-07 20:02:31 -0500, Seth Breidbart wrote:
> daily.

That assumes that the Message-ID is created by the MTA. Many MUAs create
the Message-ID themselves, and the MTA should not (indeed must not, per
RFC 2476 and 2821, if it is syntactically correct) replace it, because
that would make the "In-Reply-To" and "References" headers useless.

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 8 Jan 2005 14:17:49 +0100

> that would make the "In-Reply-To" and "References" headers useless.

However, the ENVID introduced in RFC 1891 (current version: RFC 3461) 
may be generated in that way.

Would that be feasible? 

* Do MUAs generate ENVIDs?

* Which percentage of bounces contains the ENVID?

Looks like I should do a bit of research on our mail server :-)

	hp

---

From: John Levine <[email-masked]>
Date: 8 Jan 2005 16:53:08 -0000

>only system in use, or at least that everyone will be willing to add

Gee, that would include SPF, wouldn't it?

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 8 Jan 2005 18:52:44 +0100

> and email provider to recognize a bounce sent via my system.

And for the gazillion of similar schemes, too? The examples on your web
site don't look like standard DSNs (you don't even say if the "bounces"
are sent with an empty envelope from or with <[email-masked]>
as the mail headers suggest), they look like free form text. Currently
everybody implementing your scheme is very likely to generate different
bounce messages - and from experience with handling bogus "a mail you
sent was blocked because of a virus" messages I can tell you that they
are not easy to recognize. 

> previously sent out an email to the supposed source of the bounce.  If
> the recipient had not sent out this earlier email then the bounce that
> is coming in must obviously be an erroneous bounce and it would then
> be blocked.

The supposed source of the bounce is <[email-masked]>.
Assuming you mean the failed address, how does the MTA get that? Is it
supposed to parse the English sentence "The following message that you
sent to [email-masked] was blocked ..." (and its Chinese translation)?
Please use at least an already standardized format for DSNs (sie RFC
3461) if you want at least a small chance that MTAs will behave as you
expect them to behave.

> Now there is no chance that anyone would receive an erroneous bounce.
> In your example above the small site in San Jose would still send out
> the erroneous bounce, it's just that the small site in Ottawa would
> filter it out before the user ever saw it.

More likely the use would see a flurry of such bounces, complain to his
provider, and the provider would block them MTA of the small site in San
Jose completely (and report it to several RBLs). No more erroneous
bounces, but no more legitimate mails either.

> emails.

They will, if they are annoyed enough. But they won't bother to filter
out only erroneous bounces - they will either filter out all messages
generated by your software or all from the host sending the bounces.
Either way users of your software will find that they can't send mail to
some addresses any more.

	hp

---

From: der Mouse <[email-masked]>
Date: Sat, 8 Jan 2005 22:03:09 -0500 (EST)

>> Perhaps this needs to be another FUSSP criterion: "it assumes it's
>> the only system in use, or at least that everyone will be willing to
>> add special cases for it".

Why yes, actually, it would.

Funny, that, innit?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Seth Breidbart <[email-masked]>
Date: Sun, 9 Jan 2005 00:48:46 -0500 (EST)

"Peter J. Holzer" <[email-masked]> wrote:
>> > keeping track of the tuples of <sender, recipient> for any length of ti=
> me
>>=20

You're right.  They'd have to remember it in that case.  However, AOL
(specifically) wouldn't have that problem.

They can also play games either with md5 or hash tables, so the amount
they have to remember is a lot less.  It doesn't matter much if there
are a few false positives.

Seth