Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Patrick via mailop
Yeah, M4 + `make' is great. It's basically Chef/Puppet before those were a 
thing. 

M4 toggles the critic bit in your head. Instead of writing a config file to 
just make the damn thing work, you reduce the config where possible and that 
makes one-offs painfully obvious. And it's wicked easy to start, just `cp $cfg 
$cfg.m4` , and start editing the m4 -- instead of reducing the $cfg to a 
template and a YAML file. 

And because M4 is not well known, all config file syntaxes expand until they 
poorly implement M4
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Grant Taylor via mailop

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

Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Grant Taylor via mailop

On 8/23/23 11:00 AM, Michael Grant via mailop wrote:
I've been waiting for someone to layer something like yaml on top of 
sendmail's M4.


First:  It's not /Sendmail/'s M4.  M4 is it's own stand alone language 
-- one I find quite useful -- which Sendmail happened to utilize.


Aside:  Is it IBM's COBOL if nobody else uses COBOL any more?  Nope, 
it's still just COBOL used by IBM.


I've not done anything with YAML in M4.  I rather dislike YAML.

But I have written what a few different things in M4 that have made my 
life a LOT easier.


 - ~/.ssh/config file manager combined with make and sed
 - /etc/hosts file manager -- respin of the previous
 - rwhois data manager
 - Q & A formater.

The first two were fixed position parameters.  So I ended up with 
multiple macros calls that were effectively:


   host(`hostname', `username', , , , `jump host')dnl

I disliked the fixed position parameters so I created the third and 
forth as more quasi object oriented.


I could do things like the following:

router(
name(`router1')
ip(`192.0.2.1/24')
ip(`198.51.100.1/24')
rack(`A1')
)dnl
router(
name(`router2')
ip(`192.0.2.2/24')
ip(`203.0.113.2/24')
rack(`B2')
)dnl
router(
name(`router3')
ip(`198.51.100.3/24')
ip(`203.0.113.3/24')
rack(`C3')
)dnl
router(
name(`router13')
ip(`192.0.2.13/24')
ip(`198.51.100.13/24')
ip(`203.0.113.13/24')
ip(`100.64.13.13/12')
rack(`D4')
)dnl

I could use the same M4 macro calls to different macro definitions to 
produce different results.


It could easily convert the macros into just about any format of output 
that I wanted.  It was calculating the following given the IP and 
(sub)netmask:


 - subnet
 - broadcast
 - Cisco wildcard

It made it really trivial to maintain rwhois data for a network.

The fourth Q & A formatter took things like this the following:

   question(`What is the square root of three?')dnl

And converted it to something like the following:

   Q:  What is the square root of three?
   A:
   C:

The idea being I could maintain my list of questions as a set of 
individual lines each calling the question macro.  Then when I needed 
to, I could choose questions at random / shuffle / what have you and run 
them through M4 and get a series of question, answer, comment blocks 
output ready to be used in the interview process.


M4 is great at converting one form of text to another form of text.

It's really only your imagination that is the limit of how you convert 
things.



Come on, admit, i know some of you all have thought this too.


Nope, not YAML.  Many other things with M4 have crossed through my mind.

Yes, Sendmail is what introduced me to M4.  But M4 in no way, shape, or 
form limited to, much less belong to Sendmail.




Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Lyndon Nerenberg (VE7TFX/VE6BBM) via mailop
John Levine via mailop writes:

> Yeah, we did that. For a while I was ima!jo...@cca.arpa, decorate to
> taste to get your mail to CCA.

Ah, the precedence wars.  Which comes first, the bang or the at? :-)

--ihnp4!alberta!ncc!lyndon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Chris Adams via mailop
Once upon a time, Sean Kamath  said:
> That’s how I learned BSD4.3’s csh had a fun history expression “bug” (it 
> caused csh to coredump):

Yeah well, csh considered harmful. :)

-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread John Levine via mailop
It appears that Sean Kamath via mailop  said:
>PS For real grins, this was legit (if memory serves — I’d have to dig out the 
>6250 tape backups to confirm):
>
>mail !!%@

Yeah, we did that. For a while I was ima!jo...@cca.arpa, decorate to
taste to get your mail to CCA.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] hotmail.com SPF forgot IPv6

2023-08-23 Thread Gellner, Oliver via mailop

> On 21.08.2023 at 22:33 John Levine wrote:
>
> It appears that Gellner, Oliver via mailop  said:
>>
 SPF contains information about which IP addresses are authorized or 
 unauthorized to send messages for a given domain. It does not contain a 
 policy on what to do with this information.
>
> What's the difference among -all ~all ?all if it's not policy?
>
> (I'm not saying one should pay a lot of attention to the policy, but it's a 
> policy.)

As a non-native English speaker I don’t want to argue about the definition of 
„policy“. What I meant by the term policy is a statement that includes an 
action, comparable to a rule of a firewall: If condition X is true then perform 
action Y.
SPF does not include such an action, neither in the DNS entry, nor in the RFC, 
which just gives you examples of what could be done in various scenarios.

The result of the SPF check can and should be considered when evaluating an 
incoming message, I guess we all agree on that. What I disagree with is that 
emails should be rejected solely based on the SPF result, while ignoring all 
other signals - even when the domain owner published a statement which 
instructs you to do otherwise (to avoid the term „policy“ here).

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Sean Kamath via mailop


> On Aug 23, 2023, at 06:59, Doug McIntyre via mailop  wrote:
> ...
> 
> The Sendmail configuration is mostly a pattern match based setup. For
> back when there were 100's of different email system addressing ways,
> and 100s of gateways between them. If they had to only deal with the
> way Internet mail works today, they would never have had to have the
> complexity seen in the base sendmail config.
> 
> If we suddenly had to deal with the email address complexity of the 80's,
> all the other email servers would fall over dead. 

That’s how I learned BSD4.3’s csh had a fun history expression “bug” (it caused 
csh to coredump):

mail !mailto:u...@arpa.addr>>%

No, I’m not making that up, that’s how I sent my girlfriend at Brown email.

I narrowed it down to a repro with “echo a!x%r”.

So email was so jacked up in the 80s the freakin’ shell couldn’t handle it.

Sean

PS For real grins, this was legit (if memory serves — I’d have to dig out the 
6250 tape backups to confirm):

mail !!%@

Sendmail likely can still parse that (even properly).___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Eduardo Diaz Comellas via mailop

Hi,

I did some raw sendmail.cf configuration. Then some m4. Then moved to 
exim and never looked back.


Nowdays, sendmail.cf is the same as modem noise to me :D

Best regards.

El 23/8/23 a las 18:00, Michael Grant via mailop escribió:

On Wed, Aug 23, 2023 at 09:35:40AM -0600, Paul Ebersman via mailop wrote:

lena> They chose incomprehensible m4 in order to coerce you to buy
lena> support from them.



nice shot. ;)

sadly, as someone who still remembers doing raw sendmail.cf, m4 was a
major improvement over eric's fascinating attempt to create a new AI
language and claim it was a configuration syntax.

of course, "better" is a term of relative worth...

I've been waiting for someone to layer something like yaml on top of
sendmail's M4.  Come on, admit, i know some of you all have thought
this too.

Michael Grant

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
Eduardo Díaz Comellas
Ultreia Comunicaciones, S.L.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..

2023-08-23 Thread Michael Peddemors via mailop
It's been a bit, but this week with so many of the team on holidays, I 
guess it is on me to post an update.. Things that we are seeing..


* Increase of Japanese servers with Email compromises

* Zimbra BEC continues to rise, and with the latest CVE, will expect
  more but it is of course sad to see so many governments and
  enterprises having trouble addressing this.  Same IPs utilized over
  and over.  STARK Industries and Serverion are common sources.
  (Have to self promote here, PLEASE start using SpamRats
  RATS-AUTH/NULL for IP reputation at the AUTH layer)

* Salesforce still having the same problem for a couple of weeks, same
  actors, even the same source emails.. Fake quote requests, UAE
  petroleum companies

* NameCheap still having the same problem with compromises, via their
  webmails, pretty wide spread. Pfizer themed phishing/malware. Going
  on for weeks now.

* HotMail affiliate spammers using 'Calendar Invites' for spam.

* Resurgence of compromised Wordpress spammers

* Digital Ocean (if you haven't blocked them already) continues to
  be the biggest source of Brazilian bank phishing.

* Increase in Vietnamese threat actors

* SharePoint phishing campaign increased again

* Increase in .rar attachments, not surprising with the recent news
  about windows vulnerability.

* GoogleGroups spam continues to get WORSE..

It continues to be a battle, but overall the traditional spammers are 
still getting IP space, seems that even the historically 'good' hosting 
companies are throwing in the towel lately, and letting any one on board


I mean, you have to show growth right? And the other companies that
allow the bad guys to operate, don't see to see any ramifications.. so
why not? Right?

But the trend of phishing and malware continues to grow.  Keep your head 
down, remember to use IP reputation as your first line of defense.


But there is definitely a trend, maybe because of recent economic, or 
global events, that we see a lack of energy and resources being put into
network security, across the board.  So sad that we hear it is hard for 
those interested in cyber security to break into the field.


Hope you enjoyed today's report.

-- Michael --

--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Collider via mailop
Would they? I suspect many would just need a little precision hammering (like 
for elongating gold into gold leaf), some more than others.

Le 23 août 2023 13:59:08 UTC, Doug McIntyre via mailop  a 
écrit :
>On Wed, Aug 23, 2023 at 01:08:36PM +0300, Lena--- via mailop wrote:
>> > 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.
>> 
>> They chose incomprehensible m4 in order to coerce you to buy support from 
>> them.
>
>M4 isn't even the configuration language?!, it is a standard macro tool 
>package that gathered
>bits of configuration together to make configuring it a bit easier for 
>standard setups.
>Having the configuration bits wrangled with M4 came about much later in the 
>lifecycle. 
>Most people haven't used M4 for anything else other than sendmail config bits. 
>
>Sendmail the software was around for almost 2 decades before Sendmail Inc was 
>formed.
>The Bat book was the original tech support..
>
>The Sendmail configuration is mostly a pattern match based setup. For
>back when there were 100's of different email system addressing ways,
>and 100s of gateways between them. If they had to only deal with the
>way Internet mail works today, they would never have had to have the
>complexity seen in the base sendmail config.
>
>If we suddenly had to deal with the email address complexity of the 80's,
>all the other email servers would fall over dead. 
>
>
>___
>mailop mailing list
>mailop@mailop.org
>https://list.mailop.org/listinfo/mailop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Michael Grant via mailop
On Wed, Aug 23, 2023 at 09:35:40AM -0600, Paul Ebersman via mailop wrote:
> lena> They chose incomprehensible m4 in order to coerce you to buy
> lena> support from them.
> 
> 
> 
> nice shot. ;)
> 
> sadly, as someone who still remembers doing raw sendmail.cf, m4 was a
> major improvement over eric's fascinating attempt to create a new AI
> language and claim it was a configuration syntax.
> 
> of course, "better" is a term of relative worth...

I've been waiting for someone to layer something like yaml on top of
sendmail's M4.  Come on, admit, i know some of you all have thought
this too.

Michael Grant


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Paul Ebersman via mailop
lena> They chose incomprehensible m4 in order to coerce you to buy
lena> support from them.



nice shot. ;)

sadly, as someone who still remembers doing raw sendmail.cf, m4 was a
major improvement over eric's fascinating attempt to create a new AI
language and claim it was a configuration syntax.

of course, "better" is a term of relative worth...
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Doug McIntyre via mailop
On Wed, Aug 23, 2023 at 01:08:36PM +0300, Lena--- via mailop wrote:
> > 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.
> 
> They chose incomprehensible m4 in order to coerce you to buy support from 
> them.

M4 isn't even the configuration language?!, it is a standard macro tool package 
that gathered
bits of configuration together to make configuring it a bit easier for standard 
setups.
Having the configuration bits wrangled with M4 came about much later in the 
lifecycle. 
Most people haven't used M4 for anything else other than sendmail config bits. 

Sendmail the software was around for almost 2 decades before Sendmail Inc was 
formed.
The Bat book was the original tech support..

The Sendmail configuration is mostly a pattern match based setup. For
back when there were 100's of different email system addressing ways,
and 100s of gateways between them. If they had to only deal with the
way Internet mail works today, they would never have had to have the
complexity seen in the base sendmail config.

If we suddenly had to deal with the email address complexity of the 80's,
all the other email servers would fall over dead. 


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Andreas S. Kerber via mailop
Am Wed, Aug 23, 2023 at 09:29:48AM + schrieb Dan Mahoney (Gushi) via mailop:
> 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.

Hi,

we're doing it this way:

FEATURE(`enhdnsbl', `.spamhaus.XXX', `"blocked by 
zen.spamhaus.org see: http://www.spamhaus.org/query/bl?ip="$&{client_addr}', 
`t', `127.0.0.2.', `127.0.0.3.', `127.0.0.4.', `127.0.0.9.')dnl


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Michael Orlitzky via mailop
On Wed, 2023-08-23 at 15:04 +0200, Johann Klasek via mailop wrote:
> 
> Wild claim, but funny. For most things or standard configuration stuff
> (even the ednsbl feature) m4's syntax is not to overcomplicated. It's
> more or less in the range of other configuration syntaxes ... (just from
> my perspective).

It's also POSIX, and at least tangentially familiar to anyone who works
with autoconf (when sendmail was written, all unix admins were C
programmers). There are worse choices for sure.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Johann Klasek via mailop
On Wed, Aug 23, 2023 at 01:08:36PM +0300, Lena--- via mailop wrote:
> > 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.
> 
> They chose incomprehensible m4 in order to coerce you to buy support from 
> them.

Wild claim, but funny. For most things or standard configuration stuff
(even the ednsbl feature) m4's syntax is not to overcomplicated. It's
more or less in the range of other configuration syntaxes ... (just from
my perspective).

.Johann

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Lena--- via mailop
> 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.

They chose incomprehensible m4 in order to coerce you to buy support from them.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread ml+mailop--- via mailop
On Wed, Aug 23, 2023, Dan Mahoney (Gushi) via mailop wrote:

> It looks like the version of enhdnsbl.m4 simply checks for *any* return code

Have you checked the fine documentation?

cf/README:

enhdnsblEnhanced version of dnsbl (see above).  Further arguments
(up to 5) can be used to specify specific return values
 ^^
from lookups.
[[...]]

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Any old-school sendmail types here good with the m4?

2023-08-23 Thread Dan Mahoney (Gushi) via mailop

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.


This is bad, as when you get that, you start rejecting mail.  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.  Obviously I've already fixed the 
DNS problem, but I'd like to prevent this in the future.


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.


-Dan

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop