A short time ago, at a computer terminal not so far away, Liviu Daia wrote:
> All RBL-by-name (or whatever they are called these days) services
>that I'm aware of only list hosts, not domain names, so there's probably
>little point in matching subdomains. Even if it was, there would be
>little point in having separate commands for checking hosts and domains.

I got some useful answers from the rfci mailing list on the question; see
later below.

>> and reject the connection if an A record is found.
>
> Actually, this should only apply to client checks, and only if
>$smtpd_delay_reject set to "no". Otherwise, a second lookup should be
>done for a corresponding TXT record etc.

Yes, it does the TXT lookup if a desired A record was found, but the TXT
lookup isn't required to succeed (as TXT records appear to be optional in a
dns rbl).

And the connection isn't rejected immediately (that was perhaps imprecise
wording). It "rejects the request" as do the other smtpd-restrictions,
returning SMTPD_CHECK_REJECT.

>> If the A-value is specified, reject only if the A record
>> has that value (as many RBL zones use different A-values
>> to indicate different RBL categories, ie inputs, outputs,
>> dialups, etc).
>
> This makes sense, but you probably want some (easy) way to match
>a list of values rather than a single IP. In the absence of a better
>idea, either a plain list (.../127.0.0.2, 127.0.0.3, 127.0.0.5) or a
>regexp (.../^127\.0\.0\.[235]$/) should do.

Yes, I was thinking about adding some way to list the A values, but haven't
yet decided on something that was simple enough to satisfy me. :)

> Like I said, one way or another, you still have to list the services
>somewhere.

True.

>> http://www.megacity.org/pipermail/rfci-discuss/
>>
>> Should the MTA check an rhsbl map for the domainname from the
>> sender envelope, or the domainname of the client? Or both?
>
> The obvious choice is to check RBL-by-IP for the client, and
>RBL-by-name for the envelope sender.

Yeah, checking by client IP is a given, I think. Checking by sender
domainname vs client domainname was really where I was unsure (and the
question of subdomains).

>Checking RBL-by-name for (the
>reverse address of) the client is probably a waste of time, because
>(1) the vast majority of spam comes from relays with no PTR mapping,
>and

True.

>(2) you'd have to handle the case of multiple PTR records (a setup
>that seems to be quite popular among NT admins these days, for reasons
>beyond my comprehension).

Ah, I hadn't thought about that case. Yes, it would produce possibly more
lookups, but it shouldn't be that hard to actually handle in the code.

>Checking RBL-by-IP for the envelope sender
>makes sense, but (1) a sender address may or may not have an A record,
>(2) you'd have to handle the case of multiple records (perhaps also
>MX-es), and (3) if it's on the list, it's more likely to be known by
>name.

Yes, I was never really considering checking by envelope sender IP, as
indeed that didn't seem to make much sense.

There was, though, the idea of checking by complete envelope sender,
including username. I'm still thinking on the specifics of that one,
though, and was leaving it for later questions.

>> Should the MTA check for only the full-domainname, or should it
>> check for any subdomains as well?
>
> IMO, this depends entirely on the servers. AFAICT, RBL servers only
>list hostnames these days.

Based on the answer on the rfci mailing list, as well as further reading of
the listing policies for the zones, my understanding is:

Overall:
 - The rfci lists are properly described as "domain-based" lists, and not
   really "rhsbl" lists.

On checking sender domainname vs client domainname:
 - The DSN list is only valid for checking sender domainnames.
 - The other lists (postmaster/abuse/whois) are primarily intended for
   checking sender domainnames, but checking client domainnames is valid as
   well, and frequently useful.

On checking complete domainname vs checking any parent domains:
 - The MTA should do only 1 lookup, of the complete domainname. Matching
   of parent domains is handled by wildcards in the zones, depending on the
   policy of the individual lists.

So then, on the question of the listing of subdomains in the zones:
 - The DSN and Postmaster zones list only full domainnames.
 - The Abuse zone lists full domainnames plus wildcards to match any
   subdomains.
 - The Whois zone lists full domainnames, and possibly subdomain wildcards,
   depending on the domain in question.

>[...]
>> As far as I can tell, there's not much in the way of documentation
>> or specification for rhsbl's (and little for dnsbl's). I'm guessing
>
> As I pointed out elsewhere, putting RBL on top of DNS was not only
>an ugly hack, it was a stupid one.

No doubt it was convenient and accessible at the time. And it does have
certain appealing features (builtin caching, udp, easily distributed, etc).

>Whoever had that idea should be ashamed of it, rather than write a
>standard. :-)

Well, perhaps we should write a standard for a _new_, proper way to do it,
then. :) Seriously. Otherwise, there's not an apparent alternative when
folks are looking for solutions - and the existing method will just get
used more and more.

There's LDAP, of course, but I'm not convinced it's better. Other than
that, I imagine something would have to be written for the purpose, as I'm
not aware of a pre-existing service that fits well.

-- 
Will Day                  Those who would give up essential Liberty, to 
rom.oit.gatech.edu       purchase a little temporary Safety, deserve neither 
O&E / Tech Support        Liberty nor Safety.
UNIX System Programmer      - Benjamin Franklin, Penn. Assembly, Nov. 11, 1755
  -> Opinions expressed are mine alone and do not reflect OIT policy <-

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (Solaris) Comment: http://hpgx.net/wd/pubkey.asc

iQCVAwUBPIMxABDHlOdPw2ZdAQGgQQP9G318cQfP04CutUNqH2EXK6CC6T51qy4Z iTjSh5FlJm9YooTwDeS3wUgIJHAeFdiQg4KAzRLR++SdpGyI1/v8aavRajEbO/Gg PkIqvmir4obOfcfaor3EpOYj7FeQIY/vfTGk0yqqTj3Zd1XytOVDJuPSMVn2OzHW rj1b/uKkNnI= =+7/4 -----END PGP SIGNATURE-----

- To unsubscribe, send mail to majordomopostfix.org with content (not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]