>What I think would be a better solution is governmental support for >"credentials."
we don't need no gov support. We admins must set MX policy's that insist on "best practices" SMTP/DNS settings, aka, credentials. >The A/PTR part of credentials is east to understand and explain. >(D.C.B.A..in-addr.arpa. PTR host.name. must resolve to host.name A >A.B.C.D) no govt needed for each MTA to implement the following: SMTP settings: HELO label.domain.tld 220 label.domain.tld DNS settings: D.C.B.A.in-addr.arpa. PTR label.domain.tld. label.domain.tld. A A.B.C.D If you guys would just hold the line on these minimu settings as policies for your MXs, ie, simply refuse to whitelist legit servers that don't meet the above, then those legit servers would have to fix their settings or live with their mail being rejected. The more of us that reject, the more pressure there is on legit servers to setup correctly. Just like when AOL started insisting on PTRs, there was a mad scramble for mail servers to get PTRs. >But I remember hearing there is more to it than that. I know Len has >talked about SPF/DSP, but I never quite figured out what technology he was >talking about. Sorry Len, but whenever you had that acronym explained, I >missed it, and can't seem to see it in my archive. Try google for "SPF", it's the first hit, and Meng already provides SPF patches for postfix and other MTAs. I think SPF/DMP is an excellent solution, free, immediate, but if we can't even get past the SMTP/DNS credentials stage (also free, and immediate, like all DNS-based solutions), then there's not much hope SPF/DMP. Supposedly serious antis-spam lists such as spatmools and spam-L sterilely debated SPF into nothingness, picked it apart as having tinyimperfections, etc, etc, until there was nothing left, and nobody does anything. >If forgeries were automatically rejected by everyone, then we would only >have known sources to deal with, and that is a lot easier. exactly. but 30% of your accepted mail today doesn't even have a PTR, but you accept it anyway. error!! >Does anyone here have links to layman's explanations of the tech involved? what's hard about the 4 lines above? >I want to make sure I state things properly before sending off any such >letter. don't waste your time. What would be more useful is a generic http://postmaster.mydomain.com page that everybody could add to their organization's website stating what the "credentials" policies above are. The URL could be added to reject messages. But the hard part, at least as I see it with some of my IMGate customers, is that IMGate admins cave in to their users who complain about a mail from a "legit" server being rejected for "illegit" SMTP/DNS settings. All users want spam to be blocked, but nobody wants to hold the line on credentials. And then there are the anti-spam "solutions" which actually contribute to the problem, selling themselves as being able to ignore the credentials completely, or require umpteen different "faults" to be added up before rejecting and/or then scan the msg content (they have to receive all DATA commands) to see if it is spam or not. These "solutions" actually give the legit server with bad credentials a "pass" and they think that helps the situation. Len
