[RFCI-Discuss] about FQDN for our smtp servers

[mouss]

Alex van den Bogaerdt wrote:
> On Thu, Apr 13, 2006 at 09:00:20PM +0200, mouss wrote:
>
>   
>>>> This is debatable. The RFCs are self-contradictory here (one RFC 
>>>> requires clients to use a "canonical" name, but doesn't allow servers to 
>>>> check for that). of course, even requiring helo has been controversial 
>>>> for some time...
>>>>    
>>>>         
>>> This has come up here before.  Your statement is false in multiple ways.
>>>  
>>>       
>> prove it. my "statement" above is comprised of two statements:
>> - RFCs are self-contradictory
>> - requiring helo has been controversial
>>     
>
> You said the RFC does not allow to check a canonical name is used.
> Now you say something different. Make up your mind.
>   
Mea culpa. I wrote check, I spelled check, but I thought "reject" (ie 
check to reject, not check for free).
>   
>>> The parameter must be a resolvable, fully qualified domain name
>>> FOR THE CLIENT HOST.  If this client host claims to be somebody
>>> I know it is not, using knowledge I possess, I can safely reject
>>> the message(s) in that session.
>>>       
>> and how do you get that knowledge? do you have a huge /etc/hosts on your 
>> machine?
>>     
>
> Do I need a huge /etc/hosts on my machine, to know a server in china
> is using *MY* host name in ITS ehlo command ?
>   

This is an easy one. if it's your hostname or your IP, you don't need 
any lookup.
The problem is if someone is claiming to be "foo.yahoo.com" in his helo. 
we can either have a list of "forged" helo names or we can do dns 
lookup. I prefer the dns lookup as I don't need to manage a list and it 
allows the domain owner to take his local decisions.
> And what about stuff like SPF, specifically forbidding 99.9999% of
> all hosts on the Internet to use a certain HELO string ?
>   
SPF si not an answer. the best we can say is that it brings its own 
problems. but this isn't the subject here, so let's keep this for 
another thread.
>>> People claiming you cannot refuse messages based on HELO are
>>> RFC ignorant themselves.
>>>       
>> we are talking about the standard, not about what one can do if he 
>> wants. as said above, you can reject mail randomly (as far as you accept 
>> postmaster and abuse mail).
>>     
>
> I am not talking about randomly rejecting email.  I am talking about
> rejecting based on faulty HELO parameters.
>
> It is quite simple.  The HELO parameter has to be *the*host*name* of
> the client.  A fully qualified domain name. The canonical name, not
> an MX record. Not a local alias.  Not a CNAME.  There are some
> ifs and unlesses, in some narrowly tailored cases.  That's when the
> SHOULD applies. We are not talking about those very uncommon exceptions
> here, we are talking about people that think "aol.com" is a correct
> parameter, or "mailhost", or "192.0.2.1".
>   
unfortunately, while talking about canoncial, we are still forced to 
accept mail from silly systems that use their netbios name as helo... In 
the past I wouldn't care of helo, but in these spam days, having 
legitimate systems misbehave breaks makes it harder to detect spam. but 
that's another issue.