Hi,
someone should look for this issue:
Received: from tieinterceptor2.discourse.org (hosted-vh1.discourse.org [64.71.148.4])
tieinterceptor2.discourse.org shoud be hosted-vh1.discourse.org.
Andy
2 Likes
Sure, will make sure our sysadmin checks and replies.
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.
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 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.
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 (tieinterceptor2.discourse.org [64.71.148.3])
It's a different IP address.
Practically, many people have a lot of ill-conceived ideas.
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?
@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.
- Resolving FQDN to IP mean you have control over the domain.
- 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).
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.
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.
You asked for standards ?
here are only some links that describe it. So you can see it is an common behavior.
http://www.msxfaq.de/spam/filter-helo.htm
https://www.ietf.org/rfc/rfc2821.txt
- 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
Sigh... I just can't avoid staring at a car wreck on the highway, either.
"common behavior" != "Internet standard"
$ 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,
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.
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.
1 Like
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.
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.
1 Like
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.
1 Like
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.
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.
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> 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>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. 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. IN TXT “v=spf1 -all” assuming the fqrdns is never used in helo or 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)
1 Like
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.
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
1 Like
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.
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.