Subject: [Asrg] Non-delivery

From: [email-masked]
Date: Wed, 09 Jul 2003 13:07:22 -0500

> Since you say the purpose of the framework is to evaluate anti-spam proposals, 
one of the criteria should be the likely impact on existing usage and 
interaction between existing users and those who have migrated to consent-based 
software. Some of that detail will depend on implementation, but some abstract 
ideas are so fundamentally different from the current system that *any* 
implementation of them would affect interoperability.

> Of course I know there are already many reasons why e-mail may not arrive 
under the current open system, such as an invalid recipient e-mail address or a 
lack of disk space at the receiver's incoming mail server. So maybe this issue 
is less important (to the abstract model) than I first thought.

> Anyway, I'd be interested to hear your comments about the issue.

I think there are a whole variety of separate issues and cases here.

First of all, when first implementing a Permissions List type consent system, 
the first 2-6 months are probably going to be used setting the permissions 
appropriately for the mail you 'normally' are receiving (a lot of that will take 
place within the first 7-20 days or so, but I'd expect it would taper off fairly 
rapidly after that).  During that time, a different default blocking policy 
probably should apply (perhaps even "block nothing").

After the system is installed and basically familiar, there are a whole variety 
of issues and considerations, and there may not be any one single 'best' 
practice.

For example, if Aunt Gertrude sends an inhabitual message, one might want to:

   1)  deliver it but include a warning (appended?  separate message?) about the 
nonconformance?
 
   2)  auto-send a reply to Aunt Gertrude advising her that the nonconforming 
mail has been held awaiting special approval for delivery?

   3)  hold it pending a decision by the recipient?

OTOH, for mail coming from a spammer (i.e. using spammer tricks like obscured 
content or obscured URLs that are never used in normal E-mail) there may be no 
point in bouncing or replying to it, even if the from or reply-to address are 
actually valid.  (If nothing else, you really don't want to indicate to them 
that the E-mail address they sent to was 'good'.)

(Actually, if they WERE valid then bouncing the mail back from millions of 
recipients would have the effect of being a (richly deserved!) DoS upon the 
spammer...)

I wonder if that might be an interesting countermeasure, actually, for spams 
hawking Web sites?  Where if the Web site mentioned in the spam was "unknown" 
(i.e. not on a "good guys" URL database), then a bot "hit" would be done on the 
Web site just to scope it out, as part of E-mail checking?  Surely the 
spam-promoted site wouldn't hold up very well under the onslaught of all those 
bot-generated 'hits'.... the effect would be that of a distributed-DOS attack 
:-)

And for that matter... might it make sense to include the stuff on that Web page 
as an additional source of material to be considered in the content filtering of 
the message, perhaps?

One downside of such an approach is the potential for particularly nasty "joe 
jobs", I suppose.  But it's still an intriguing thought.  :-)

Anyhow, I think there are several quite different handlings for incoming 
messages that trip the 'spam filter' (and/or violate the Permissions List 
rules).

In some cases, you really do just want to T-can the message (familiar and known 
companies who just insist on spamming you).  Sometimes you might want to bounce 
it;  sometimes to hold it pending decision.  Or whatever!  A good permissions 
list approach will allow for any of those, I'd think.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg