Dear mail admins

[trixtah.livejournal.com]

I am implementing a new mail gateway. I would like to use some simple antispam checks. But it's quite difficult to do that sometimes unless
you make sure your goddamn server sends out a FQDN with its HELO (it's in the RFC!), and also make sure that that hostname is resolvable via DNS lookup!

Ok, I know that some MTAs might need a bit of configuration to get that happening (*cough*Sendmail*cough*), but Postfix is configured that way out of the box, and so is bloody Exchange - if you can't fix up your own MTA, then you SHOULDN'T be a mail admin. If you can't read an RFC, you SHOULD get into another line of work.

Thanks to you incompetent admins, I need to relax one of my rules, so that I am no longer blocking 70% of inbound messages as spam - I'm now only rejecting 30% of messages due to the 0.1% of you who can't get it right... and who also happen to be important customers, as I found today. *cries*

Comments

[japester.livejournal.com]

It's hard to be a bofh when there are so many stupid people on the planet!

IMO, if it violates the RFC, it gets denied and I have had my manager's approval to do so in the past.
you could push that line with your employer(s) - 5 minutes of work on their part will save you countless hours. so give 'em the one week warning, and then enforce RFC compliance.
their users will complain *but not at you*.

[mouser.livejournal.com]

Check the sending and receiving of Hotmail and Yahoo mail.

Honest to god, I was shocked to find out the number of people that use them for business purposes.

[inahandbasket]

AOL denies mail if you don't have a reverse-lookup specified for your IP. (I borrow bandwidth from my employer with permission.)
Took me months to determine that that was why i couldn't e-mail AOL users from my boxen.

[jarad.livejournal.com]

You poor sod. Someone made you a mail admin. I've been doing it as part of my job for 6 years now... and I can tell you that no matter what rules you implement, there will always be someone who manages to fall afoul of them.

Frankly, we take the stance that if someone has a misconfigured mail server, it is up to them to fix it. Sacraficing a good antispam rule in favour of receiving a small amount of mail from someone who doesn't know what they are doing will not do you any favours in the long term.

I would say I encounter someone with a misconfigured mail server every 2-3 days. But by comparison, we have a 1:24 spam ratio (for every valid email we receive, there are 24 spams we block). So if we were to remove or relax those rules, we would need a 24 fold increase in server resources in order to cope.

I'd say screw them. Put the rule in, and tell them to fix their mail server.

[jecook]

+Infinity... AND BEYOND!!!

[brothersterno.livejournal.com]

I work for an ISP with a reasonable implementation of this, and I have had several accounts complain about not being able to receive email from important clients like this.

So I tell 'em: This is how the internet works, those people need to configure their mailserver correctly, and we are NOT going to change our correct configuration so that you can receive mail from their incorrect configuration.

They don't like it, but the can't escalate.

[squigit.livejournal.com]

1:24? Lord, I complain about our 1:12. (although today's it only at 1:9 - some college somewhere must have its network connection down).

[network-nerd.livejournal.com]

Some ISPs implement a dummy "provide a reverse DNS answer for all addresses" to get around this. Honestly, I don't think AOL (and the other places that do this) really thought about it.

[network-nerd.livejournal.com]

I used to admin an email server that enforced this rule. When we installed it, I stopped getting email alerts from our Cisco VPN box.

It turned out that instead of the FQDN, the code on the box was supplying the destination email address on the HELO line.

I reported the bug, and waited. Nothing.

I tried inserting the box's hostname as the first of the list of destination email addresses. A few days passed, and the box locked up solid. Reboot, and it was fine. A few more days, and it locked up again. RMA'd the box -- NOT cheap.

Duplicated config on replacement box. Same thing. Realized that with an entry in the list of email addresses that didn't contain an "@" anywhere, some parser code (invoked only when there was actually an alert to be emailed) was falling off the end of its buffer and corrupting memory, and that there had not actually been any HARDWARE problem with the RMA'd unit.

Informed Cisco....

[jon787.livejournal.com]

Although it is fun to write daemons that require strict RFC compliance, it could be argued that this configuration is also non-conforming:

The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). -RFC760, 791, 793, 1122, and so on

As far using RFC compliance as a spamfilter, this will work until enough do it that the bot writers learn to write proper SMTP engines.

[brothersterno.livejournal.com]

Well, the RDNS/PTR requirement seems pretty widespread. If spammers start setting up PTR records and proper RDNS, then they are going to be pretty easy to block, and it seems that, as much of the spam I see is from SMTP Daemons running as part of a botnet, they are hiding amongst all the (for example) 067-231-216.lax1.dsl.att.net reverse domains.

That's very different from geographical and reverse blocking which some hosts (US govt, amazon.com) use.