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:

At 8:40 PM -0500 4/4/03, Len Conrad wrote:
>>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.

Yes, that's exactly what I've experienced.

>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.

No, not "from", "for". As in, the destination is that.

>>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.

Again, I'm talking about the destination, not the sender.

>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.

Right.

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

Again, that's not what I'm talking about at all.

>>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.

Actually, many mail server programs will default to setting their
HELO/EHLO name based on the PTR record. So for many mail servers,
this is automatic.

The last trick is setting the MX record to also match the PTR record,
like this:

client.domain. MX 10 mx1.mydomain.

mx1.mydomain. A a.b.c.d

d.c.b.a.in-addr.arpa. PTR mx1.mydomain.
____________________________________________________________________
Chris Buxton Men & Mice
support@menandmice.com Making DNS Easy

Sales:
888/4-DPOINT

Support:
858/452-3696