Email Bounce vs Reject

Standards Dont Match Reality

[incrediBILL]

I follow all of the email standards on my primary servers, SPF records, no relay, and all standard nonsense with one exception. Where I draw the line is I don't BOUNCE, I use REJECT instead, screw the rules and I'll tell you why. If you simply REJECT email that can't be delivered, some of the games spammers play just get deflected off your server, no harm, no foul.

I refuse to be a victim of the spammers games and REJECT it on principle alone ;)

However, if you BOUNCE, that means you have to actually accept the mail, it has to be delivered into your server before it can be BOUNCEd! Now it's YOUR problem, it's clogging up your mail queue, using your bandwidth and busying up your mail server trying to return mail to places that don't exist for days or worse yet, bouncing email to a forged return address.

Next thing you know your outbound mail server has thousands and thousands of these stupid emails bouncing and you can't send or receive anything in a timely manner, it could take minutes or even hours depending on how bad your server got abused. Even better is when the spammers use real return addresses and use your BOUNCE to send junk to people that otherwise are immune to spam. Next thing you know you're getting yelled at by people getting BOUNCE spam just because you had your server set up properly.

Been there, done that, BOUNCE is officially not allowed on my servers, only REJECT.

Mail server queue is virtually empty at all times by making this one simple change to combat spammers games and my delivery time is almost instantaneous and has been for many years. Basically, if you have problems connecting to my server it's not on my end and I have log files to prove it.

That's the other upside, without all the crap bouncing around in the server the log files are so small they're actually useful for debugging real issues that sometimes arise.

Let the email purists complain, I don't care, it's not their server.

[phranque]

i think REJECT would be proper protocol under those circumstances.
most importantly it sends the response signal to the proper place - the sending server.
what reply code do you use?
i would suggest:
420 Put this in your pipe and smoke it.

[topcoder]

I do the same thing, I actually went as far to set up DMARC.

[unlocktheinbox.com...]

Which really cut down the spam.

[incrediBILL]

I always thought a simple way to slow spammers down or stop them altogether was to simply require a valid SSL cert, which costs money, to be installed on the mail software in order to be able to send and receive email. Perhaps require a cert per user for individual email accounts or per domain for corporate accounts. I doubt many would complain if each email address had just a one-time fee associated with a cert per email address if it was reasonable like $10-$25 in order to permanently secure your individual email address or email server per domain.

Especially if that's all it took to put an end to spam by pricing them out of business.

For instance I've been using my primary domain and email accounts for over 15 years now so spending a couple of bucks to get a one-time certification of email accounts for my wife and myself wouldn't be much of a big deal really.

Spammers don't like to spend money, nor do they like to expose who they are, so getting certified would be a big issue. They like to leech off the free resources of others and if the only way to send spam is to buy an SSL cert which would be invalidated as fast as each IP or domain caught sending spam was blocked, they'd run out of money real soon. Best part is they couldn't use the same credentials for getting a new cert after being bagged and tagged for spamming.

The downside is that it would raise the spammers desire to hack into mail servers to an all-time high just to use someone else's certs. The other major downside I can contemplate is that spammers would also want to do ID theft to get certs but the upside is sending phishing emails to steal those IDs would be much harder to do if not next to impossible!