I summon you, oh Postmasters of the world, to answer this

[Pepinno]

Only the postmasters really knows the tons and tons of spam and garbage email that daily hits the mail servers he tends.

Fighting spam is somewhat doable, with the right tools, the right expertise, and the right "determination" to do what-it-takes...

On that later regard, sometimes "bending the standards" is what it may take.

For example, to those of you with postmaster duties, I ask:

1. Do you reject email sent to the "postmaster" account? Do you even have a "postmaster" account set up?
2. Do you reject email coming to your server with an empty sender?

For according to the standards, receiving email addressed to the postmaster account "must be supported", see section 4.5.1 of RFC-5321:

Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in Section 3.1). The requirement to accept mail for postmaster implies that RCPT commands that specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT

Also according the the standards, accepting mail with an empty sender "must be supported", see section 5.2.9 of RFC-1123:

The syntax shown in RFC-821 for the MAIL FROM: command omits the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page 15). An empty reverse path MUST be supported.

To you I call, postmasters of the world, to come forward and declare what your practice is on these two cases!

 

[barythrin]

You do remember the old saying, the nice thing about standards is there are so many of them. RFCs I don't feel always need to be followed, especially when the majority of the breakage is found to be misconfigured mail clients or spammers. On the flip side your mail server is likely following RFC compliant rules by accepting the mail, it's then up to you and SpamAssassin or procmail or whatever other combo you like to tune the rules for what you consider a spam flag/point and reject it before sending it onward to a valid email account.

As for postmaster yes we route it to another mailbox although it's rarely checked and generally it's more of a risk since the majority of the mail as you probably noted is malware or malicious contents attempting to exploit your mail client.

It's funny, I was just talking to a coworker about this last Friday as well about how we both in previous jobs filtered our own mail using procmail and other rules. I was joking about filtering my pager for some text that doesn't need to wake me up during the night that another department is being lazy about removing.

 

[Pepinno]

On the flip side your mail server is likely following RFC compliant rules by accepting the mail, it's then up to you and SpamAssassin or procmail or whatever other combo you like to tune the rules for what you consider a spam flag/point and reject it before sending it onward to a valid email account.

The problem with procmail is that if only kicks in after you have already accepted the email delivered to your mail server (and before said email has landed into its final destination mailbox), and therefore if you then drop that email you should send a NDR to the original sender. Of course you can choose to drop it and not to send the NDR, but then if it was a spam false positive your users may come to hunt you down that they did not get that so very much important purchase order and it's only your fault!

So it's much better to reject suspected-to-be-spam email during the initial SMTP transaction, so that notifying the sender of the non-delivery remains a duty of the sending SMTP server, and not of your mail server.

 

[barythrin]

I was avoiding a product name drop but one neat opensource and free app is MailScanner which sorta combines clamav with procmail. It will redirect (which you can also do with procmail vs delete it which is what I used to do.. move it to a different mail file/user) but this one has a nice web interface. If it chooses to block anything it goes into a quarantine which you can release with a few clicks. We used it at a corporation once to block both viruses and malicious file attachment types that we didn't approve. In the event that a user or customer did end up sending a file we could still forward it on all in tact. Pretty nice for a freebee.