On Sep 13, 2014, at 7:35 AM, li...@rhsoft.net wrote: > > Am 13.09.2014 um 15:10 schrieb LuKreme: >> On 12 Sep 2014, at 13:55 , li...@rhsoft.net wrote: >>> Am 12.09.2014 um 21:49 schrieb Philip Prindeville: >>>>> However, any time I connect via telnet to this server and specify >>>>> *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions >>>>> won't trigger. >>>> This is both legal and reasonable. >>> >>> it maybe true but it is *not* reasonable >> >> What do you base that on? > > you stripped that part from my quote > because it is *easy* to do it right
It’s EASIER to do if you know your topology. It’s impossible to do with absolute certainty if you don’t. > > if someone is not able to determine his public > hostname and IP he better don't setup a MTA Again, it’s not just MTA’s which speak SMTP… > > the same way as your internel PTR and A record don't count in > the internet your internal hostname also is not relevant - set > the HELO name to the public one matching the public DNS redcords > and if you don't know where to do so don't setup a public mail server What if you’re on an ISP (like Comcast residential) which won’t give you a fixed address? > >> What problem are you having that you are trying to solve? > > have you ever seen a non-spam connection on a inbound MX with > such a HELO - yes it happens 1 out of 100000 and only because > people continue to tell it is reasonable instead block such > connections > > Yeah, all the time. Each of the company employees when he’s out-of-office and connecting remotely. You’re forgetting that UNTIL you’ve seen the MAIL FROM and RCPT TO, you don’t know if this is a CLIENT submitting the message to the OUTBOUND MTA, or another MTA attempting FINAL DELIVERY. So you can’t block on the HELO because that’s way too early. -Philip
