MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
hsantos at santronics.com
Sat Jun 9 09:01:06 PDT 2007
John Levine wrote:
>> However, I disagree with the sentiment that senders can tell
>> receivers to "kill it, don't pass it on" as expressed here.
>> This implies that senders control the threshold at which receivers
>> discard mail. I consider this unrealistic.
> I think we all agree that receivers will only do what's in their own
> self-interest, and they'll only take senders' advice if it helps that
> "It's all spam" is about the simplest useful advice a (non) sender can
> give. In my case, which I don't think is unusual, I get buckets of
> spam and blowback to subdomains that have never, ever, sent a real
> message. The domains are the names of computers on my network, which
> were probably scraped out of usenet or mail archive message IDs. If
> receivers were to reject or drop all mail purporting to be from those
> domains, it would be uniformly better both for the receivers (less spam,
> cheap filter) and for me (less blowback.)
IMV, the bottom line is that operators or everyone for that matter, do
not want abuse, senders and receivers. No one is interested in stopping
mail. Thats no fun.
But when abuse begins, they will want help to stop or control it, and of
course, they want to do so in a way that is 100% correct.
For us, when it comes to a base of customers who want as much help as
they can get, lots of hand holding, automatic logic, etc, and taking on
more and more of this responsibility, we need to ability to offer the
options and hopefully, define the defaults, that works best for them.
It was only about 3 years ago (when I began to get involved in all
this), that I had absolutely no interest in providing SMTP rules to
control spam. If the sysop wanted it outside of the basic SMTP
protocol, he did it himself. All we did was provide the "hooks" for
them to do it.
But what hooks were available back them?
With the infamous SORBIG attack and the variants that followed, this
changed every part the industry at all levels. It put the spot light on
the SPAM problem. People needed new regulations, new tools to help them
control the mess, and like you said, any automated system advice they
can get, helps the process.
You and your ASRG efforts helped tremendously to jump start ANTI-SPAM
efforts and you should be recognized for that.
When we take away all the personalization, we all do seem to one thing
in common: The common goal to make sure it makes sense, hopefully make
it as transparent as possible, without hindering the flow of "good mail."
Hector Santos, CTO
More information about the ietf-dkim