[milters] Archive

Lists Index Date Thread Search

Article: 1486
From: Anthony Howe
Date: 2007-03-09 06:26:54 -0500
Subject: Re: Feedback desired about black / white listing support.

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

I'm disappointed that no one has yet commented on this thread.

Anthony Howe wrote:
> a) Reduce number of lookups: consider dropping support for sendmail
> untagged entries, which have been deprecated by sendmail for a long
> time, but haven't yet disappeared.

I think this change will appear in either libsnert/1.64 or 1.65, unless 
I can get arguments to continue support for untagged entries in access.db

> c) Related to b) revisit what RHS values are supported? Should RELAY
> white list or be ignored?

Steve Freegard brought this up in private email discussion with me last 
year and I've been on the fence concerning it. I asked him to post to 
the list to solicit feedback to which there was none:


Since Steve Freegard's argument makes some sense I'm thinking about an 
option to turn on/off RELAY white list behaviour. Note too that 
discontinuing support for untagged entries will probably address part of 
the problem seen Steve.

> d) Revisit pattern-lists. Are they used at all or only rarely? If so
> which ones? CIDR patterns appear to be most useful, should I keep only
> this one and chuck the rest?
> e) Consider new tags to provide delay-check like behaviour with combo
> lookups, ie. Connect:From:, Connect:Auth:, Connect:To:, From:To: I have
> a very long brain storm mail about this from a private discussion to 
> post later about this.

Below is a brain storming message in response to a request from
Steve Freegard:

Anthony Howe wrote:
 > Steve Freegard wrote:
>> Wed Feb 14 16:10:06 2007: Request 900 was acted upon.
>> Subject: feature request - from:to: access statements
>> We could use a combination directiive fromto for access.
>> This would allow us to whitelist people or domains only when sending to
>> specific people or domains.
>> example: our customer needs to receive email from unknown users at some
>> domain.  We don't want to whitelist the domain to all of our customers
>> in case spammers use the domain as a forged sender, but it is important
>> we can be flexible enough so our customer can receive email from their
>> customer.
>> FromTo:somedomain.com:ourcustomerdomain.com    OK
>> or
>> FromTo:somedomain.com:johnsmith@ourcustomerdomain.com    OK
>> Thanks,
> The problem with a From:To: tag is how to implement the lookups and
> order. For example one such lookup ordering would be:
> From:To:achowe@host.snert.com:steve.freegard@sub.fsl.com
> From:To:achowe@host.snert.com:sub.fsl.com
> From:To:achowe@host.snert.com:fsl.com
> From:To:achowe@host.snert.com:com
> From:To:achowe@host.snert.com:steve.freegard@
> From:To:achowe@host.snert.com:
> From:To:host.snert.com:steve.freegard@sub.fsl.com
> From:To:host.snert.com:sub.fsl.com
> From:To:host.snert.com:fsl.com
> From:To:host.snert.com:com
> From:To:host.snert.com:steve.freegard@
> From:To:host.snert.com:
> From:To:snert.com:steve.freegard@sub.fsl.com
> From:To:snert.com:sub.fsl.com
> From:To:snert.com:fsl.com
> From:To:snert.com:com
> From:To:snert.com:steve.freegard@
> From:To:snert.com:
> From:To:com:steve.freegard@sub.fsl.com
> From:To:com:sub.fsl.com
> From:To:com:fsl.com
> From:To:com:com
> From:To:com:steve.freegard@
> From:To:com:
> From:To:achowe@:steve.freegard@sub.fsl.com
> From:To:achowe@:sub.fsl.com
> From:To:achowe@:fsl.com
> From:To:achowe@:com
> From:To:achowe@:steve.freegard@
> From:To:achowe@:
> From:To::steve.freegard@sub.fsl.com
> From:To::sub.fsl.com
> From:To::fsl.com
> From:To::com
> From:To::steve.freegard@
> From:To::
> Another ordering would be reversed, ie. breaking down the From: side
 > first (but that's a harder implementation). In either case, you end up
> generating a LOT of lookups per recipient.
> Remember too, as for all my other tags, that the right hand side can
> be a pattern list normally and so what meaning does it have in this
> context and what should it be compared to. Probably the RHS would be a
> pattern list that matches against the From:, since the To: can be
> assumed to be clearly defined on the left and so needing no further
> pattern matching.
> Since I'd be using some combination of existing code lookups, note
> the "blank" default cases and how the "From:To:something:"
entries would be
> equivalent to the semantics for From: tag and how the last set,
> "From:To::something" would be equivalent to To: BUT where the RHS
> pattern list would be comparing the From:, which actually might be more
> useful than the original To: tag pattern list semantics.
> The original From:To: suggestion could probably extended to a
> Connect:To: tag as well with similar lookup semantics and ordering. The
> RHS pattern list could match against the Connect: since the To: is
> clear. Extending this further still to Connect:From:To: I think would
> NOT be useful and certainly be expensive.
> Connect:To:
> Connect:To:
> Connect:To:
> Connect:To:
> Connect:To:
> Connect:To:123.45.67:steve.freegard@fsl.com
> Connect:To:123.45.67:fsl.com
> Connect:To:123.45.67:com
> Connect:To:123.45.67:steve.freegard@
> Connect:To:123.45.67:
> Connect:To:123.45:steve.freegard@fsl.com
> Connect:To:123.45:fsl.com
> Connect:To:123.45:com
> Connect:To:123.45:steve.freegard@
> Connect:To:123.45:
> Connect:To:123:steve.freegard@fsl.com
> Connect:To:123:fsl.com
> Connect:To:123:com
> Connect:To:123:steve.freegard@
> Connect:To:123:
> Connect:To:[]:steve.freegard@fsl.com
> Connect:To:[]:fsl.com
> Connect:To:[]:com
> Connect:To:[]:steve.freegard@
> Connect:To:[]:
> Connect:To:machine.example.com:steve.freegard@fsl.com
> Connect:To:machine.example.com:fsl.com
> Connect:To:machine.example.com:com
> Connect:To:machine.example.com:steve.freegard@
> Connect:To:machine.example.com:
> Connect:To:example.com:steve.freegard@fsl.com
> Connect:To:example.com:fsl.com
> Connect:To:example.com:com
> Connect:To:example.com:steve.freegard@
> Connect:To:example.com:
> Connect:To:com:steve.freegard@fsl.com
> Connect:To:com:fsl.com
> Connect:To:com:com
> Connect:To:com:steve.freegard@
> Connect:To:com:
> Connect:To::steve.freegard@fsl.com
> Connect:To::fsl.com
> Connect:To::com
> Connect:To::steve.freegard@
> Connect:To::
> As you can see, to introduce these series of lookups with the
> existing  tag set would significantly increase access.db processing.
 > This begs the question whether to reduce lookups we should replace
> the Connect:, From:, To:, tags with Connect:To: and From:To: (and 
 > maybe a Connect:From: as well if a case for it can be made.).
> Note also that these tags by definition imply "delay-checks" like
> behaviour, while the Connect:, From:, To: are immediate linear
> behaviour. I suppose a new delay-checks option could be implemented with
> three possible settings:
> delay-checks=no        Use only Connect:, From:, To:
>             		(default, historical)
> delay-checks=yes    Use only Connect:To:, From:To: and maybe
> 	            Connect:From: if useful.
> delay-checks=both    Use both Connect:, From:, To:, and Connect:To:,
>       	From:To: and maybe Connect:From: if useful.
>       	This would be most flexible, but involve the
>             	greatest number of lookups.
> This would provide the best flexibility to postmasters.
> One problem I have with From:To: is that the sender can still be
> easily forged from any where. A Connect:From: is interesting in that
> it's like a local SPF definition (or could be using pattern lists), ie.
> these hosts can send for this sender / domain, which is more reliable
> IMO than From:To:.

Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561

Lists Index Date Thread Search