Am 13.09.2014 um 19:12 schrieb LuKreme: >> On 13 Sep 2014, at 07:35 , 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 > > FSVO of ‘right’, sure. > >> if someone is not able to determine his public >> hostname and IP he better don't setup a MTA > > Sometimes it is not possible to set your external hostname to match.
then set the one in your server configs to your external - so what >> 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 mailserver >> >>> 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. All the time, in fact prove it by logs - no sane MTA i ever seen is using such HELO and any connection i see on MTA logs with such a HELO end in get rejected by RBL's, ClamAV or SpamAssassin and the few messages not rejected are clearly junk not caught >> yes it happens 1 out of 100000 > > Far more than that we are talking about MTA to MTA communication and not MUA to MTA where such restricitons are overriden by permit_sasl_authenticated >> and only because people continue to tell it is reasonable instead block such >> connections > > It would be a burden on YOU to convince people (well Wietse) that it is not > reasonable check_helo_access exists