> Giampaolo Tomassoni wrote:
> >> The statement you're replying to doesn't say anything about the HELO
> >> string. It says the PTR and A records should match (and they SHOULD).
> >
> > Oh, come on. Which RFC states that?
>
> RFC 1912, section 2.1, 2nd paragraph:
>
> Make sure your PTR and A records match.
You took this too much literally, I guess. The meaning of this phrase is a bit
broader and is explained by the following:
> For every IP address, there
> should be a matching PTR record in the in-addr.arpa domain.
This is the purpose of 2.1: there shouldn't be IP addresses without associated
PTR records. This doesn't mean the "the A and PTR records must match". Infact,
often you can't feed the result of a PTR query back to obtain the IP address:
most ISP (even country-wide ISPs, not me) do define PTRs with names which may
help them to identify the trunk and link where that ip is located, but which
doesn't match an associated A record...
> If a
> host is multi-homed, (more than one IP address) make sure that all IP
> addresses have a corresponding PTR record (not just the first one).
> Failure to have matching PTR and A records can cause loss of Internet
> services similar to not being registered in the DNS at all. Also,
> PTR records must point back to a valid A record, not a alias defined
> by a CNAME. It is highly recommended that you use some software
> which automates this checking, or generate your DNS data from a
> database which automatically creates consistent data.
>
> (note: RFC 1912 is not a "Standard", it is informational, but it is
> basically trying to establish guidelines for good DNS configurations)
Maybe it is informational because it is unreasonable to be enforced? The reason
is also that Internet works fine even without PTR records...
> >> This doesn't bother virtual domains at all.
> >>
> >> For example:
> >>
> >> IP addr A.B.C.D might have a PTR return "virtdomains.domain.tld"
> >>
> >> virtdomains should have an A record returning A.B.C.D (perhaps among
> >> other IP addrs).
> >
> > But there may be more zones with an A record returning A.B.C.D.
> That's how a domain is virtualized.
>
> Funny. The _very_ next thing you quoted from me, addresses the virtual
> domains issue:
>
>
> >> The virtual domains can also have A records that say A.B.C.D. That
> >> works, and doesn't violate the "PTR and A records should
> match" guideline.
> >
> > Who did sell you these guidelines?
>
> RFC 1912
Ok. RFC 1912.
> >> And, in any case, the HELO string can be anything. It can be
> >> virtdomains.domain.tld, or it can be one of the virtual domains, and
> >> nothing should be wrong.
> >
> > HELO/EHLO must indicate the MTA official name.
>
> That's true, and irrelevant to whether or not the PTR record and A
> record should match. Since the latter is the discussion in this
> side-thread, the content of the HELO/EHLO string can be anything and
> still not break "the PTR record and A record should match".
I would prefer something like "the IP address specified by the EHLO/HELO
string, either explicitly or as a DNS name, must match the one of the SMTP
client itself". But you're right: even this way is almost irrelevant.
>
> ...omissis...
>
> That's not what I said. I said the PTR record and A record should
> match. What this means is the the PTR record should lead to a hostname
> which has an A record (not a CNAME), and that hostname should have an A
> record that points to the IP address you started with.
But... this is automaticly enforced by most ISPs. What's the meaning of this?!?
Suppose I have this in my virtual domain yoyodine.com:
@ MX 10 mta.yoyodine.com.
mta A 1.2.3.4
When my MTA connects to your, your see that I'm connecting from 1.2.3.4, issues
a DNS PTR request 4.3.2.1.in-addr.arpa. and obtains, say, c4-l3-t2.isp.net.
Then, if your MTA issues a DNS A request
for c4-l3-t2.isp.net and my ISP is not that bad (i.e.: it follows your
guidelines), your MTA should get a 1.2.3.4 reply. Your MTA ends saing "Ok".
If the client's ISP is not rfc-1912-conformant, your MTA says: "Bad".
So, what's the purpose of this? Penalize people who got a rfc-1912
non-conforming ISP?
> The hostname may
> have multiple A records (round robin DNS), but at least one of them must
> be the IP address you started with (the SMTP client).
This is multihoming matter. Multihoming is not concerned into this discussion.
Is it? Why do you speak about it?
> Further, this has absolutely no impact on multiple hostnames having an A
> record with that IP address. There is NOTHING in this statement that
> prevents this situation.
So, what are we discussing about?
/Me lost.
> What matters is "the hostname listed in the
> PTR record" should point back to the IP address you started with (whose
> PTR record you looked up, resulting in the hostname). All other
> hostnames with the same IP address are not a factor in this "matching".
Well, fine. But this will definitely categorize the ISP, not the MTA's user.
> >> ...omissis...
> >>
> >> (but if they send email directly to me, instead of through
> their ISP, I
> >> will reject them, because their customer oriented IP address shouldn't
> >> be directly submitting email to my mail server)
> >
> > This is clearly stated in RFC 101974192374. :)
> >
> > You're "their ISP", isn't it?
>
> No, I am not their ISP, thus I have no desire, and certainly no
> obligation, to be their mail server :-)
