On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote:
> Wietse Venema wrote:
> > John Peach:
> >> On Mon, 03 Aug 2009 13:18:52 +0200
> >> Robin Smidsr__d <ro...@smidsrod.no> wrote:
> >> [snip]
> >>
> >>> Willy De la Court wrote:
> >>>
> >>>
> >>> Does this mean that all of the reject rules are in fact not
> >>> RFC-conformant?
> >>>
> >>> The reason I mention reject_invalid_helo_hostname is that I'm unsure
> >>> if the IPv(4|6) address syntax is part of this rule (postfix version
> >>> 2.5.5, distributed with ubuntu 9.04).
> >>>
> >>> What about the two other reject rules? As far as I can tell, they are
> >>> both non-conformant.
> >>
> >> Your server, your rules.
> >
> > Indeed. RFCs are relevant only when parties want to interoperate.
> > Generally, there is no such desire on the receiving end of SPAM.
>
> 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.)
It's difficult to put your subjective experiences into a policy
document that would allow a person who lacks knowledge of the subject
area to make an informed decision. A lot of the "informed" part can
only come with experience.
> 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. 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?
But seriously, reject_non_fqdn_helo_hostname and
reject_invalid_helo_hostname are not likely to block real MX mail.
> rejects legitimate email). Whitelisting is (usually) a manual job, and
> anything that is manual work requires human intervention (i.e. usually
> not something you want).
>
> 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.)
> 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.
> If you don't use these reject rules, will warnings (as suggested by the
> RFCs) be inserted in the Received: line (or somewhere else in the
> header)? If it is I can use this as input to a mail filter.
Received lines are constructed the same way for all accepted mail,
augmented only by some TLS settings.
> 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. I think mail administration needs
much MORE professionalism (paternalism, you might even say), not less.
Good luck.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
