gushi: (freebsd logo)

The problem:

  1. FreeBSD comes with Sendmail. Sendmail, in order to verify SSL certs, requires a CAPath (i.e. a bunch of split files, one cert per file), with a hash pointing at each file.

  2. The sendmail docs specifically warn against using too large a cafile, which is why you should use the path (arguably a hack, but what are you gonna do).

  3. FreeBSD's ports only contain ca_root_nss, which installs only a single, monolithic .crt file. (i.e. probably too large)

  4. I can't find a good script which will split this file apart (I mean, sure, I can write one) and generate those hashes.

  5. The tool that comes with openssl that does this is called c_rehash -- FreeBSD rips it out of their base OpenSSL install (probably because it's dependent on perl, which is no longer in base). I think the real solution here is that the port for ca_root_nss needs to just have a port-readme that gives you these commands.

The solution:

  1. Install ca-root-nss from pkg.

  2. cd into the /usr/local/share/certs directory

  3. Split up the certs into their requisite files, using the split command: split -d -p 'Certificate:' -a 3 ca-root-nss.crt foo

  4. Remove the first one: rm foo.000

  5. Use a quick for-loop to generate the hashes: for file in foo*; do ln -s "$file" "$(openssl x509 -hash -noout -in "$file")".0; done

Quickly

pkg install ca-root-nss

cd /usr/local/share/certs

split -d -p 'Certificate:' -a 3 ca-root-nss.crt foo

rm foo.000

for file in foo*; do ln -s "$file" "$(openssl x509 -hash -noout -in "$file")".0; done

Testing it

I did the above, and restarted sendmail, and noticed that now, when I connect to gmail, I get:

Aug 28 22:54:20 <mail.info> prime sm-mta[76815]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1.2, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Which is great.

One thing we're still always going to hit is that SSL validation will always fail here:

Aug 28 22:54:18 <mail.info> prime sendmail[76809]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256"

because our cert doesn't have "127.0.0.1" or "localhost" as common names. No real fix for that, sadly.

gushi: (Default)

Gmail outright rejects mail from my server delivered via ipv6, but allows it via ipv4.

What this means is that I'm going to have to simply maintain a list of gmail MX AAAA's and pump them into an ipfw reset rule like:

reset tcp from me to 2a00:1450:400c:c02::/64 dst-port 25


On the same note, I am getting continually added to various google groups that send me a bunch of Indian CV's for people seeking employment. Google apparently will anyone be added to a google group without confirmation.

I keep maintaining a procmail rule that looks like this:

:0
* 1^0 ^List-ID:.*.shaikhgroups.net
* 1^0 ^List-ID:.*zain-22.zaryabi.info
* 1^0 ^List-ID:.*hadi-20.hadebad.info
# ...more goes here
| /home/danm/spamcopquick.pl

I should probably write a SpamAssassin module that detects this crap, and once it does, rather than filtering the body, detects the list-header and reports as appropriate. (I don't want to reject at SMTP transaction time, because I want the lists to get onto google's radar as a problem that's not simply a delivery issue)

Note: Looks like this journal theme doesn't show the markdown "code" properly. Dammit.

gushi: (Default)

Okay, so I have a redhat 9 box in new york, with a whopping ten gigs of hard drive space. It's a cobalt raq3, and it's basically a spare DNS server, and Nagios box for me.

I recently discovered something ugly. There was no "postmaster" user on this system. Which is fine. /etc/aliases usually redirects that to root.

Except...there was no aliases file.

Picture this for a moment. "Postmaster" is the user that gets a notification whenever there's a delivery failure. Even when there's a failure delivering to "postmaster". Which in turn causes a failure...which causes postmaster to get a notification that that failed.

Yeah, headache, that.

So I try to rebuild the aliases file, and I get newaliases: no database format defined

Apparently, this version of sendmail doesn't actually link against an installed database engine.

So I go, attempt to download a new clean version of BerkeleyDB...only to find that a) the oracle site is down and not responding. I trace down another location for the file, and then I get to have FUN trying to get sendmail to notice that these libraries exist.

Apparently, a good number of the howto's out there are dead fucking wrong about this.

Also, couple this with the fact that Sendmail doesn't use your standard configure, make, make install procedure. It has a shell script in there called "Build". With no clear documentation. And once you run it, it magically holds on to your settings that you've run it with. There's no "make clean" option. Every time it didn't work, I got to blow away and reinstall the fucking thing.

I'm kind of where I want to be now -- although I'm kind of spoiled by BSD, and the ability to have my .mc file in /etc/mail and a nice makefile that just does anything I need it to.

I'd probably like to get StartTLS working on this thing, just so I can say I can....but I'm just happy to get the shit working.

Next: Building a new BIND. Headdesk

gushi: (Default)

So as some of you know, I've been playing with Greylisting recently.

Greylisting is the practice of telling a server that tries to deliver mail with a certain "tuple" (say, sender's-server-ip, sender's-email-address, recipient-email-address). "Okay, let's see if you follow the standards, and retry this address for an hour." Programs that spammers use to send mail, such as Dark Mailer, just fire fast and continuously, and do not re-queue.

If the same tuple comes up an hour later, it's let through.

However, this gets annoying for most people because it makes email that-much less instant.

There are two solutions here:

First, is that upon a successful delivery (i.e. a retry-after-an-hour with a matching tuple, the server can then WHITELIST you (i.e. not force you to delay again -- as long as a message is between that recipient, that sender, and from that mail server IP).

The second, is that the program I'm using milter-greylist, lets you ALSO make use of DNS blacklists, so that the default policy is "let mail through, unless they're on this list, then make them wait an hour"

So, recently, I started using one of the most obnoxious blacklists I could find (APEWS, formerly the SPEWS blacklist), on my inbound mail port, 25.

Spews (Site Archive HERE) has had a reputation for being obnoxious, hard-to-get-off-of, and has had a reputation for listing entire carriers if even a small segment were spammish. APEWS follows in a similar suit. Normally, only an insane person would use it to blacklist people.

Fortunately, one of the cool things about Greylisting, is that it can turn what would normally be a high-collateral-damage blacklist into something perfectly serviceable (so odd to hear a ferret say serviceable...). Mail's not actually rejected, just told "come back later". (Of course, there ARE some blacklists that I actually use as BLACKLISTS -- but those are the more carefully maintained ones.)

My normal "MSA" on port 587 did not have the restriction (since the MSA requires that you auth), so even if spammers know I'm listening on port 587 they can't send anything to it.

Here's what I've discovered:

1) There are still a few ISPs out there who are not blocking port 25, outbound (they SHOULD!).

2) Those users that were ON those ISPs, are also listed in APEWS (probably BECAUSE those ISPs don't block things).

3) My auth-detector wasn't working properly (the port 25 users were authing, but the greylist wasn't recognizing it) and was thus giving the message meant for mail servers to a few of you.

Of course, I've fixed it.

Maybe at some point I'll make a flowchart for all this stuff, and how my mail works.

gushi: (Default)

So as some of you know, I've been playing with Greylisting recently.

Greylisting is the practice of telling a server that tries to deliver mail with a certain "tuple" (say, sender's-server-ip, sender's-email-address, recipient-email-address). "Okay, let's see if you follow the standards, and retry this address for an hour." Programs that spammers use to send mail, such as Dark Mailer, just fire fast and continuously, and do not re-queue.

If the same tuple comes up an hour later, it's let through.

However, this gets annoying for most people because it makes email that-much less instant.

There are two solutions here:

First, is that upon a successful delivery (i.e. a retry-after-an-hour with a matching tuple, the server can then WHITELIST you (i.e. not force you to delay again -- as long as a message is between that recipient, that sender, and from that mail server IP).

The second, is that the program I'm using milter-greylist, lets you ALSO make use of DNS blacklists, so that the default policy is "let mail through, unless they're on this list, then make them wait an hour"

So, recently, I started using one of the most obnoxious blacklists I could find (APEWS, formerly the SPEWS blacklist), on my inbound mail port, 25.

Spews (Site Archive HERE) has had a reputation for being obnoxious, hard-to-get-off-of, and has had a reputation for listing entire carriers if even a small segment were spammish. APEWS follows in a similar suit. Normally, only an insane person would use it to blacklist people.

Fortunately, one of the cool things about Greylisting, is that it can turn what would normally be a high-collateral-damage blacklist into something perfectly serviceable (so odd to hear a ferret say serviceable...). Mail's not actually rejected, just told "come back later". (Of course, there ARE some blacklists that I actually use as BLACKLISTS -- but those are the more carefully maintained ones.)

My normal "MSA" on port 587 did not have the restriction (since the MSA requires that you auth), so even if spammers know I'm listening on port 587 they can't send anything to it.

Here's what I've discovered:

1) There are still a few ISPs out there who are not blocking port 25, outbound (they SHOULD!).

2) Those users that were ON those ISPs, are also listed in APEWS (probably BECAUSE those ISPs don't block things).

3) My auth-detector wasn't working properly (the port 25 users were authing, but the greylist wasn't recognizing it) and was thus giving the message meant for mail servers to a few of you.

Of course, I've fixed it.

Maybe at some point I'll make a flowchart for all this stuff, and how my mail works.

August 2017

S M T W T F S
  12345
678 9101112
13141516171819
20212223242526
27 28293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 07:18 am
Powered by Dreamwidth Studios