On 16-11-10 01:23, Wietse Venema wrote:
> Thinking of the longer term, ...
Maybe the following is too wild in this context, but while the cards
are on the table and since the need for the new wild card syntax arose
in relation to whitelisting, I'll throw it in anyway:
RFC5782 says that an operational whitelist MUST contain an entry for
127.0.0.2 and MUST NOT contain one for 127.0.0.1, and whitelist users
MUST periodically check this to see if the list is still active.
If Postfix is going to expand support for whitelists, it is probably
a good idea to go all the way and add these 'sanity checks'. I apologize
if this has come up before, but I checked the archives (of both 'users'
and 'devel') and found nothing. Therefore I venture the following proposal.
1. The "sanity check' by itself seems easy enough to implement (I
know, "they" always say that). For basic support, it would be enough to
add lookups for these two pseudo-clients to 'postfix check' processing
and write a warning message if the list is defunct. This could be a
quick first step, but IMHO it is not sufficient.
2. Of course not every mail server operator reads the logs, so it
would be better if Postfix _ignored_ the accept_dnswl_client statement
(or whatever) if that particular list is dead. This would probably
require that the result of the sanity checks be cached (to avoid
"tripling" the load on the whitelist server), and more code would be
needed.
However, if we keep consulting dead whitelists, things would get
interesting if the list, after some time, starts returning a positive
for every IP, in an attempt to get the attention of negligent mail
admins, just like blacklist operators have been doing in the past.
As an aside, this is also why I think Postfix should handle the
sanity checks as part of its whitelist support.
3. Of course not every dnswl operator implements RFC5782, so this
"ignore mechanism" would make non-conforming lists unsuitable for use
with Postfix. They would be considered dead and the accept_dnswl_client
statement for them would have no effect at all. Mail would be blocked
even though the client is whitelisted, and we all know what will happen
if we attempt to shift the blame to the whitelist operator by waving
RFC5782 at our customer.
Therefore it might be good to provide a way to disable the sanity
check for a particular list. This could be done as a side effect of
making the frequency of the sanity checks configurable, either via (yet)
another parameter to the accept_dnswl_client statement, or via (yet)
another config statement, e.g. :
check_dnswl_sanity some.whitelist.com = value.
That value could simply be an integer that specifies the check
interval in hours. A value of 0 would mean 'don't bother to check, this
list is not conforming to RFC5782'.
The default would be - say - 25 (configurable, of course <g>, e.g.
with check_dnswl_interval).
These sanity checks could be done as needed, i.e. a message comes in
_and_ it 'hits' the accept_dnswl_client statement _and_ the check
interval is not zero _and_ it has expired. This would (re)populate the
cache for this particular list. Next, if the cache entry indicates that
the dnswl is indeed alive and kicking, it can be asked about the real
mail client in the usual way. Nothing new here.
4. However, in addition to that, the 'postfix check' processing
should _always_ perform the RFC5782 sanity checks, each and every time
it runs.
Firstly, I would expect 'postfix check' to tell me in real-time
something like: "Hey you, you tell me to use some.example.com as a
whitelist, but it doesn't pass the RFC sanity checks, so it must be dead
and I won't use it and therefore your job is at stake. If you're sure
it's not dead but just non-conforming, please tell me so.".
Secondly, it would be cool if it could tell me: "Hey there, you
declared another.example.com as 'non-conforming' but it _does_ in fact
pass the sanity checks, so you had better remove that declaration. It
serves no purpose and it will bite you if/when the list goes dead one day".
Since 'postfix check' would typically be part of cron.daily
processing, it makes sense to have it repopulate the cache with the
result of its sanity checks (and this is why I proposed a default of 25
hours for check_dnswl_interval). On the other hand, that would it make
it impossible (or rather: useless) to specify check intervals that are
longer than one day.
Indeed, with a 'postfix check' in cron.daily, the whitelist server
would still see our sanity checks coming in at 24 hour intervals, no
matter what our config says.
The only way around this (that I can see) is to add a separate
"postfix check-whitelist-sanity" mechanism (instead of expanding on
'postfix check') but that seems a) overkill and b) contrary to
expectation for 'postfix check'.
So maybe it is best to decree that check_dnswl_interval should only
be used to specify intervals of less than 24 hours. After all, that
means only two extra queries a day, not exactly a DoS for a DNS server
that offers e-mail whitelisting services.
Does all of this seem like something that is worth doing?
Of course the actual names of the proposed parameters are just for
the sake of clarification.
Luc Pardon
Belgium
