# [SOLVED]Mail: How best to cut traffic for unhandled domains?

## c00l.wave

Our servers are configured following the good old Virtual Mailhosting System with Postfix Guide (and work great with some additions - I can't thank the authors enough for that guide). Unfortunately one of our servers is experiencing frequent bursts of huge mail traffic to domains that should not receive mail.

Let's say the correct domain is company.com and one of the domains that are not used for email but only a website is product.com.

E-Mails to company.com are all fine as they are. Lots of spam that gets blocked through policyd-weight, no problem at all.

However, although there never was any active email address on product.com, we are getting lots of mail traffic for that domain. A rate limiter in IPTables already reduced the number of mails to an average of about 60.000 mails per week in bursts of up to 350 mails per minute that occur for a few hours per day. That would be okay if it was just a temporary phenomenon but unfortunately these bursts occur for 2 years now with some month-long breaks in between. I can't think of any reason for it; it just started after product.com had been directed to our server and although it looks like someone is scanning for recipients/usernames, continuing in such rates after 2 years of constant error code replies shouldn't make sense even to the dumbest spammer or cracker. For real DoS attacks, the mail volume is still too low to put any serious load on the host (plus, after 2 years of not blackmailing us or our customer, this would be really stupid to continue resource-wise).

Although we had no impact on availability or performance yet, we would now like to try to reduce the amount of emails reaching Postfix further by blocking hosts accessing product.com as quick as possible for a medium period of time using fail2ban. We already have that working but unfortunately opened a possible way to DoS wanted email coming from MTAs accessible to an attacker and going to company.com (such as free mail services like Yahoo and e.g. contact or order forms that automatically send mail to the given address). That is because unfortunately RFC specifies that MTAs should connect to the A record addresses if no MX record is defined for a domain, so we can in fact send emails from any real MTA to product.com and would get banned by fail2ban for that behaviour. So there is no easy way to tell wanted MTAs from botnet mailers by simply watching incoming connections.

Since there are no recipients on product.com but only on company.com, I got a few ideas to solve that but would like to know what you think about it. Maybe you have tried similar approaches before?

let fail2ban rely on decisions made by policyd-weight based on DNSBLs, so most normal MTAs would not trigger a ban - we would still get garbage traffic from any unlisted sender for product.com

direct mail for product.com to 127.0.0.1 or similar bogus destinations by setting up another A and MX record - this may violate common sense and thus may even be ignored on real MTAs and even botnets (which would then still email to our server instead)

do something else with domain records such as trying to redirect to some bogus port number using SRV records or - this would be best - signalize that the domain accepts no mail with some TXT record if there is a way to explain "takes no email" semantically to fully featured MTAs?

somehow send an SMTP reply with the Enhanced Mail System Status Code "X.1.2   Bad destination system address" in hope that full-featured MTAs will cache that response so they will not attempt to reconnect for a second email any time soon (thus allowing for a justified ban on a second mail delivery from the same IP within 30 minutes or so) - I'm not sure if MTAs can be expected to act this way and I also haven't figured out how to get Postfix to answer with the 5.1.2 instead of "5.7.1 Relay access denied" yet

live with the traffic or get some other server to use as a trash can and direct mails there if it starts to seriously impact performance or availability

----------

## Anarcho

Put the domain (the A-Record) on a server / IP where no MTA is listening.

----------

## c00l.wave

That would match the last option; unfortunately currently all our servers are listening for SMTP, so we don't have one to spare. We could get an extra IP address but today that seems like a waste of resources if we don't need the address for anything else.

----------

## xming

How come that the mails for product.com get to your mail server? Do you have/had a MX for product.com? Is product.com a CNAME to company.com?

Few random thoughts:

- delete MX for product.com (if you have that)

- create a MX for product.com point it to a tarpit (if you didn't have MX)

- reject relaying for product.com on the postfix

- use a pre-queue milter to reject mails for product.com

- use iptables string match to drop the mail connection

no. 3 and 4 are actually the easiest and preferred way to do this, both are done before queuing so that won't affect much on performance.

----------

## c00l.wave

 *xming wrote:*   

> How come that the mails for product.com get to your mail server? Do you have/had a MX for product.com? Is product.com a CNAME to company.com?

 

No, product.com was never used or intended for email. It seems like someone is scanning the server for addresses that it accepts (maybe brute-force login attempts would follow if mail would be accepted for an address). As I said, we can't imagine any reason why the domain is a target and scanning for 2 years without success is plain stupid for an attacker, no matter if that's supposed to be DoS, a login scan or just trying to find addresses to spam. The IP addresses are mostly from some botnet (lots of connections from India, Pakistan, Indonesia, China, Russia, Vietnam, South Korea etc.) but also from some abused "freemailers" (Yahoo, among others).

 *Quote:*   

> - delete MX for product.com (if you have that)
> 
> - create a MX for product.com point it to a tarpit (if you didn't have MX)

 

We don't have an MX record on product.com and don't have any tarpit yet. If the MX does not answer, I fear that the bots will continue to target the A record nevertheless. Maybe it's best to move the website hosted at product.com to another IP without SMTP as well to avoid an A-record fallback if the MX fails. If there is no other way, we may do that.

 *Quote:*   

> - reject relaying for product.com on the postfix

 

We are already rejecting but the number of connections is what I'm a bit worried about and would like to decrease, so catching the traffic in an IPTables rule would be best I think.

 *Quote:*   

> - use a pre-queue milter to reject mails for product.com

 

That could speed things up a little since we are currently first doing a lookup with policyd-weight before Postfix decides that it doesn't take mail for it. Maybe it's enough to change order of these rules.

 *Quote:*   

> - use iptables string match to drop the mail connection

 

That's what we would like to do but cannot until wanted but abused MTAs like those at Yahoo can be told to keep off the domain, since the same host should accept mail for company.com. I was planning for 30 minute long bans of any traffic once product.com has been triggered plus day long bans if 3 tries happened within a few hours. So, if someone sends mails via Yahoo to product.com, we would not be able to accept mails from Yahoo at company.com either (self-made DoS).

PS: I changed the thread title to better express what I want to do. (rejecting mails works of course, but should be improved to reply with a "there are no mailboxes on this domain, stop trying" sort of message)

----------

## Anarcho

[quote="c00l.wave"] *xming wrote:*   

>  *Quote:*   - use iptables string match to drop the mail connection 
> 
> That's what we would like to do but cannot until wanted but abused MTAs like those at Yahoo can be told to keep off the domain, since the same host should accept mail for company.com. I was planning for 30 minute long bans of any traffic once product.com has been triggered plus day long bans if 3 tries happened within a few hours. So, if someone sends mails via Yahoo to product.com, we would not be able to accept mails from Yahoo at company.com either (self-made DoS).
> 
> PS: I changed the thread title to better express what I want to do. (rejecting mails works of course, but should be improved to reply with a "there are no mailboxes on this domain, stop trying" sort of message)

 

I think he means something else. You should not ban an IP address but use iptables to drop the connections on the fly. But this may leave open connections in postfix and will definitely put high pressure on iptables as it has to scan each port 25 connection. I would really put it on another IP if possible. You can of course put mulitple IP addresses on one server and use only one for postfix to listen.

----------

## xming

 *Anarcho wrote:*   

> I think he means something else. You should not ban an IP address but use iptables to drop the connections on the fly.

 

Correct, see this for the idea, http://rhcelinuxguide.wordpress.com/2008/08/05/iptables-string-match-to-drop-malicious-urls/ but I really

don't recommend this.

Replying 5xx is enough to keep legit servers away, why do you need 512 instead of 571? It doesn't matter and 571 is more correct. To answer 512 you need an additional luser lookup. And this doesn't sound right, if there are legit server sending you mails with rctp to: *@product.com then you either have an MX, or product.com is a CNAME to company.com.

 *Quote:*   

> 
> 
> No, product.com was never used or intended for email.

 

We got that in you first post, but you've not answered my questions, did product.com ever had a MX or is product.com a CNAME?

 *Quote:*   

> It seems like someone is scanning the server for addresses that it accepts (maybe brute-force login attempts would follow if mail would be accepted for an address). As I said, we can't imagine any reason why the domain is a target and scanning for 2 years without success is plain stupid for an attacker, no matter if that's supposed to be DoS, a login scan or just trying to find addresses to spam. The IP addresses are mostly from some botnet (lots of connections from India, Pakistan, Indonesia, China, Russia, Vietnam, South Korea etc.) but also from some abused "freemailers" (Yahoo, among others).
> 
> 

 

This happens all the time, dictionary attacks, address scanning, every SMTP admin see that every day, I have seen that for 15 years. What is wrong though is that even yahoo tries to send mail to you, if you don't have MX not is it a CNAME, how can a legit mail server find you?

----------

## c00l.wave

Okay, I misread and didn't consider IPTables string matching but that's not the kind of filter I would like to use anyway.  :Wink: 

 *xming wrote:*   

> Replying 5xx is enough to keep legit servers away, why do you need 512 instead of 571? It doesn't matter and 571 is more correct. To answer 512 you need an additional luser lookup. And this doesn't sound right, if there are legit server sending you mails with rctp to: *@product.com then you either have an MX, or product.com is a CNAME to company.com.

 

Postfix already has all domains configured that it is authoritative for. If a mail for product.com comes in, Postfix already knows that it is not the host who should take that mail, it just does not tell the remote client (well, it already says "relay access denied" but I think "bad destination system address" would be more specific). My idea was that if it would reject the mail by disclosing that it is not configured for that domain name then legit mail servers such as Yahoo would refrain from sending any more email to product.com for some time. That time could be enough to let fail2ban trigger bans on any host that tries to send more than one mail to the unconfigured domain in something like 30 minutes.

 *Quote:*   

> We got that in you first post, but you've not answered my questions, did product.com ever had a MX or is product.com a CNAME?

 

Not that I would know. I think to remember product.com could have been transfered from someone else to our customer before we took it to our account but since then we never set MX records or CNAMEs to other domains. But since that has been at least 2 years ago, I doubt any hosts would still rely on 2+ year old cached records. (even Yahoo finally refresh their caches after at most 2 months)

 *Quote:*   

> This happens all the time, dictionary attacks, address scanning, every SMTP admin see that every day, I have seen that for 15 years.

 

Me as well, but huge amounts of emails to a domain that should never have taken mail is a bit stranger than the usual attacks. The volume of rejected mails over one year of intermittent activity on that customer server is actually already 10 times higher than what our most busy shared mail server accepts, sends and rejects in one year.

 *Quote:*   

> What is wrong though is that even yahoo tries to send mail to you, if you don't have MX not is it a CNAME, how can a legit mail server find you?

 

I was surprised myself but it seems it is actually the common way to lookup mail hosts. If no MX record is set, mail to a domain simply falls back to the A record. That's even specified in the according RFC; there are a few questions on ServerFault asking about exactly the same thing. Since we usually don't get mails to domains without MX records I never actually noticed that until now. You can try for yourself and let Postfix send a mail to a domain without any MX record, it will behave in exactly the same way. As one of the commentators on the above ServerFault answers says, MX records were introduced after mail was already being sent to A records. So the lookup is historically correct although I have never seen it being actually used this way.

----------

## xming

 *c00l.wave wrote:*   

> 
> 
> I was surprised myself but it seems it is actually the common way to lookup mail hosts. If no MX record is set, mail to a domain simply falls back to the A record. That's even specified in the according RFC; there are a few questions on ServerFault asking about exactly the same thing. Since we usually don't get mails to domains without MX records I never actually noticed that until now. You can try for yourself and let Postfix send a mail to a domain without any MX record, it will behave in exactly the same way. As one of the commentators on the above ServerFault answers says, MX records were introduced after mail was already being sent to A records. So the lookup is historically correct although I have never seen it being actually used this way.

 

Oh I totally forgot about that, you are right, when MX is absent, SMTP delivery could try "direct" delivery, using A record.

So you have a A record for product.com? One way is to delete that and create a A record for www.product.com. but then http://product.com won't work any more.

The proper solution would be to create a MX for product.com with either

- fake MX (point to something where no smtp is listening)

or

- null mx (product.com    IN    MX 0 .), 

and

- publish an spf record (@	IN	TXT	"v=spf1 -all") to show the world that no mail would originate from product.com

This will at least help that legit servers won't send you mails any more, but botnets probably still do, hopefully a lot less.

----------

## xming

Oh those mails you see from yahoo are probably bonces. If you just accept all mails fro product.com and the you can see what's going on :p

----------

## c00l.wave

"Null MX" was the correct keyword, thanks.  :Smile:  I found a thread that discusses some methods and their implications. I will set up a SPF TXT record so hopefully mailers that follow SPF will not accept mail from that domain and thus won't need to try sending bounces to product.com in the first place, just in case these are bounces (no need to check that as our customer is not using the domain as a sender). To stop receiving mail from full-featured MTAs I will set up an MX record to something like "doesnottakemail" - according to the thread I found, all common MTAs should take the missing A/CNAME record for "doesnottakemail.product.com" for an instant delivery failure without retries or further queries. Any other connections that come in for product.com should then be safe to ban.

"IN MX 0 ." would work as well but is not the cleanest solution since it has not been defined to stop delivery and there may be cases in which tiny but additional traffic is being produced (the effect is the same as with "IN MX 0 doesnottakemail" with doesnnottakemail.product.com not having any record).

If nothing helps, we can still get an additional IPv4 address. Maybe I will use this opportunity to check if unreachable IPv6 addresses defined through a MX record directing to AAAA records will do the same. Could be that I would be able to save an otherwise unused IPv4 address then.  :Wink: 

Thanks for your advice!

----------

## xming

"IN MX 0 ." should not have the same effect as no MX defined. With "IN MX 0 ." you have a proper MX defined and it say no service, so legit servers won't try to send the mail directly (you A record).

----------

## c00l.wave

I've tested it with an unknown MX (@ IN MX 0 doesnotacceptmail) and get an instantaneous reply if I email product.com from another server:

```
<test@product.com>: Host or domain name not found. Name service error for

    name=doesnotacceptmail.product.com type=A: Host not found
```

The server is no longer being contacted. The instantaneous stop in mail delivery is exactly what was intended. According to the thread I linked above, "@ IN MX 0 ." should do exactly the same but may do a lookup on the root zone first (it's also said that directing to . is the specified way of saying "no service" for SRV records but - at least a few years ago - this was still not officially defined for MX records). Anyway, "@ IN MX 0 ." is not being accepted by the zone file sanitization that our domain provider runs, so I'm unable to set that record.

Since the attacks run Monday to Saturday between 10am and 1pm UTC, tomorrow I will know if anything else is needed. Postfix is already dead silent right now.  :Smile: 

----------

## c00l.wave

It seems like the bots actually obey the MX entry and stay off the server. Of course, we still have the expected "background noise" but with only 200 to 300 (rejected) mails per day that's much less than the many thousand messages we got mainly in only a few hours. Again, thanks for your help; I think the issue is solved.  :Smile: 

----------

