From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]
On
Behalf Of Terry Sullivan
Sent: August 6, 2003 17:19
To: asrg(_at_)ietf(_dot_)org
Subject: RE: [Asrg] RE: 2.a.1 Analysis of Actual Spam Data -
Titan Key reduces spam attacks
On Mon, 4 Aug 2003 06:41:50 -1000
"Peter Kay" <peter(_at_)titankey(_dot_)com> wrote:
I do believe that techniques using a
550/NSU response are effective in truly
reducing spam...
It'd be interesting to hear a focused, clearly articulated case
identifying exactly how a "false-550" spoof could possibly affect
spam volume. Ideally, the case should explicitly address the
following points:
According to RFC2821 a 550 response is defined as
| Requested action not taken: mailbox unavailable
| (e.g., mailbox not found, no access, or command rejected
| for policy reasons)
Note the "...rejected for policy reasons" part. It is perfectly
acceptable to reject a message as part of an expression of
consent.
I. The return address on the majority of spam is either:
A. utterly nonexistent, consisting of either:
1. forged username (e.g., yxal88qz(_at_)sbc(_dot_)net)
2. non-existent domain (e.g., Fred(_at_)NoSuchDomain(_dot_)com)
B. a legitimate address of an innocent party, pulled at
random from the spammer's database of email addresses
If the sending MTA is the source of the spam, then this action
will have a positive effect and no further notifications will
be generated. The problem you describe only occurs if the
sending relay is an abused third-party. It happens, but I would
not say in the majority of cases.
In the case where the sending MTA is an innocent third-party,
then the production of DSNs would, at the very least, raise an
alarm for the administrators and enable them to do something
about it.
II. The false-550 notices:
A. Cannot possibly be delivered to the nonexistent
addresses identified in I.A, and therefore cannot
possibly affect spam volume.
B. Are deliverable to I.B addresses, but since the
I.B recipients are not the source of the original
spam, it's difficult to imagine precisely how the
false-550 message would/could influence the amount
of spam sent by someone else.
However, in the case of a false positive this notice is
critical in informing the sender that their message has not
been delivered.
III. The small fraction of bulk email that actually bears
the spammer's true return address can be handled and
eliminated without resorting to deceptive, high-volume
automatically-generated email.
There are also several tangential points that would be crucial
in building a business case for the false-550 approach:
1. For every spam bearing a I.A.1 forged username, the
false-550 approach generates, directly or indirectly,
a minimum of 4 additional automated emails, thus
effectively quintupling the burden on shared network
resources. *Everyone* ends up paying higher costs
associated with a 5-fold increase in unnecessary
automated email.
How do you arrive at the "minimum of 4 additional automated
emails" ? If a 550 response is returned, a maximum of one
automated e-mail is generated. (Unless I'm missing something.)
This message should not have a return path and thus cannot be
bounced. Either it is delivered, or it is dropped.
2. When a false-550 message arrives in the InBox of an
innocent 3rd party (I.B addresses), it constitutes
an unsolicted, deceptive, automated email, whose sole
purpose is to promote the vested interests of the
sender at the expense of the recipient (i.e., SPAM).
Individuals/organizations who send a false-550 should
not be surprised to find that some folks think of them
(and treat them) as spammers.
3. Every time a false-550 message is sent to someone who
has attempted to undertake an innocent correspondence,
the very act of replying with a *false message* impacts
the sender's credibility. (It amounts to saying, "Some
people take advantage of open communication, so here at
XYZ Corp., we believe that every conversation with a
stranger should begin with a lie.")
In an effective system I would imagine the 550 response to
include details informing the sender on what has happened,
rather than simply dropping the message.
Given all that, I also fail to see how such responses would
actually reduce the spam volume. Perhaps when we have more
data this will become clearer.
Best Regards,
- Elric
--
Elric Pedder
Mailtraq Development (www.mailtraq.com)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg