Matthew Sullivan wrote:
Andrew D Kirch wrote:
Matt Sergeant wrote:
Some mail systems are unable to differentiate between these various
results or flags, however, so a public DNSBL MUST NOT include
opposing or widely different meanings -- such as 127.0.0.23 for
"sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
same DNS zone.
Not sure why this is a MUST NOT. If people are dumb enough to use a
mixed list in a broken way they get what they deserve. What's the
justification?
This isn't just broken lists it's broken software. Not all software
which uses DNSBL's differentiates by returned response.
Valid point and a separate section on client configuration/usage or even
a separate RFC would be a good idea.
I'm contemplating doing a more general BCP on filtering (receiver end),
or perhaps restricted to DNSBLs if the former gets too controversial
(like if I start ragging about SAV or C/R ;-) Main things would be
"reject, not block", "useful, not necessarily fully revealing" error
codes, plus various attitudinal adjustments ;-) I have this 10 point
thing laying around somewhere that forms the basis for the ideas.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg