On 3 March 2002, Will Day <willdayrom.oit.gatech.edu> wrote:
> A short time ago, at a computer terminal not so far away, Liviu Daia
> wrote:
> >On 2 March 2002, Will Day <willdayrom.oit.gatech.edu> wrote:
> >> I've been playing with the rhsbl patch:
> >
> > FWIW, a few month ago I posted a blurb about RBL checks and
> >friends (message 20011018232236.060001028euler.imar.ro, from 18 Oct
> >2001 23:22:36 +0300). At the time, people seemed to agree with my
> >points.
>
> Yes, the rhsbl patch is only a temporary solution, but since I'd made
> those changes locally, I figured I'd pass them along.
>
> I have indeed been reading through all those old threads - trying to
> figure out which direction to go to solve the things I'm looking for.
>
> What you mentioned in that particular message, actually, is kinda
> where I was headed, and to those ends what I have in the local code at
> the moment is:
>
> reject_rbl_client_addr rbldomain[/A-value]
> reject_rbl_sender_domain rbldomain[/A-value]
> reject_rbl_sender_name rbldomain[/A-value]
>
> Look up (respectively) the reversed client network/IP
> address, the sender envelope domain/subdomains, or the
> "user.domain" sender envelope address in DNS zones below the
> given rbldomain,

    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.

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

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

> The rbl_reject_code configuration parameter specifies the
> reject status code (default: 554).
>
> So that you can do, for instance:
>
> smtpd_recipient_restrictions =
> reject_rbl_client_addr relays.ordb.org
> reject_rbl_sender_domain dsn.rfc-ignorant.org
> reject_rbl_sender_domain ex.dnsbl.org/127.0.0.3
> reject_rbl_sender_name users.rbl.hpgx.net
>
> That allows, for instance, using ex.dnsbl.org's easydns entries
> without using its spamsites entries. One disadvantage is that if you,
> say, want to use all of the osirusoft lists _except_ one, you have to
> have 7 reject_rbl_client_addr settings for osirusoft.

    For the particular case of osirusoft, the list / regexp approach
I suggested above would provide a nice shorthand. Otherwise, if the
various types of services are not merged in a single list, you'd have to
write them _somewhere_. Anyway, this is probably not very important,
since RBL servers don't appear and disappear sever times a day.

> Also, it ends up a bit less convenient than maps_rbl_domains, because
> you have lots of smtpd_recipient_restrictions settings, but certainly
> provides greater flexibility.

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

> Before I finish up the code, though, to pass along, there's still
> several remaining questions in my mind about how rhsbls (not to
> mention some kind of "userbl" map) are supposed to work, and what's
> expected of an MTA that checks against them. I posted some of these
> questions to the RFCI mailing list; since they seemed to be one of the
> early rhsbl instances, presumably they should have some idea. :) It
> doesn't seem to have shown at the list archive yet, though:
>
> http://www.megacity.org/pipermail/rfci-discuss/

    To answer your questions:

On 3 March 2002, Will Day <willdayrom.oit.gatech.edu> wrote:
> (note: resent due to problems with local mail)
>
> I'm playing with rhsbl support for postfix, and I find I have some
> questions about how rhsbl maps are supposed to work. :)
>
> In particular:
>
>
> 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. 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 (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). 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.

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

[...]
> 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
> that's because it's just one of those little ideas that sprung up and
> started getting used, without any formal specification. :) It might be
> nice to have that now, though - a nice webpage describing the format,
> specification, expectations, and implementation assumptions for using
> the maps. It sure would make it easier to get support for these added
> to MTAs and such, if there's a usable spec to follow.

    As I pointed out elsewhere, putting RBL on top of DNS was not only
an ugly hack, it was a stupid one. Whoever had that idea should be
ashamed of it, rather than write a standard. :-)

    Regards,

    Liviu Daia

-- 
Dr. Liviu Daia               e-mail:   Liviu.Daiaimar.ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

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