John Hardin a écrit : > On Fri, 22 May 2009, mouss wrote: > >> John Hardin a écrit : >>> On Fri, 22 May 2009, Matus UHLAR - fantomas wrote: >>> >>>> I was mentioning cases where someone compares HELO to FQDN and rejects >>>> connections if they do not match. That was indicated by the message >>>> (even >>>> with different wording). >>> >>> Ok, agreed. If they don't match don't reject, just give that a point. >> >> Not as stated. let's say >> >> 192.0.2.1 has a PTR of life.example >> life.example has an A of 192.0.2.1 >> easy.example has an A of 192.0.2.1 >> >> if an MTA running on 192.0.2.1 helos as easy.example, then it's as good >> as any other name he could use. The fact that "life" is not "easy" is >> totally irrelevant. (of course, hostnames were chosen to allow for a >> word game, but this too is totally irrelevant :) >> >> you can only add a point if you do more checks, such as helo is in AU >> and sending IP is in UA, ... etc. > > ...sigh. Yeah, that's what I was trying to say, without going to the > effort of saying all of it. I agree. > >>> However, a FQDN in the HELO being unresolvable is a valid reason to >>> reject. >> >> but as I understand the RFCs, it could resolve to anything. an example >> would be an MTA behind a NAT box. (note that I am talking about the RFC >> requirement, not about what anyone can do with the noise he gets...) > > Right. Checking that what it resolves to is reasonable is a more complex > question. Whether or not it resolves at all is a simple question that > can be enforced at SMTP time by the MTA or a milter. >
I still get mail with "company.grp" (oh these exchange admins!). I've also seen unresolvable helo in mail from .edu sites (where they seem to like to use an infinity of subdomains, some of which get removed from dns but some MTAs containue to use them...). so I don't try to resolve the helo... on the other hand, you can block some known values/suffixes/expressions. here are a few recent "real" life samples dynamic.ranchi.bb.59.92.92.92/24.bsnl.in static.chandigarh.bb.59.94.224.236/24.bsnl.in 161.185.225.124.null.hi.!dynamic.163data.com.cn 18.50.225.124.lg.hi.!dynamic.163data.com.cn customer-static-.iplannetworks.net dsl88.230-.2304.ttnet.net.tr 40.subnet125-166-24.astinet.telkom.net.id.24.166.125.in-addr.arpa BThomehub.home api.home dsldevice.lan speedtouch.lan (and the award winner:) my.firewall >>> Per RFC2821 3.6 it MUST resolve. >> >> BTW. 2821 and 2822 were updated some time ago. use 5321 and 5322 as >> references now. > > Thanks. > > RFC5321 2.3.5 still requires the domain name in the HELO/EHLO, if used, > to resolve, so that reject is still valid for internet mail. > RFC aside, it is relatively easy to setup a helo that resolves (and even that resolves to the "public" IP unless you are behind NAT and you have multiple routes). but I'll wait until the gorillas enforce this.
