/dev/rob0 wrote: > On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote: >> I'm just trying to figure out what to write in a policy document about >> this behaviour. A behaviour which is backed by a RFC has a lot of more >> weight (conserning interoperability) than our own policies about what is >> accepted behaviour or not. > > It's subjective. In my subjective experience, I have never seen a bad > HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss]) > delivering good mail. (YMMV if you don't know how to separate your > users' submission from MX. MUAs often do EHLO with the bracketed > [ip.add.re.ss] syntax. But no real MTA does it, IME.)
All my servers/users are either listed in mynetworks or use sasl auth, and they go before any HELO reject rule, so they should be in the clear. >> When a legitimate server is rejected it is generally easier to say "the >> admin of that server has not set up his server correctly according to >> the standard. Make him fix it if you want to receive email from them." >> than it is to say "our policies does not allow a connection like that >> because the email is usually spam". The last one is a tempting reason >> for a customer to leave and find another service provider (because it > > Does this happen in the real world? Possibly. I've had at least one client leave because he absolutely needs to have every email, because every single email he receives could be really important. So dealing with spam is something he just has to do. On the other hand I have users that don't really care one way or the other. I just want to be able to let the user make that choice. And rejecting email based on (possibly forged) helo is a system-wide policy, not a user-specific policy. Is it possible to make this a user-policy? > But what are the > alternatives? Allow ALL the spam through, maybe doing some expensive > content filtering which is slightly less accurate than pre-DATA checks > (and far more prone to actual loss of mail, when users do not check > their spam folders) -- or, block what you know to be garbage and take > your chance with clueless customers and clueless competitors? Well, my way of dealing with the problem is to actually filter the email (statistical filtering) and let the user decide what they want to do with it (quarantine, tag or reject). That way I haven't taken the choice away from them. Yes it costs more (in terms of resources), but it makes it possible to cater to those clients that really don't want mail to be rejected. > > But seriously, reject_non_fqdn_helo_hostname and > reject_invalid_helo_hostname are not likely to block real MX mail. Thanks for the clarifications. I've re-enabled them, ignored the whitelist (for now) to see how these rules actually pan out. reject_unknown_helo_hostname is still disabled. It was the main rule that required whitelisting in the first place. >> What does the reject_invalid_helo_hostname rule do with the IPv(4|6) >> HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]? >> Does it accept or reject it? According to the RFC it should be valid. > > It IS valid. "Invalid" means "not valid under RFC standards." However, > again, I have never known a real MTA to use that syntax, only MUAs and > spambots. I therefore made the policy decision to reject those (after > permit_* restrictions.) Thanks for the clarification. I've re-enabled it to see if it blocks anything legitimate. >> reject_non_fqdn_helo_hostname means that the "domain" needs to contain >> at least a dot, and otherwise conform to the DNS naming standards, am I >> correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as >> defined above, or will it reject it? > > A bracketed [ip.add.re.ss] is not a non-FQDN HELO. Common ones I've > seen include "friend", and strings which appear to be infected Windows > PC netbios names. Thanks again. > Received lines are constructed the same way for all accepted mail, > augmented only by some TLS settings. Is there any documentation for how it is constructed, or do I need to look in the source code? >> Regards, >> Robin, which is trying to build a mail system which puts the >> choice of rejecting/filtering email in the hands of the end user. > > While that sounds like a noble goal, I see lots of problems with it. > Chief among those is the fact that end users often cannot distinguish > spam from unwanted legitimate email. That doesn't really bother me so much. If it "feels" like spam to them they may classify it as such. It only influences the user himself. Of course, if they classify mailing lists as spam it will only fill up their junkmail box, which will just influence their allotted storage capacity (quota). > I think mail administration needs > much MORE professionalism (paternalism, you might even say), not less. I highly agree with you there. That is what I'm trying to build. A well documented, with clear policies, mail system which can cater to both of the user types mentioned above. -- Robin
