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

Reply via email to