# Dns mail server issue **URL:** \ **Category:** Site Feedback\ **Created:** [November 22, 2015, 10:09am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281 "2015-11-22T10:09:46Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![andreasernst](https://avatars.discourse-cdn.com/v4/letter/a/bbce88/32.png) [@andreasernst](https://community.letsencrypt.org/u/andreasernst)\ **Post date:** [November 22, 2015, 10:09am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/1 "2015-11-22T10:09:46Z")
Hi, someone should look for this issue: Received: from [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) ([hosted-vh1.discourse.org](http://hosted-vh1.discourse.org) [64.71.148.4]) [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) shoud be [hosted-vh1.discourse.org](http://hosted-vh1.discourse.org). Andy ---
**Author:** ![discourse](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/discourse/32/9_2.png) [@discourse](https://community.letsencrypt.org/u/discourse)\ **Post date:** [December 6, 2015, 5:23am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/2 "2015-12-06T05:23:13Z")
Sure, will make sure our sysadmin checks and replies. ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 6, 2015, 7:19am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/3 "2015-12-06T07:19:02Z")
> [@andreasernst](#): > > Received: from [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) ([hosted-vh1.discourse.org](http://hosted-vh1.discourse.org) [64.71.148.4]) > > [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) shoud be [hosted-vh1.discourse.org](http://hosted-vh1.discourse.org) Why? `tieinterceptor2.discourse.org` is a valid name, which resolves to an IP address. There's no RFC I'm aware of that requires the domain name presented in the `EHLO` greeting be one which resolves to the IP address of the connection. In fact, [RFC5321] s4.1.4 says, > An SMTP server MAY verify that the domain name argument in the EHLO > command actually corresponds to the IP address of the client. > However, if the verification fails, the server MUST NOT refuse to > accept a message on that basis. I'd appreciate it if you could expand further on your rationale for this request. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [December 6, 2015, 5:07pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/4 "2015-12-06T17:07:42Z")
Hi, yes this is what the RFC say. But practically many spam filter rate this with very height spam indication. For example if i run at an dialin i could also use [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) since this resolves to an valid dns entry. And if the generalize this to the limit. We could say we need one FQDN in the DNS and all SMTP Implemenations will use this FQDN as an fixed value since it is legal arcoding to the rfc. ---
**Author:** ![andreasernst](https://avatars.discourse-cdn.com/v4/letter/a/bbce88/32.png) [@andreasernst](https://community.letsencrypt.org/u/andreasernst)\ **Post date:** [December 6, 2015, 5:32pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/5 "2015-12-06T17:32:29Z")
Yes that’s what I meant. Sure the RFC says this, but postmaster take a look at this. Also the PTR _should_ fit. But somebody changed this already: Received: from [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) ([tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) [64.71.148.3]) ---
**Author:** ![Zoddo](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/zoddo/32/2841_2.png) [@Zoddo](https://community.letsencrypt.org/u/Zoddo)\ **Post date:** [December 6, 2015, 5:33pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/6 "2015-12-06T17:33:25Z")
> [@andreasernst](#): > > But somebody changed this already: > > Received: from [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) ([tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org) [64.71.148.3]) It's a different IP address. ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 6, 2015, 10:19pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/7 "2015-12-06T22:19:37Z")
> [@tlussnig](#): > > But practically many spam filter rate this with very height spam indication. Practically, many people have a lot of ill-conceived ideas. > [@tlussnig](#): > > We could say we need one FQDN in the DNS and all SMTP Implemenations will use this FQDN as an fixed value since it is legal arcoding to the rfc. If you want to talk ridiculous hypotheticals, I could run a spam filter which scored very high any message which included the string "false positive". Would it be reasonable for everyone to avoid the use of that phrase, simply because I'm out of my gourd? ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [December 6, 2015, 10:57pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/8 "2015-12-06T22:57:49Z")
@mpalmer Even if you think it may ridiculous. But it is fully understandable that admins require that both ways resolve to the same. If you greet someone and say “an name” it is normaly expected that not only this name exists but it is your name. 1. Resolving FQDN to IP mean you have control over the domain. 2. Resolving IP to FQDN mean you also have control over the ip. If both make an valid round trip another mail server admin is sure that the IP owner and DOMAIN owner are working together and this is normally an positive indication. Since for example dynamic IP’s can only do (1). ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 6, 2015, 11:41pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/9 "2015-12-06T23:41:02Z")
> [@tlussnig](#): > > But it is fully understandable that admins require that both ways resolve to the same. No it isn't "fully understandable". It is _completely inexplicable_. The value in the `HELO` is a diagnostic nicety, only provided to give an extra little "hint" as to the sending mail server. It has absolutely no value as a general means of identifying the true source of bad behaviour, above and beyond that provided by the source IP address of the connection. If I set the `HELO` to the rDNS of the source IP address, what can you infer from that? That I'm willing and able to jump through hoops set by over-zealous, non-thinking spamfilter admins. That's it. If I'm a spammer, it's trivial for me to evade that check, because I just do an rDNS lookup of the IP I'm spamming from and set my `HELO` to that. Meanwhile, if I'm a legitimate MTA admin, using the `HELO` _for the purpose it was explicitly intended_, which is to say, uniquely identifying the sending MTA, I get flagged because I'm not conforming to some standards-defying, utterly pointless "anti-spam" rule. ![](https://global.discourse-cdn.com/letsencrypt/original/2X/d/d875fe20dee1cddf669d0771cd4eaef5d751a87b.gif) It is a truism of the Internet that any admin is free to reject any traffic, for any reason. Your network, your rules. Don't like the letter 'q'? Fine, reject all e-mail containing that letter. However, you don't get to make up rules from nothing, complain when it bites you in the behind, and require the entire Internet to adjust itself to accommodate your delusions. I won't be participating any further in this thread, unless someone can describe a _legitimate_, standards-based, issue with the current setup. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [December 7, 2015, 12:04am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/10 "2015-12-07T00:04:33Z")
You asked for standards ? here are only some links that describe it. So you can see it is an common behavior. > **[Forward-confirmed reverse DNS](https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)** > > Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols. RFC 1912 (Informational) recommends it as a best practice, but it is not a requirement of stan... [http://www.msxfaq.de/spam/filter-helo.htm](http://www.msxfaq.de/spam/filter-helo.htm) [https://www.ietf.org/rfc/rfc2821.txt](https://www.ietf.org/rfc/rfc2821.txt) - 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 7, 2015, 12:35am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/11 "2015-12-07T00:35:40Z")
Sigh... I just can't avoid staring at a car wreck on the highway, either. > [@tlussnig](#): > > So you can see it is an common behavior. "common behavior" != "Internet standard" > [@tlussnig](#): > > a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. ``` $ dig tieinterceptor2.discourse.org +short 64.71.148.3 $ dig -x 64.71.148.3 +short 3.subnet0.148.71.64.in-addr.arpa. tieinterceptor2.discourse.org. ``` Yep, that conforms to FCrDNS. ``` $ dig hosted-vh1.discourse.org +short 64.71.148.4 $ dig -x 64.71.148.4 +short 4.subnet0.148.71.64.in-addr.arpa. hosted-vh1.discourse.org. ``` As does that. And even then, > [@](#): > > RFC 1912 and RFC 1033 (Informational) recommend it as a best practice, but it is not a requirement of standard defining RFCs governing operation of the DNS. > [@tlussnig](#): > > [HELO-Filter](http://www.msxfaq.de/spam/filter-helo.htm) I don't read German, so I'm not sure what most of that page is describing, but I'm fairly sure it isn't a ratified standard of any kind. It also quotes the same text from RFC821 that I quoted up-thread from RFC5321 (meaning that that text has been through two major revisions over a period of _ **THIRTY-THREE YEARS** _ without anyone who knows what they're talking about saying "hey, maybe it's a bad idea to _explicitly prohibit_ refusing a message due the `HELO` FQDN failing verification, huh?" > However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. > [@tlussnig](#): > > [https://www.ietf.org/rfc/rfc2821.txt-](https://www.ietf.org/rfc/rfc2821.txt-) 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) That RFC has been obsoleted by RFC5321, so yeah... But, regardless, RFC2821 _also_ contains the same language as the other SMTP RFCs: > An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. Further, in searching for the section number you referenced, I found: > The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) Since `tieinterceptor2.discourse.org` is "a domain name that resolves to an A RR" (specifically, as at the time of writing, the `A` record `64.71.148.3`), there's no standards violation there, either. ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [December 8, 2015, 3:49am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/12 "2015-12-08T03:49:57Z")
> [@mpalmer](#): > > "common behavior" != "Internet standard" Doesn't matter what the speed limit (standard) is if you're stuck in a traffic jam. You can refuse to adhere to a common/bkp because it is not a "standard". But if everyone else is, then you're not going to get along very well. And there is vastly more of them than there are of you. Follow the standards and require others to do so also. But also get along with common/bkp. Standards rarely prohibit following common/pkp. ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 8, 2015, 5:06am UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/13 "2015-12-08T05:06:18Z")
> [@NOYB](#): > > Follow the standards and require others to do so also. Excellent. I hereby require others follow RFC5321 s4.1.4, which states: > An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. That's not a "MAY NOT". That's not even a "SHOULD NOT". That's a "MUST NOT". You can't get any stronger language prohibiting a behaviour in an RFC. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [December 8, 2015, 1:46pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/14 "2015-12-08T13:46:03Z")
Hi, it does not take anywhere to discuss about RFC’s. Fakt is that many mail server admins check it and refuse the connection. Since LE try to reach all people the question is if there is no point against the requirement and it can explained why it is in place the mail server should comply to it. ---
**Author:** ![mpalmer](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@mpalmer](https://community.letsencrypt.org/u/mpalmer)\ **Post date:** [December 8, 2015, 6:54pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/15 "2015-12-08T18:54:26Z")
> [@tlussnig](#): > > if there is no point against the requirement and it can explained why it is in place the mail server should comply to it. I assume by "the requirement", you mean the requirement that the name in the `EHLO` should match rDNS. Personally, I think it's a fairly big point against the requirement that the RFC says you "MUST NOT" do it, but if you'd care to explain why it is in place, I'm all ears. ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [December 8, 2015, 7:23pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/16 "2015-12-08T19:23:43Z")
> [@mpalmer](#): > > That's not a "MAY NOT". That's not even a "SHOULD NOT". That's a "MUST NOT". You can't get any stronger language prohibiting a behaviour in an RFC. That is the server. You are the client and you are not following the standard. Suggest you read the entire RFC5321 and pay particular attrition to the client requirements. ---
**Author:** ![gothic.ie](https://avatars.discourse-cdn.com/v4/letter/g/54ee81/32.png) [@gothic.ie](https://community.letsencrypt.org/u/gothic.ie)\ **Post date:** [December 8, 2015, 8:15pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/17 "2015-12-08T20:15:50Z")
its really simple and its CORRECT in fact many would legitimately argue its MUCH more correct to use different unique helo and fqrdns (within the one parent domain) as it distinguishes helos generated by mta’s from helos generated by infected machines that are able to look up their own fqrdns (all can) to operate a mailserver you must have an ip with FQRDNS (they do 64.71.148.4\>[hosted-vh1.discourse.org](http://hosted-vh1.discourse.org)\> 64.71.148.4) fqrdns is perfect and a helo identity that resolves to an ip (ideally the ip you connect from) theirs does resolve to an ip [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org)\>64.71.148.3 it is non-ideal that its different ip BUT not wrong (per rfc) as far as helo verification for ratware detection goes it passes with a tiny negative score (made tinyer by the fact that the helo resolves to an ip in same range as the connecting ip) it actually gets less of a negative score than if the helo-id matches the fqrdns-id as this is indistinguishable from ratware running on an infected ip that luckily has a fqrdns the helo identity verification could be assisted further (if wanting a positive score) by adding [tieinterceptor2.discourse.org](http://tieinterceptor2.discourse.org). IN TXT "v=spf1 ip4:64.71.148.4 and any other ips it may helo from -all" to spf validate the helo and for bonus points [hosted-vh1.discourse.org](http://hosted-vh1.discourse.org). IN TXT “v=spf1 -all” assuming the fqrdns is never used in helo or [user@hosted-vh1.discourse.org](mailto:user@hosted-vh1.discourse.org) but as i said it already passes and is delectably less likely to be forged than heloing as the fqrdns name so intelligent filters should have zero issues with it (i know my crazy draconian ones don’t, yes it could get more plus points easily but scores higher than most helos from most major senders already) ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [December 8, 2015, 8:45pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/18 "2015-12-08T20:45:09Z")
> [@gothic.ie](#): > > a helo identity that resolves to an ip (ideally the ip you connect from) theirs does resolve to an [iptieinterceptor2.discourse.org](http://iptieinterceptor2.discourse.org)\>64.71.148.3it is non-ideal that its different ip BUT not wrong (per rfc) Yes it is wrong per the rfc. The rfc says it is to identify itself (client). Not some domain, person, or some other entity. What identifies itself (the client) is it's own FQDN or as the rfc permits if FQDN is not available it's address litteral (ip address). The verification is happening on the server side of the communication. Whether or not they are adhering to the standard is not justification for a client to not adhere to the standard. ---
**Author:** ![gothic.ie](https://avatars.discourse-cdn.com/v4/letter/g/54ee81/32.png) [@gothic.ie](https://community.letsencrypt.org/u/gothic.ie)\ **Post date:** [December 8, 2015, 9:32pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/19 "2015-12-08T21:32:00Z")
again read the RFC it says the helo identity MUST resolve (only not what ip it must resolve to) yes it is non ideal, but as someone who writes mta level helo verifiers i can assure you it is perfectly valid and very common ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [December 8, 2015, 9:52pm UTC](https://community.letsencrypt.org/t/dns-mail-server-issue/4281/20 "2015-12-08T21:52:42Z")
> [@gothic.ie](#): > > again read the RFC it says the helo identity MUST resolve(only not what ip it must resolve to) Yes it does say what it must resolve to. Like I said read it and pay particular attention to the client requirements. Specifically the client ehlo/helo requirements. It is there. Either you are not reading it or not comprehending it. > [@gothic.ie](#): > > as someone who writes mta level helo verifiers i can assure you it is perfectly valid and very common It may be very common. But it is not perfectly valid. I hope nobody is paying you for that work. If they are they deserve a refund. Or at the very least you owe them some patches to fix the incorrect validation you have them performing. [Next page](https://community.letsencrypt.org/t/dns-mail-server-issue/4281.md?page=2)