Re: Spam filtering non-features

Victor Duchovni:
> On Fri, May 06, 2005 at 11:06:26AM -0400, Wietse Venema wrote:
>
> > > I really wanted to make this DNS PTR specific. If a host is the local
> > > hosts file, it is unlikely to not forward resolves or that one wants to
> > > reject connections from it.
> >
> > I am talking about the omission of IPv6 support. When people use
> > hostname based access control, hosts should not be able to escape
> > the access control mechanism by connecting over IPv6.
>
> I lifted the code from reject_rbl_client. This too (for lack of any
> IPv6 RBLs and avoid sending bogus queries to current v4-only RBLs)
> does not support v6. Clearly the reasons don't carry over, but I was
> looking "check_reverse_access" (aka check_ptr_access) as somewhat akin
> to an RBL mechanism, only useful to reject listed parent domains or
> regexp patterns.
>
> Indeed we can make it much more similar to check_client_access with
> the sole exceptions being:
>
> - Names are not verified
> - OK results are mapped to DUNNO.

Assuming that we're also using getnameinfo() so that check_reverse/
client_access are consistent in what they use as the client
hostname.

> > If we use a name-based access map mechanism, then it should be
> > consistent with other similar access map mechanisms in Postfix: no
> > host should escape name-based access map lookup just because they
> > have no name. That would be another user interface problem.
>
> As for "unknown" it is not a useful key in access tables, because there
> is no way to downgrade 5XX to 4XX. What do you suggest? Use of "unknown"
> as a key in the existing client access table is also semantically invalid
> unless the RHS is "reject_unknown_client".

It's not hard to make check_client_access smarter about the hostname
so it maps (5XX && unknown) into 4xx, but that means we have to
update the policy delegation protocol with another attribute so it
can do the exact same thing (I like to keep the option to rip out
thousands of lines from smtpd into a separate process that plugs
into the policy delegation hooks).

> > I don't see this as a DNS specific feature. The popular request is
> > to have a way to capture information about hosts whose address->name
> > mapping is not consistent with the name->address mapping, or that
> > have no corresponding name->address mapping.
> >[getnameinfo() results inconsistent with raw DNS results]
> > For example, one follows CNAME indirections and the other does not,
> > so you can get different name results for the same host. That's
> > another user interface problem.
> >[and one uses nsswitch.conf while the other does not]
>
> That gets us into deeper trouble, because canonicalization lookups
> can fail, but the bad PTR blockers just want to block their least
> favourite PTRs come hell or high water. Now if canonicalize the
> PTR we either get inconsistent behaviour, or no blocking when
> the canonicalization lookups fail.

I don't particularly like the idea of client hostname-based access
control primitives that can disagree on the client's hostname even
when the DNS is correctly configured, for example because one
primitive follows CNAME indirections, while the other does not.

This would be an argument to keep the name check_ptr_access
and to make clear that it is the dumbest possible lookup
routine that doesn't even follow CNAMEs.

Another concern is that Postfix by design does a lot of sanitization
of network information. For example, Postfix rejects hostnames that
don't pass the valid_hostname syntax check, and rejects hostnames
that pass the valid_hostaddr check.

Postfix rejects such names because they could mis-lead humans,
because they could be used to evade access controls (a numerical
hostname will match a network address pattern), or because they
could corrupt audit trail information (hostnames with spaces will
not be parsed correctly).

This would be an argument to keep the lookup result from reverse-only
lookups strictly separate and not make it available to anything
else, lest it be tricked by unsanitized data.

This still does not make me comfortable about the idea of running
unsanitized and potentialy mis-leading information through Postfix
lookup tables that are likely to be shared with access primitives
that do use sanitized data, not to mention the audit trail corruption
issues. The existing Postfix code assumes sanitized data; it must
not be suddenly exposed to raw sewage, or accidents will happen.

Finally, this sounds like a project of ways to figure out a client
identity.

- client identity from PTR record

- client identity from reversible name<->address mapping

- client identity from EHLO->address mapping

That's the easy part. The hard part is a user interface that doesn't
create more problems than it solves, and dealing with unsanitized
versus sanitized information, as discussed above (valid hostname
syntax, hostnames spelled as a network address, corruption of audit
trails or otherwise mis-leading humans).


Wietse