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.

May 2017

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2017 02:42 am
Powered by Dreamwidth Studios