From: David Walker <antispam(_at_)grax(_dot_)com>
We should not be advocating non-standard hacks as a means to supress spam.
If there is a proposal to make a standard relating to them then discuss away.
So why haven't you long since implemented the standard checks to
prevent what you call "spoofed" free provider mail?
...
Since they have exactly the effects that you advocate, why are they
not acceptable solutions?
Why are they not appropriate topics for discussion here?
The IETF is about documenting things more than recommending them.
De facto standards and random hacks are grist for the RFC mill.
This is neither news.admin.net-abuse nor SPAM-L. Around here as well
as among experience professionals, whether something is documented in
an RFC is irreleavnt, except when you're worried what you need to
write in a new RFC. The IETF is about making interoperation more
likely but not about net-cops checking for RFC compliance. All that
matters is whether something has desired effects, sufficiently few
and mild bad effects, and doesn't make one's employer look too bad.
This is particularly true of security and authorization issues, which
is what controlling spam is. If you're ambitious, generous, and have
permissions from your bosses and relevant intellectual property owners,
you might take the time to push your favorite hacks through the
Standards Process, but that is in no sense required.
Most authorization policies are not documented in RFCs. Long established
spam defenses were once controversial hacks. For example, requiring
that sender domains be present and valid was controversial when AOL
started checking, but it is now the default in popular MTAs. Have
you turned off that check because it is not mandated by an RFC?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg