Dear email "administrators"

[trixtah.livejournal.com]

Get a fucking clue about how to configure your systems if you want to play with the other kids on teh intarwebs.

1. Ensure you send your mail from a server that has a goddamned A record in DNS!!! How hard is it? I would like to do the most simple header checks on my mail, but because there are so many morons who administer email servers that don't have a proper DNS entry, I had to turn it off today. And if you administer any local body email servers in New South Wales, you're a moron (as far as I could tell today, none of the servers relaying mail to us from any subdomain at *.nsw.gov.au was properly identifiable).


2. Get a PTR as well. Just one, unlike those idiots in Bahrain who have 24 PTRs associated with one host. No wonder DNS queries time out every time I get a connection from that IP.


3. Make sure your server issues a fully qualified domain name with its HELO. If a server says "HELO < fred>", guess what, that equals "HELO SPAMMER" to me.


4. And if you actually do have enough brain to configure it with an FQDN in the HELO, make sure that bloody FQDN resolves in DNS as well. Again, how hard is it? And why oh why do people use HELO FQDNs that bear no relation to the server that is sending the messages? Idiots. (Oh, ok, sometimes your internal application relays via the mail gateway - it still doesn't stop you from using a resolvable FQDN!)


5. Also, while you're at it, ensure that your MX server actually exists. If it's down for a while, that's one thing, but no A record for that as well makes me suspect it never existed.


6. Guess what? Having a sender domain that actually exists is a wonderful thing as well. Ok, I expect spammers to get it wrong, but if you send mail to us and expect a reply, it helps if your sender domain is correct. (I don't care if your "reply-to" is correct - if your envelope sender domain doesn't exist, I'm gonna bounce your message).


7. For chissakes, do not accept mail to recipients that don't exist in your organisation... and then bounce it to the forged sender address later on. This is called backscatter. It makes sensible admins Very Angry, and gets your servers on RBLs, and then we start bouncing all your emails. If you can't figure out a way of ascertaining who a genuine recipient is on your internal networks, you have just won the Giant Moron prize, and your servers should be forcibly removed from your sweaty hands.


8. If you're an ISP (I'm looking at you, Verizon, Comcast, RR) do something about the spammers that keep hijacking your networks. Implement SMTP AUTH for your senders. Yank machines that start broadcasting excessive traffic. Because I'm sick of our servers rejecting 10s of thousands of messages a day from your bot-infected networks.


9. Don't implement Sender Verification on a global basis. Save it for frequently-forged domains (eg. Hotmail, Gmail, Yahoo) only. I don't need you making unnecessary connections to my servers when our sender addresses are very rarely forged (no more than anyone else), and we have never sent spam. Also, if you suddenly turn on global Sender Verification, the odds are you'll end up on an RBL because your message traffic will double overnight. Which means that we start rejecting your mail, and my users get cranky with me because they're not receiving mail from your stupid network.


10. Start implementing simple header checks, and checks for SPF or DKIM. Publish your own SPF or DKIM records. If you don't know what any of these things are, then find out. Don't touch an Internet-facing mail server until you've assessed their merits.

...I'm sure I'll think of more things when I'm back at my desk tomorrow. ::sigh::

Comments

[the-rkd.livejournal.com]

amen on the points 1,2,3,7 & 8 there fellow bofh.

Also hinet needs to die in a fire

[trixtah.livejournal.com]

Oh hinet. Yes, after we toast their admins' toes slowly over the fire for a few hours first.

[ptomblin-lj.livejournal.com]

11. Don't forward your abuse@ address to a non-existant address.

Sorry, we were unable to deliver your message to the following address.

<egroups-abuse@yahoo-inc.com>:
Remote host said: 550 5.1.1 <egroups-abuse@yahoo-inc.com>... User unknown [RCPT_TO]

...

To: abuse@yahoogroups.com

[trixtah.livejournal.com]

Oh, that's classy. I think I'll try that with postmaster.

[gholam.livejournal.com]

Just for the reference, it took XO half a year - HALF A GODDAMN YEAR!!! - to change PTRs for our client's email servers. I shit you not. All that time, A record was correct, but PTR was pointing to ip_address.xo.net, with predictable consequences.

[mogaribue.livejournal.com]

I love when people get all upset that their email is getting rejected and you look in the logs and it's doing 'HELO localhost'

[jsbillings]

Another complaint: Don't make your MX records contain IP addresses or CNAMEs, that breaks a lot of mailers (because it isn't rfc-compliant).

Nature.com is one of the big offendors of #6 on your rule list, I had to create an exception for them in our rules.

[trixtah.livejournal.com]

Oh, yes, non-A records in MXes drives me nuts. Should have mentioned that too.

Re #6, I find a lot of subscription lists from publications in general have that problem. I mean, ok, they're sending from an application, but that's no excuse.

[jsbillings]

Sadly, this was mail being sent by a journal to reviewers -- something that shouldn't be dropped.

[greenmansgrove.livejournal.com]

Yesterday, I had a client call me because they weren't getting any inbound mail. Why weren't they getting any inbound mail, you ask? Because there was no mx record for mail..com. Nor were there any a records at all. Nor any DNS records of any type. Why is that, you may ask? I certainly asked myself that. It turns out that the authoritative DNS records are hosted by a friend of the accountant, and his system "went down" yesterday, supposedly due to being hit by spammers.

Which wouldn't account for actively MISSING DNS entries. Oh, no.

And when we tried to get ahold of him, he never called back. Oh, until this morning, to bitch about the fact that we transfered the DNS hosting to NetSol, to make sure that they could actually get mail at all. And he wanted me to facilitate moving the DNS hosting back to his server. "No."

So, sometimes, it's not the configuration of the mail server. Or the person who set up the server. Sometimes it's the moron up the line.

Just for the record.

[trixtah.livejournal.com]

Oh, I hear you with the moron up the line - when we got our new mail gateway, our DNS guys created the A records for the servers, and then managed to create the MX records referencing another domain suffix. Ooops. Still, it's important for the mail admins to be able to clobber the DNS guys, or at least palm all the blame off onto them when applicable. :-)

[klfjoat.livejournal.com]

My company performs External Penetration Tests on companies. Among our items to test are #'s 1, 2, 5, and 10. (and blacklist inclusion)

But you wouldn't believe the number of BANKS and FINANCIAL INSTITUTIONS that come back asking why we checked for "SPF", and is REALLY important for them to implement? HELLO? You're getting phished, and you're not sure if SPF would help?

[trixtah.livejournal.com]

Yeah, I am amazed that 100% of financial institutions don't implement SPF or DKIM. At least one or the other.

I was having a problem yesterday receiving mail from a finance company which handled superannuation schemes and investments - if they can't even configure an A record for their mail server, I wonder at just how reliable their service to their customers really is. I even had their admin ring me today to ask me what he needed to do to fix the problem - I mean, hello, if you don't understand the essentials of what your logs are saying ("450 - unknown host" is reasonably obvious), why are you administering mail systems? Forget about such gnarly things as SPF records if you don't even know what an A record is!

[klfjoat.livejournal.com]

The barrier of entry for admins is VASTLY lowered these days. It seems like you can take a few courses, read a cramsession, and bam! Insta-Admin. Just add water (but no knowledge outside of the area of specialty).

I'll be the first person to admit I'm not an old skule admin... but I'm closer to them than this new group. The old skule admins knew lots about everything that affected their systems. New whipper snappers don't have the same drive, fire, and passion to learn. Nowadays, these guys become MCSE's (or other types of admins) who can't pass the A+ exam. Seriously, what old skule admin wouldn't be able to perform basic hardware troubleshooting on his servers?


Security is my area of expertise, and don't even GET me started on that.

[jon787.livejournal.com]

#12. When the revisied SMTP spec explicitly states not to do something because it caused problems in the past, DON'T DO IT!

Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. -RFC 2821 section 2.3.10

I traced this to the ironport antispam server (http://www.ironport.com/) that my mail relay installed.

[trixtah.livejournal.com]

Erm, I hate to think what the Ironport module was doing to the localpart. What was it doing to the localpart? My boss keeps drooling over Ironport appliances, but I've managed to fend him off so far since our current configuration is pretty robust. If I could get more ammunition against the things...

[jon787.livejournal.com]

Its doing Bounce Address Tag Validation, which involves changing the local part of the address give in the MAIL FROM command. It just happens to not be smart enough to tamper with it when it isn't the mail server for the domain in the address too.

My understanding is that this rewriting should only be done on outbound email where the address matches the domain the IronPort server is responsible for. The setup I'm exposed to is rewriting the address on all email. I'm not sure if this is a limitation of IronPort itself or if it is a faulty configuration on the part of our mail server admins.

[jasoncrowley.livejournal.com]

Ere, ere!

Any systems professional who doesn't understand all point above should be put in charge of dusting trashcans, and not else!