John Levine <asrg(_at_)johnlevine(_dot_)com> wrote:
Given that spammers have made it pretty clear that they will stoop to
anything to try to shove their junk into our MTAs, I don't see how
publishing a policy could be of any use unless it was soemthing like
my old NO UCE banner with lawsuits to back it up. Anything more
complex than a single bit for spam/no spam is overimplemented.
This comes back to the question of why doors have locks, when the
locks don't prevent criminals from entering.
Publishing a policy as to number, size, bandwidth, etc. for incoming
mail allows a recipient to better interact with any cooperating
originator to better manage network resources.
e.g. Rather than bouncing mail when the disk is full, tell the
originator "try again in a day"
More information means better decisions. Much of this kind of
information is currently *implicit* in SMTP. It means that in order
to cooperate with the recipient, the originator must jump through all
sorts of hoops to try to discover the recipients policy. That work is
unnecessary, and is wasteful of resources.
So how does this apply to spammers? As you said, they are
non-cooperating originators. Once the recipient publishes a policy,
and an originator doesn't cooperate, then the recipient has reasonable
grounds for changing the way he deals with that originator. Getting
such information in the mail envelope stage is *much* preferable to
getting it post-facto, after applying a content filter which may or
may not work.
In other words, the spammers are non-cooperative in the SMTP
conversation, completely independent of the message body. That fact
alone means that SMTP envelope methods to address spam will ALWAYS be
more effective than content-based filtering.
And we are seeing this now. Many spammers are sending messages
like:
---
Here's the URL you requested:
http....
--
There is so little content to that message that in order to prevent
similar non-spam messages from being caught in a filter, the filter
must err on the side of false negatives... and let spam through. This
solution is unacceptable in many ways.
Now you might say that recipients are already publishing such
policies. But they're not, really. They may be *enforcing* such
policies, but there is no standard way to publish them. This lack of
a standard also means that it's more difficult for the local
administrator to decide what the policies are. The decisions usually
end up being:
- MTA software says turn on feature FOO to gith spam
Ok... we turn it on.
Question: What's the local site policy?
Answer: The administrator doesn't know.
So having a method to publish those policies means that the
administrators will create them, rather than just using magic stuff
that other people told them works. Magic wands are nice for wizards,
but they're inappropriate in a technical environment.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg