Subject: RE: [Asrg] Ban the bounce; improved challenge-response systems

From: "Sauer, Damon" <[email-masked]>
Date: Mon, 7 Apr 2003 10:05:52 -0400

>> 
>> >On 6 Apr 2003, wayne wrote:
>> 
>> >> In <20030406042307.GC994@m1800> [email-masked] writes:
>> >> 
>> >> 
>> 
> >Could the receiving MTA, when it must send a DSN, restrict itself to
> connecting to the
> >connecting MTA or one of its MXs? In that case a forged envelope from 
> >would
> typically
> >result in a "relay denied" rather than sending the DSN to an innocent 
> >third
> party. If the >envelope from was in a domain that the connecting MX 
> serviced, presumably it would accept >and deliver the DSN. If the 
> spammer forged addresses in the scope of the connecting MTA, >the DSN 
> would still go through, of course, but the burden would be on the 
> "legitimate"
> >users of the MTA, which would encourage relays to be closed and 
> >spammer's
> accounts to be >canceled.
> 
>  If I understand what you are saying correctly, you are saying that a 
> DSN should be returned to the sending IP. (I am not sure how you would 
> be able to parse correctly the MX from the reporting IP or hostname of 
> the connecting server.)  While I agree with what you are saying on 
> merit, this would unfortunately break many large SMTP implementations. 
> Many mailers are "outgoing" only and buried deep inside an intranet. 
> Saying that all MTAs MUST be able to receive DSN's would be 
> restrictive to current SMTP implementations and require substantial 
> changes in SMTP routing design of many current networks.

->The MTA wishing to send a DSN would do a reverse dns lookup on the
connecting MTA, then find the appropriate MX record, ->or use the A record
if none were found. 

->I understand that many large sites are too busy to support RDNS, or to add
an MX record for their MTAs, in which case
->they might miss some DSN traffic. It would be up to them. At some future
date, they could hire additional engineers to 
->handle the project.

->Seriously, I realize that half of sites don't have RDNS, but the A record
will accept mail for nearly all of those sites. ->And it is no tragedy if it
doesn't, it is their choice and must be respected.

As I understand the RMX or rDNS proposal... A reverse lookup might yield a
ip address, which would work in this instance or in the case of domains with
multiple MTA's, just a subneted address range, which would not work.

Damon

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Apr 2003 10:41:29 -0700

> About half of spam in my inbox has a "hotmail" or "yahoo" 
> return address. 
> I wouldn't bounce a message to that address based on content, although
> I realize that the address is unlikely to be active. 

That is the rough figure we see. Does any of that spam
actually come from that source though?

> >   2. many are of innocent third parties.
> 
> I don't know how many are innocent third parties. I get a few bounces
> every week as an innocent third party myself, but I don't 
> know if that is
> typical. It may reflect the fact that most content based 
> scanners don't
> bounce mail. 

I get no bounces from content scanners, but I get a lot 
from the mail systems themselves trying to deliver to 
non-existent addresses.

> >   3. "content based spam detectors" must use bounces to 
> indicate false
> >       positives instead of STMP status codes.
> 
> I agree they don't have to. But none of the scanners 
> presented at the MIT spam conference could.

I don't think that is practical. Very few sites could afford 
to put in place the level of processing required to be able
to support their peak mail throughput. Being able to delay 
messages by up to five minutes cuts the processing requirements
to a tenth, or better.

What I would like to see though is a modification of the
way the bounces are reported. I would like to see a header
that specifies the SMTP status codes that would have been
returned. This then allows the client to process the bounce
in a sensible fashion from a UI standpoint.

My point is that the users should NEVER see signalling data.
There should not be a UI difference between messages handled
inband and those handled asynchronously.

	Phill

---

From: "Bob Atkinson" <[email-masked]>
Date: Tue, 8 Apr 2003 15:49:03 -0700

The well-put good design principles notwithstanding, a troublesome and
unfortunate thorn here is that of the scale of the problem.

Today, worldwide email traffic is (very) roughly 10 billion messages a
day, or at least close enough to that for me to make my point. Of that
there's good evidence that half or more is actually spam. 

If all this spam were detected and bounced (or even a substantial
fraction), then we're looking at *significant* increase in the overall
volume of email, at least in the short term until spam disappears :-).

And, to the extent that not all sites are evenly affected, the increase
in burden of outbound traffic (and the attendant hardware, bandwidth,
electricity, etc) is exacerbated. 

For many sites, these consequences would be a significant impediment to
them adopting a non-bounce approach, at least for mail which is
determined with very high probability to be spam.

	Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad
Templeton
Sent: Monday, April 07, 2003 8:49 PM
To: Vernon Schryver
Cc: [email-masked]
Subject: Re: [Asrg] Ban the bounce; improved challenge-response systems

Rejoining the list after a week off for a conference (where I gave a
nice
talk on spam issues, among other things) let me add that while I doubt
we can get rid of bounces -- no well designed software system drops
traffic
on the floor without informing the interested parties (except if that is
part of the design, as in UDP) -- but we can make them easier to handle
for honest mailing lists.

[...]