-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]
On
Behalf Of Jon Kyme
<snip>
Unless my "anti-spam" system is perfect, there must be no
silent false-positives for this to be true. Either a sender
whose message is not delivered because of the action of some
"anti-spam" system must be able to know this. And be able to
find out what they can do about it. (This is a very strong
argument for "spam" rejection to happen during the SMTP - or
whatever - transaction; we don't want to be sending DSN or
challenges to forged senders.) Or, the "receiver" must be be
informed that the message hasn't been delivered, and be able
to do something about it (but this imposes a cost on the receiver).
In general I agree with you, but I will play devil's advocate here.
Notifying the receiver that a message was not delivered is analogous to
moving messages to a "spam-review" folder. Many bulk mailers have argued
that this amounts in practice to deleting and/or blocking their messages
because the receiver never reviews this folder - and by analogy might
simply ignore any notifications (presumably due to the cost).
Since the "human component" will tend to be wildy inconsistent from a
system-wide perspective, we must assume that some amount of "silent
loss" will always occurr in any system we devise... for example, even if
the message is passed through to the end user without any modification
or redirection, the end user might simply delete it out of hand and
nobody can prevent that. Give that user sufficient technology and they
will likely use that technology to delete these messages automatically.
It could be argued that this action is an exercise of that user's
consent and so that dynamic is part of what we must consider in the
design of a consent based system.
--- I take off my devil's hat ---
It is apparent to me that we can develop a system that forces that vast
majority of reject cases to provide some appropriate notification to the
sender, and even the receiver if they wish. This rejection notification
starts on the scale of an unsubscribe request, escallates to delivery
failure notifications, then to rejections of the message during the DATA
sequence in SMTP, then to rejections of the message at the envelope
stage in SMTP, and finally to rejection of the network connection. In
all of these cases the sender would know that consent is not granted. If
we make the design of the system such that these cases are the "most
economical" (most automatic?) for the receiver then the vast majority of
cases will provide sender notification.
An side benefit of this interaction is that one can percieve a failure
to heed this notification can be considered abuse and therefore lead to
more aggressive countermeasures - such as blocking sender IPs and
Networks at gateway routers - thus denying the sender's ability to
compromize the network.
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg