Re: Spam filtering non-features

On Fri, May 06, 2005 at 02:20:42PM -0400, Wietse Venema wrote:

> > 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.

Yes.

> > 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).

This sounds reasonable, I can't think of any compelling cases where
a REJECT result from an "unknown" key should not be downgraded to
4XX if the "unknown" is a result of a failed lookup. Some questions
will doubtless arise from confused users now and then, but this
already the case with defer_if_reject, and defer_if_permit, not much
can top those in complexity :-)

> > 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.

Yes. The requirement is I think to handle unmodified PTR data from DNS
essentially as-is (modulo syntax issues below).

> 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).

Well we don't use the raw PTR names to construct the name[ip] data
for logging, but we do send them to the access(5) table, and here
perhaps it is not unreasonable to skip keys that valid_hostname()?

The key use case is an ISP that supplies bogus generic

There is not much need to pass invalid data into the access table,
except perhaps as an "invalid" key, that would allow blocking of
"invalid" PTRs. Comments?
NN-NN-NN-NN.exampl.net PTR records that don't forward resolve.

> 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.

Yes, the "check_ptr_access" mechanism was intended to solve a very
narrow problem.

> Finally, this sounds like a project of ways to figure out a client
> identity.
>
> - client identity from PTR record

This I really don't view as client identity, I think of it as
data for an optional local blacklist pure and simple.

> - client identity from reversible name<->address mapping

This is client identity.

> - client identity from EHLO->address mapping

This is even more-so the client identity, and IMHO could
override the reversed name when the EHLO->address mapping
matches the client's IP address. The key question is where
to use it? Received headers? Logs? To record both names or
just one? ...

> 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).
>

I am not sensing that you are ready to adopt anything concrete in this
space yet? Are we close to a consensus on what check_reverse_access or
check_ptr_access (or both) should do. Should check_client_access be
enhanced to downgrade "unknown" REJECT actions to "DEFER"?

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@postfix.org?body=unsubscribe%20p ostfix-users>