From: Daniel Feenberg <feenberg(_at_)nber(_dot_)org>
A bigger issue is that no one has shown that bounces are a significant
spam problem. ...
I think the problem is rather that forged return addresses make people
reluctant to use otherwise attractive methods for spam control. A content
based spam detector that had a 1% false positive rate might be acceptable
if senders were informed that their message had been rejected, but not if
their message were dropped on the floor. ...
1% false positive rates are accepted only by people who don't really
care about mail. People who make their living on the net do not
tolerate false positive rates significantly higher than the underlying
error rate of the mail system or 0.1%, whichever is higher. (15 or
20 years ago the net lost 1% or more of all messages, but like the
telephone system 50-75 years ago, expectations changed.)
But a content based scanner can't DSN all its hits - most of the return
addresses are forged and many are of innocent third parties. So a
technique that makes sure the sender gets a notice (if the sender is
legitimate) without generating lots of notices to innocent third parties,
is an improvement over the current usual practice.
That assumes statements not in evidence and that I think are wrong:
1. most return addresses of messages caught by spam filters are forged.
2. many are of innocent third parties.
3. "content based spam detectors" must use bounces to indicate false
positives instead of STMP status codes.
There is limited evidence to disprove #1 and #2, but #3 is obviously
wrong. Many content based spam detectors operate during the STMP
transaction and so do not themselves cause bounces.
Restricting DSNs to the connecting host and its MXs is a reasonable
compromise along these lines.
The problem with that notion is that it is impossible to define, not
to mention implement. It makes no sense unless you assume more things
that at best have not been established:
4. that STMP clients (mail senders) are also SMTP server (mail receivers)
5. that relays are wrong or unneeded.
It is true that a few DSNs would not find their way to legitimate senders
but if senders find that a problem, in the fullness of time, their mail
administrators may find ways to accomodate them....
Waiting for the fullness of time for mail administrators to find a
solution to lost data is not a widely respected tactic for protocol
design, at least not in professional circles.
.........
] From: Jim Youll <jim(_at_)media(_dot_)mit(_dot_)edu>
]
] I have to ask this again and forgive me if it's a stupid question, but...
]
] Is it _absolutely_ necessary to bounce back the entire message body,
] rather than just status and delivery data?
Yes, it is absolutely necessary that enough of the message be bounced
so that sender can know which message bounced.
] As a postmaster I can see message delivery details but not bodies and
] can diagnose just about anything.
Most mail senders care less about diagnosing the problem than knowing
which of their messages and to which addressee did not arrive.
] The idea of allowing a mail server
] to generate an entirely new message seems anachronistic at best,
] dangerous at worse. I do think most people keep an "outbox" today...
An "outbox" containing the 50 messages you've sent in the last 5 days
does not help deal with a bounce until you know which message bounced.
You need to know which message nees to be retransmitted or otherwise
handled. Even if the bounce contains all of the headers and you are
one in 10,000 who can read headers, you may not have enough information
to pick the original from your "outbox." Only if your MUA generates
Message-IDs that are preserved by your MSA and all subsequent MTAs in
the path might you reliably figure it out. The source of the bounce
cannot know if your MUA and MSA are sane. What can it do except
send most of the SMTP transaction log?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg