ietf-asrg
[Top] [All Lists]

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

2003-04-08 20:00:44
At 20:47 -0600 4/8/03, Vernon Schryver wrote:
 > From: Jim Youll <jim(_at_)media(_dot_)mit(_dot_)edu>

 > >An important but not hard part of the job is letting people at the
 >source of the message diagnose the problem.  People who've spent years
 >trying to guess why a distant machine run by idiots who can't look at
 >their own logs or do their own tests is intermittently rejecting mail
 >have more sympathy for the current, ad hoc, brute force, bandwidth
 >wasting, theoretically spammer exploitable scheme.

 Message body has nothing to do with this.

As written, that is wrong, particularly in this age of body filters.
You're right that the body need not come from the remote system to
aid diagnosis.  Still, your new DSN format must make it completely
clear and unambiguous where the body fits in the transaction log.
Or your DSN system must recognize messages where any bounce should
include the message.

I did think about that. The common practice is not to return messages
that are rejected by filters, but to drop them somewhere e.g. a /spam
folder. Message body has - if not nothing, then very little - to do with it...

More common filters that scan for viruses definitely do not send the
message bodies back but rather, add an informational message. But there
is no reason the message can't be generated fresh FROM the destination MTA
TO the apparent sender. It need not be a literal "bounce" of the original,
but a reply to it... which leaves open options for cool MxA's to sync up
Message-IDs too.

I am not proposing a new DSN format.  Don't complicate things.

Sendmail already has this option, it's just not the default.
Matter of fact it can *ask* the other end not to send back message bodies
in bounces (not that the other end will pay attention).

 > That is not necessary. Just change the default behavior of sendmail
 and when the next root exploit is found and everybody is forced to upgrade
 within 24 hours, it'll be largely deployed.

That's a leisurely deployment schedule, since the last root exploit
of sendmail before the recent pair was six years ago.
(see http://search.cert.org/query.html?col=certadv&qt=sendmail )

You take me too literally.


When you're dealing with errors, hand waving doesn't justify not providing
sufficent information to deal with a significant minority of cases.

My unsupported claim is that this scenario is vastly more common than
spam disguised as bounces.  I bet it's more common that bogus bounces
resulting from forged spam headers.  As others have pointed out, most
users don't understand, and more important, don't care much about how
email works.

Using your own scenario - a hobbled MTA behind a UUCP feed
that is intermittent and error prone...

... by definition, those users, and that server, are BADLY equipped
to deal with full-message-body bounces and would be better served
by an efficient use of channel capacity. Returns of message bodies
is a relic that mimics physical message transmission. Bits don't need
to be sent back.

I am too. I hate receiving file attachments back in a bounce. Pointless
and actually, potentially dangerous.

It's an exercise that IS open to spammers (my servers definitely
handle messages that are delivered this way) with not much benefit
to the end user. If you want to make delivery status work right, continuing
to send extra junk at the application layer is just wrong.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>