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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg