* mouss ([EMAIL PROTECTED]) [20080903 13:14]: > Raymond Keller wrote: > >Is the compatibility that is sought by allowing underscores done for > >the sake of Windows MUAs? > > No. This has nothing to do with windows nor with MUAs. you generally > don't care about the helo used by MUAs. MUAs should use submission > (mynetworks, sasl, ... preferably on port 587). So when you check helo, > you assume that the client is an MTA.
Ah. I don't have experience with varieties of server installations, so my guess was very speculative. However, I would be surprised to hear if there were _no_ implementations wherein MUAs submit to Postfix via 25 (despite what MUAs ought to do). And I would be surprised to hear if this hadn't been a more popular method in the past, perhaps in the era when the underscore allowance was made. But, I indeed do not have the knowledge and was hoping to poll the community here for that kind of wisdom. Sadly, I am also still unclear on the actual usefulness of allowing underscores, and am left to continuing speculation on that. > >>/_/ 554 RFCs 810, 952, and 1035 do not allow underscores in hostnames. > > It's your mail! Test it (you can use warn_if_reject) and count the > number of spam hits and ham hit. if spam hit rate is too low or if ham > hit rate is too high, then you should not use this rule. I suppose I am left to personal investigation. Thanks for the warn_if_reject reminder. My setup and mail traffic are probably not typically representative (if anyone's setup ever could be said to be), but if anyone is interested in hearing my results, I would be happy to share. > >ideally this might be done with a configuration option (perhaps > >"strict_rfc2821_helo_hostnames"), but, again, it may be best for me > >to just do the rejection via check_helo_access restriction. Is > >there any sense of how many legitimate MTA configurations out there > >violate this particular requirement? > > > >>/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$/ 554 RFC 2821 does not allow bare > >>address literals. Whoops, that's wrong, btw. The end-of-line dollar should not be escaped, sorry. /^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/ 554 RFC 2821 does not allow bare address literals. Hey, upon further reflection, rejecting unbracketed address literals as "not FQDN" kind of makes sense. RFC 1123 relaxed the hostname spec to allow for the first character of hostnames to be numeric but the author was not worried about this meaning that a hostname would appear to be a dotted quad "since at least the highest-level component label will be alphabetic." So, "1.2.3.4" is not an address literal, it's the not-fully-qualified hostname "1.2.3.4.com". I don't feel so disturbed by reject_non_fqdn_helo_hostname's behavior anymore. > some people (including $->self) use: > reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname Yes, I find those useful, too. (And it was their unexpected behavior that spawned this thread.) > One can also reject literal IP in helo as it shouldn't be seen in > legitimate mail from MTAs (although it is still theoritically possible). Meaning reject something like "[a.b.c.d]"? I don't think I know nearly enough to understand the impact of that. Well, I guess I do have logs... In my log I see 2883 rejections of mail (for various reasons -- DNSBL, unknown recipient, etc.) from "[a.b.c.d]" hosts out of 12867 total connects. I can't see in the log how many "[a.b.c.d]"s were _delivered_, however. :( I suppose I can enable this restriction with a warn_if_reject as you suggested earlier, and start to gather stats. > or if that's too aggressive: > > /^\[/ reject_unknown_client That's interesting. What does reject_unknown_client do in cases of unspecified hostname (which I take address literals to be)? The code seems to suggest that anything but a success is counted as a failure and is 450'd. I might prefer an outright rejection to possibly days of delay before a DSN shows up for the sender. Thanks for your help, RSK
