From: David Walker <antispam(_at_)grax(_dot_)com>
old advice to block free provider mail that does not come from the
free provider's MTAs. It does have a high false positive rate except
Thank you. So you do approve of RMX because how else are you going to know if
the free provider mail is coming from the free provider's MTAs if you don't
ask them. and how are you going to ask them if you don't have RMX?
As I said, it is easy to know if free provider mail is coming from the
free provider's MTAs without RMX. People have been implementing the
check you advocate for many years just fine without RMX.
No, I don't approve of RMX. I believe
- it is redundant and unnecessary because existing mechanisms achieve
can stop mail from free providers that does not come from each
provider's MTAs.
- there are simpler, already largely deployed ways to do exactly
what RMX does without a new RR, including Paul Vixie's suggestions.
- the new RMX RR will never be seriously considered in the DNS WG.
- if by some fluke that happens it will never pass Last Call in a DNS WRK.
- if everyone is asleep there, it won't pass IESG review or main list
Last Call.
- if it does get standardized, it will not be widely implemented in MTAs.
- it will not be installed by the organizations you need to install
it, including Hotmail, AOL, and Microsoft, because they will not
change their business models.
I'm beginning to get the impression that RMX proponents are egregiously
unaware of how SMTP works and is commonly used. Contrary to statements
from RMX propoents, current standards and practices support rejecting
mail from a free provider that does not come from the free provider's
MTAs. Many MTAs have been doing exactly that for years. For example,
see the pages found by
http://www.google.com/search?q=match+sender+domain+hotmail including
http://www.monkeys.com/anti-spam/filtering/additions.html
You're expending an awful lot of energy trying to break down the process but
you are an advocate of something much more anti-standards and intrusive.
Using existing standards is less "anti-standards" and less intrusive
than demanding other people do things including change their business
models and demanding changes to standards such as DNS. The current
standards and practices already support rejecting free provider mail
that does not come from the free provider's MTAs. (I'm repeating myself
because repetitions in previous messages were apparently unclear.)
I think resisting standards changes that are based on willful ignorance
of existing standards and current practices is required to keep the
IETF process from breaking down completely.
Instead of blocking the spammers from using those domains you block everyone.
As I've said many times over the years including this list, I think free
providers are parasites on the Internet because of how they handle
network abuse. I do not expect you or other ASRG contributors to share
this extreme view and I certainly do not expec the free providers to
change. I do not block all users using those domains, but only almost
all. My free provider blacklist has a handful of whitelist holes.
...I think demanding that free providers
change to fit my model of how they should run their businesses to suit
my convenience would be wrong.
Then why are you doing it? Why are you saying "you can't have free e-mail or
I won't accept your messages"? You are absolutely telling them how to run
their business if they want to send you mail.
Yes, but only if they want to send me mail. Contrary to you model,
they are free to send each other mail that complies with their providers'
terms and conditions. I think that even spam is just fine, provided
it stays on the spam friendly side of the net and away from me.
with postfix (which you seem to use).
I only use pieces of it. I'm working on an SMTP proxy with finer-grained
scriptable rules and logging to a database.
So why haven't you long since implemented the standard checks to
prevent what you call "spoofed" free provider mail?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg