[RFCI-Discuss] about FQDN for our smtp servers

[mouss]

Alan Brown wrote:
> On Tue, 11 Apr 2006, mouss wrote:
>
>   
>> This is a question for the recipeitn MTA. some MTAs will reject you if
>> your helo doesn't resolve to your IP.
>>     
>
> This is an explicit RFC violation.(*)
>   

sure, but many don't care. on the other hand, using random strings in 
helo is also an rfc violation. unfortunately, the RFCs are more or less 
self-contradictory (they require things from the client, but still 
require the server to accept other things).


>>  some MTAs will reject you you if
>> your helo doesn't resolve.
>>     
>
> So is this.(*)
>   
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...
>   
>> some MTAs will accept any helo.
>>     
>
> They can use local policy rejectiosn for any reason they want(*)
>
> (*) Many sites use "local policy reasons" as the reason to violate
>     RFCs, but "MUST NOT" trumps "local policy" in my book. Having said
>     that, I am more than happy to use "local policy" as a reason to block
>     SPECIFIC problematic HELOs associated with spamware/networks, etc.
>
>   
At one time, I have parsed all my mail looking for helos. the results were:
- almost all mail has good helo
- many spammers used the recipient domain as helo
- few spam used "random" helo.
...

The result of this was that checking helo was not really helpful [_for 
me_].

> Many MTAs will reject syntactically invalid HELOs (no FQDN, unbracketed
> IP or contains invalid characters) or HELOs containing the name/IP of
> the receiving MTA ("I refuse to talk to myself, go away!")
>
>   
>> to stay on
>> the safe line, your helo should resolve to your client IP
>>     one_of_ip(helo) = client_ip
>>     
>
> At the very least, on the outnbound MTAs:
>
> 1: There should be _ONE_ PTR for each outbound IP address used
>
> 2: There should be a matching A record for that PTR
>
>   It is possible to use more than one PTR, but this _will_ cause
>   problems unless all PTRs have matching A records.
>
> 3: The HELO of the outbound MTA should match the PTR of the outbound IP
>    address used, or use the IP address itself in RFC-valid format (no
>    brackets == invalid)
>
>
>
> I have to say that given the size of Netease, I am extremely surprised
> to see an admin here asking basic questions which should have been well
> understood before deploying and administering large mail systems.
>   

true. but you know how many large ISPs are well behaving:)
> While it is a good thing that Netease/163's admins are now seeking
> assistance, there is a _long_ history of net abuse plus lack of response
> to complaints which has left many administrators worldwide feeling
> unhappy and Netease's networks widely blocked.
>
>
> I hope that the effort to fix things up continues - and that Netease
> policy towards abusive users/spamhavening is reduced to "no tolerance".
> Even with that, it will take a long time for the badly damaged
> reputation of the company to recover - but it CAN recover (Ask AOL...)
>   

I can only encourage Jeff to get it right. I prefer to get these large 
networks on the "right" side than on the "other" side.
I get very few legitimate mail from Asia, but if people there can do 
something, then I appreciate.