On Tue March 8 2005 00:54, David MacQuigg wrote:
A Spam Bounce is a message generated in response to a spam, or what is
suspected of being spam. This could be a reject message, or a challenge
message, or a bounce generated by the recipient of the spam. In the past,
these have been a problem, because they generally go to a forged address,
where they become just more spam.
First, "spam" is subjective; as Dave has noted, it is a social
phenomenon, not something that can be objectively differentiated
from an architectural point of view. Second, "forged" is a loaded
term; there are legitimate reasons for setting a return-path (i.e.
destination for delivery notifications) to point to a particular
mailbox -- there is no objective criterion that one can use to
determine a "forged" return-path from a legitimate one; sending IP
address and inbound mailbox (for notifications) are unrelated,
message header address fields are part of end-to-end user-to-user
communication and play no role in transport, etc.
No such critter, other than two cases:
1. single-hop authentication between parties having a prior
arrangement and using SMTP AUTH, SSL/TLS (there are also
some possible mechanisms for single-hop authentication
which are not standardized).
2. end-to-end, user-to-user non-repudiation via established
MIME security mechanisms (e.g. S/MIME and PGP/MIME).
The first case requires a prior arrangement which is inconsistent
with the email architecture as noted in Dave's draft. Now you
might wish to discuss some proposed new architecture, but that's
a separate issue from documenting the existing architecture.
The second case is a user-level mechanism which therefore is not
applicable to delivery (transport level) notifications. Moreover,
the second case is ineffective in the all-too-common case of a
machine owner who has installed a trojan for use by spammers,
in which case he is effectively no longer the (sole) owner, and
any authentication keys, etc. stored on the machine are available
to the (remote) spammer. [the first case is also ineffective
under such conditions, but affects a single hop rather than end-
will allow these Spam Bounces to be routed properly,
back the path they came.
You are assuming that delivery (transport) notifications always
go to the same hosts that are involved in forward transfer, and
that is simply incorrect; it is not unusual for large-volume
message handlers to use separate hosts for inbound and outbound
messages -- a host which has an SMTP client MTA for sending
outbound messages might well have no SMTP receiver and vice versa.
Looking at the email landscape from a higher altitude, a user
might use one ISP for sending messages (one with his "current"
connection; think of mobile users), and a different ISP for
receiving messages (including delivery notifications; his "home"
If the email is *not* spam
That's a subjective appraisal.
, the Spam Bounce will
get back to where it belongs, most likely the same domain as the
Return-Path. If it *is* spam, the Spam Bounce will be lost or ignored at
the point where the spam was injected.
You are presuming that categorization as "spam" is an objective
determination, that is is possible for an automaton implementing
an MTA to determine the precise *mailbox* for a non-delivery
notification separate from the architecturally-established source
of that information (i.e. the return-path) etc. In short, you're
not talking about the current email architecture at all.
Here are the Actors in a spam scenario:
| Originator | | Recipient |
| Spammer +--> - - - - -->|Forwarder+
You're saying that the spammer is not the originator?