On 8/23/23 4:29 AM, Dan Mahoney (Gushi) via mailop wrote:
I just posted this over on comp.mail.sendmail, but the gist of it is:
Sometimes spamhaus hands off a query to their dnsbls of 127.255.255.255
or 127.255.255.254, indicating that you're being rate limited.
With all due respect, this seems to be more of a /configuration/ (of
Sendmail) problem than it is a Sendmail or M4 problem.
First, multiple RBLs use different A(AAA) values to indicate different
things and have been doing so for years. You can no longer assume that
just because you get an A(AAA) response that an IP is listed.
The different values indicate different things. Some of which can be
rate limiting, others can be allow (white) listing.
I suggest that you re-consider how you are using the RBL.
Second, as others have pointed out, Sendmail has other RBL interfaces /
implementations. Perhaps consider re-configuring your system to use one
of the other methods and / or parameters which behave more to your liking.
Third, you can potentially solve this at a DNS level with something like
BIND's Response Policy Zone wherein you can cause BIND to return
NXDOMAIN in the event that you receive a 127.255.255.255 or
127.255.255.254 so that your existing Sendmail configuration works as
you desire without changing Sendmail.
This is bad, as when you get that, you start rejecting mail.
Again, this is somewhat like saying that it's bad that a soldering iron
burns you when you are holding it by the wrong end. -- Sort of an
extreme, but I hope it demonstrates my point.
I recently discovered this on my personal system as my OS's built
in resolver was silently forwarding to 1.1.1.1/8.8.8.8.
Ya.... That's another kettle of fish.
Fourth, I believe that SpamHaus made a change within the last 12-18
months where they started rate limiting open resolvers like 1.1.1.1,
8.8.8.8, 9.9.9.9, et al.
A single digit number of months (3-6?) before they made that change they
were very vocal about what they were going to do, offered free access
for small operators, and talked about having a trace period where they
would simply return nothing to queries before they finally started
returning additional IPs, which were clearly documented as rate
limiting, thus causing ... questionably configured MTAs to reject out of
hand.
Fifth, I think this is a prime example of why some people, myself
included, suggest to not reject messages just because an RBL lists an
entity (IP, sender, sending domain, URL in the body, recipient, etc.).
The recommendation that I've seen for more than a decade is to have
something, like SpamAssassin, check multiple RBLs for the entity and add
points to the spam score for each RBL that the entity is listed on.
Then, and only then, should you configure your system to reject messages
if the spam score is high enough.
Doing this type of RBL interaction helps protect against entities being
listed on a subset of the RBLs that you've configured your system to use.
Obviously I've already fixed the DNS problem,
Great!
but I'd like to prevent this in the future.
:-)
I'd encourage you to spend a few minutes thinking about how you are
interfacing with RBLs and what you do when doing so.
You could do something as simple as use a different RBL interface like
others have suggested.
You could re-architect which part of your email stack you're doing RBL
interfacing in.
You could put infrastructure around your existing RBL interface to
filter out query responses that you don't like.
You could sign up for SpamHaus's service (free or for pay) and query
them directly in a way that identifies the queries as coming from you to
avoid rate limiting like you ran into.
There are a lot of things that could be done.
It looks like the version of enhdnsbl.m4 simply checks for *any* return
code and doesn't know how to skip those responses. And I don't know
where to buy the brand of LSD that they did at UC Berkeley when they
wrote this, in order to make m4 make sense.
I think that the sendmail.cf (configuration file) is much more of a
problem than the M4 sendmail.mc (macro configuration) that is used to
generate the configuration.
I've been using Sendmail for more than 20 years. It does almost all of
what I want. Exceedingly rarely do I need to go below the established
M4 documented in the cf/README file in the Sendmail source (often
included with Sendmail configuration files on systems).
I have modified an existing mailer cf syntax to support Mailman (2.x)
and promoted that to a MAILER(...) mc syntax to make subsequent use
thereof easier.
I think I found or did similar for SRS support.
I'd bet a fast food lunch for both of us that more than 95% of the
Sendmail configuration that I've done over the last two decades has been
done at the mc level and not at the cf level.
Aside: Notice that the two primary files for the MTA configuration are
sendmail.cf and sendmail.mc. Neither of them are sendmail.m4. Sort of
indicating that the content in the .cf and .mc files are Sendmail
specific and not M4 specific.
The fact that the .mc file is run through M4 is largely incidental and
could just as well have been written in any other macro language. M4
was, and still is, a common language that's used down in the weeds.
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
