I am a idiot, no wait, I just don''t know

Re: I am a idiot, no wait, I just don''t know

From:

Date:

Time:

>The sending mail server identifies itself using a name other than the one
>in the PTR record. Suppose the sending mail server identifies itself as
>"mail.example.com"

you mean the helo/ehlo hostname? wow, I've never seen any MX reject mail
because the helo/ehlo hostname didn't match the sending MTA's PTR
hostname. But, sh!t happens, and the sh!t happens not to US, but to the
idiots who set up these systems. They will have huge rates of false
positives.

>but the PTR record says "a-b-c-d.dsl.example-isp.net".
>
>Some mail servers will reject the connection.

I've never seen that, and I've with dozens of ISPs, so it's not a solution
that I think is worth pursuing if you don't have it (of course, if you can
do it, do it)

>Case 2: Incoming mail.
>
>An SMTP relay server (i.e. someone else's outgoing server) receives a
>message for user@example.com. The relay server looks up example.com

counterproductive and misguided, since example.com is often forged and so
the receiving MTA if off on a wild goose chase.

>and sees this:
>
>example.com. MX 10 mail.example.com.
>mail.example.com. A 192.168.1.10
>
>The relay server then looks for the PTR record for that address, and it finds:
>
>10.1.168.192.in-addr.arpa. PTR 10-1-168-192.dsl.example-isp.net.
>
>Some relay servers will bounce the message right there.

Again, really stupid.

Tons of ISPs, ie legitimate mailers, have their mail server, which hosts
10's or 100's of @sender.domains, or an outbound gateway, send all domains'
outbound from a single IP. So there's no way the sending IP's PTR hostname
will ever match the @sender.domain or the HELO hostname. no way.

We do exactly this in Paris. The PTR for 212.73.210.75 is mgw1.meiway.com
and the A for mgw1.meiway.com is 212.73.210.75. ie, the "perfect match"
for DNS validation. You simply cannot do it better than perfect.

But from that IP, I send with @sender.domain as meiway.com, go2france.com,
and dozens of our customers domains. never had a problem.

>Otherwise, assuming any further DNS-based tests are passed, the relay will
>connect. But the receiving server may be expected to identify itself as
>10-1-168-192.dsl.example-isp.net, not mail.example.com. Otherwise, the
>connection might be dropped and the message bounced.

extremely bad policy. They deserve all the lost business they will get
from extremely high rates of false positives.

>Neither of these cases is common.

That's my point. They are such ill-advised, wrong-headed DNS-based
validations that, luckily, they are extremely rare. The rate of false
positives would be horrendous and unsupportable for those systems.

For your sending IP:

1. no reverse delegation or
2. reverse is delegated but not PTR record

This is the "worst case" and even here rejecting on this criterion alone
will give a huge number of false positives. However, using this "unknown
SMTP client" as weighted factor combined with other factors often tips the
decision towards rejection + blacklisting, so everyone should avoid the
absent PTR for their sending IP.

3. PTR hostname exists, but does not match the hostname's A
record. Sufficient for nearly all MXs.

4. best case: "PTR + A match", per my example above. Best case, GAMEOVER.
btw, this is Scott's situayion:

# dig -x 66.14.189.160

;; ANSWER SECTION:
160.189.14.66.in-addr.arpa. 21h27m31s IN PTR bdsl.66.14.189.160.gte.net.

# dig bdsl.66.14.189.160.gte.net.

;; ANSWER SECTION:
bdsl.66.14.189.160.gte.net. 5M IN A 66.14.189.160

So Scott is not at all in bad shape, and is a hell of a lot better shape
than a lot of mailservers.

5. Trying to set up to match your PTR hostname + that hostname's A record
+ the HELO hostame is a complete waste time, and more often than not,
simply impossible.

Len

Sales:
888/4-DPOINT

Support:
858/452-3696