John W. Baxter wrote:
>
..[snip]...
>
> Someone else can reform the world (at 65, I'm too old and tired). I
> fully agree that the world SHOULD work that way. And should have worked
> that way from (nearly) the beginning.
And I do educate those that do not have proper EHLO strings (such as _
in them), and at the same time, inform them about why it is important to
have matching PTR records for their domain.
> Until the world is reformed (optimistically 3 years to reach the
> [unlikely] IETF consensus and 5 more for implementation), I'm the one
> here who gets to answer "Why can't my friend Molly send me email?"
I have to to deal with the same problem, unfortunately I cannot impose
such 'draconian' checks to email, I do however reward those servers that
are proper, and 'punish' those that are not. However, implementation of
this 'rule' can be done very quickly, all you need are the big ISPs/email
providers (Yahoo, Hotmail, etc.) to give a joint statment that they will
require this from all connecting hosts, give a leniency period of 3 to
6 months, and then enforce it. Yes it will cause a lot of headache for
those that do not understand why it is important, but hey, most of those
that I have to educate in the first place, either A) do not understand
DNS, and/or B) do not understand the SMTP protocol. They really need to
understand both if they are going to manage or run an email server, let
alone a web server.
> If I were to insist that the EHLO/HELO string match the PTR record, many
> of the public school in Washington State (just as one example) would be
> unable to send us mail (or at least that was the case last time I
> looked)...let's see:
I know, that is why I do not insist on this myself, however, I do look at
this as part of a connection profile, you fail too many test, bam, we
don't accept the message as there is no reliable way to track who the
originating host is/was.
> ....1CAZIY-0001rB-EF <= "obfuscated"@???
> H=(mail.ptsd.wednet.edu) [168.212.160.22]:55245...
>
> # host 168.212.160.22
> Host 22.160.212.168.in-addr.arpa not found: 3(NXDOMAIN)
>
> (The A record matches, at least. Sigh!)
> # host mail.ptsd.wednet.edu
> mail.ptsd.wednet.edu has address 168.212.160.22
They are better than most education institutions at least :)
> OK...so that's the school system in our headquarters city...obviously we
> exempt them. And then???
>
> Even if I knew the admin at the Port Townsend schools (I do, actually),
> it wouldn't help, since it is the state which handles the name service.
Then they need to contact the state DNS managers to get that fixed, but
then again, unless they get their internet access directly from the state
contacting them does no good, as they need to contact their ISP and get
them to change to PTR record, or give them control for the in-addr.arpa
space that the ISP has leased to them. Thst is the whole reason why this
check is important, as there will almost always be at the very least two
different entities involved, if not three.
Besides, the SPF FAQ says as much:
http://spf.pobox.com/faq.html#bestpractices
as does AOL:
http://postmaster.info.aol.com/guidelines/bestprac.html
http://postmaster.info.aol.com/info/rdns.html
But alas, at this point I cannot even enforce (as AOL does) that all
connecting server have a PTR record, because not enough of the 'big'
guys do this yet, and at times, it is very difficult to get a clueless
mail admin to even agree that they have problems sending to AOL, as AOL
tends to dump mail from those servers directly into SPAM folders, and/or
/dev/null the stuff, rather than just not accepting it, and/or generate
an NDR....
--
--EAL--
--
