From: Rich Graves
Date: 2006-08-22 14:42:56 -0400
Subject: Re: I want "milter-spamc-Connect:" to override "reject-unknown-tld"
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
> Rich Graves wrote:
>> The email is delivered fine. +reject-unknown-tld is just a warning
>> when the sender is whitelisted.
>> *However*, the RFC 2821 check is a hard error even if the sender is
> That's because its part of the address parser that adheres to the RFC
> 2821 grammar where the <angle brackets> are required. The address has to
> be parsed first into its component parts before any B/W list lookups occur.
But if the connecting *client_addr* is whitelisted, then perhaps you
don't need to parse the MAIL FROM at all. It's a question of precedence,
If STRICT_SYNTAX always trumps milter-spamc-Connect:, that's fine, but
should perhaps be documented. In sendmail-land, it was my impression
(unverified) that positive accessdb values always trumped negative
accessdb values where there's a conflict (for example, connecting DNS
name and MAIL FROM say REJECT, but Connect:<ip address> says OK).
milter-spamc docs are silent on precedence rules.
I believe that the behavior of the combination of milter-spamc-Connect:
and reject-unknown-tld is inconsistent, no matter how the precedence
rules go. It's not clear to me where in the code path it happens, but if
reject-unknown-tld and milter-spamc-Connect:OK are both true, then the
content is passed to spamd. It turns into a trinary test.
Case 1, 2, and 5 are consistent with the documentation and the code as I
understand it. Cases 3 and 4 are unexpected.
1) whitelist ip + rcpt to:<user@fqdn> => accept (spamd not consulted)
2) non-whitelist ip + rcpt to:<bare_username> => reject (regardless of
3) whitelist ip + rcpt to:<bare_username> + high spamd score => reject
4) whitelist ip + rcpt to:<bare_username> + low spamd score => accept
5) non-whitelist ip + rcpt to:<user@fqdn> => (depends on spamd score)
IMO it's quite normal for end users to address mail to bare usernames.
For various reasons, I will probably end up moving my MSA to a different
sendmail.cf that doesn't hit milter-spamc at all, but this apparent
inconsistency should be looked into.
>> MAIL FROM: email@example.com
> This is wrong. It should be:
> MAIL FROM:<firstname.lastname@example.org>
I know, but we have local embedded systems that can't be fixed. This
doesn't seem to give false positives on the open internet, just within
known client_addr ranges. If milter-spamc can't be restructured to allow
this (white possible), then I'll just split off my MSA.
Copyright 2009, 2012 by SnertSoft. All rights reserved.