[milters] Archive

Lists Index Date Thread Search

Article: 1109
From: Rich Graves
Date: 2006-08-22 14:42:56 -0400
Subject: Re: I want "milter-spamc-Connect:" to override "reject-unknown-tld"

Removal...........: milters-request@milter.info?subject=remove
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 
>> whitelisted:
> 
> 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, 
really.

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 
spam score)

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: rcgraves@brandeis.edu
> 
> This is wrong. It should be:
> 
>     MAIL FROM:<rcgraves@brandeis.edu>

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.

Lists Index Date Thread Search