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. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. 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)
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
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".
Maybe that the SMTP rfc doesn't clearly states that, but the DSN rfcs do state
that, under the smtp domain, the name of a MTA must be a name mapping to the IP
address of the MTA itself. This means that is must be the dns name or the ip
address of the MTA.
And it wont violate the "PTR and A records
should match" guideline. Technically, it can be garbage, and still be
ok. Whatever it is, it doesn't change the item you replied to.
Again, I can't recall a single RFC asserting that an A record must mutually map
a PTR record.
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. 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).
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. 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".
...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 :-)
