unwise filtering policy from cox.net
jgreco at ns.sol.net
Wed Nov 21 14:29:39 UTC 2007
> Given what Sean wrote goes to the core of how mail is routed, you'd
> pretty much need to overhaul how MX records work to get around this one,
> or perhaps go back to try to resurrect something like a DNS MB record,
> but that presumes that the problem can't easily be solved in other
> ways. Sean demonstrated one such way (move the high volume stuff to its
> own domain).
Moving "[email protected]" to its own domain may work, however, fixing this problem at
the DNS level is probably an error, and probably non-RFC-compliant anyways.
The real problem here is probably one of:
1) Mail server admin "forgot" (FSVO "forgot", which might be "didn't even
stop to consider," "considered it and decided that it was worthwhile to
filter spam sent to [email protected], not realizing the implications for abuse
reporting," "didn't have sufficient knowledge to figure out how to
exempt [email protected]," etc.)
2) Server software doesn't allow exempting a single address; this is a
common problem with certain software, and the software should be fixed,
since the RFC's essentially require this to work. Sadly, it is
frequently assumed that if you cannot configure your system to do X,
then it's all right to not do X, regardless of what the RFC's say.
The need to be able to accept unfiltered recipients has certain
implications for mail operations, such as that it could be "bad" to use IP
level filtering to implement a "shared" block for bad senders.
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
More information about the NANOG