Happy Thanksgiving all! While I don't think I'll get a response to this question over the holidays, I thought I'd at least present it for response post Thanksgiving. I have a site that (along with others) has decided to use MSExchange as their SMTP hub. One of the problems I am seeing with this is that the current configuration allows for any inbound domain traffic. In otherwords, the exchange server seems to allow emails destin for any domain, then sends a None Delivery Report to the "Mail From" party. My argument is that there lies an exploit with this senario. In otherwords (and those of you that probably know where I am going with this just skip ahead) If I send an email to JoeSmo@domain.com and spoof the Mail From as Victim@innocentdomain.com to an Exchange Server setup in this manor, the Exchange server will bounce an email to the Victim@innoccentdomain.com. While this is all fine and dandy, if a person(s) decides to use this as a mailbomb method and exploit this, its rather simple to do. So, in short I am aguing that 1> Mail destine for a domain not handled should be 550 Denied. 2> None Delivery Reports should only be sent for Domains Handled. 3> That a Firewall should not be doing Domain checking for SMTP What I am at a loss for is RFCs that explicitly state this, that is NDR for other domains, and accepting for other domains. Perhaps I missed something or one of them. Anyone have to deal with this situation? Any suggestions on how to argue this? Am I perhaps missing something? Does Bill Gates feel that "Monopoly is just a game, I want the world!" Just kidding. Thanks in advance, and again Happy Thanksgiving! -Joe
RFC-2505 (BCP-30) talks about which return codes to use, among other things. Not a direct hit, perhaps. RFC-1891 (DSNs) may also have something. You want an RFC-lawyer. Given another hour or so, I could probably come up with the necessary citation, either in the RFCs themselves or in other suitably authoritative-sounding sources. But my pro-bono time has run out for today. :-) Or you could just ask Eric.
ahead) If I send an email to JoeSmo@domain.com and spoof the Mail From as Victim@innocentdomain.com to an Exchange Server setup in this manor, the Exchange server will bounce an email to the Victim@innoccentdomain.com. While this is all fine and dandy, if a person(s) decides to use this as a mailbomb method and exploit this, its rather simple to do. So, in short I am aguing that 1> Mail destine for a domain not handled should be 550 Denied. 2> None Delivery Reports should only be sent for Domains Handled. 3> That a Firewall should not be doing Domain checking for SMTP
What I am at a loss for is RFCs that explicitly state this, that is NDR for other domains, and accepting for other domains.
On Thu, 28 Nov 2002 01:53:06 EST, joej@Rocknyou.com said:
and exploit this, its rather simple to do. So, in short I am aguing that 1> Mail destine for a domain not handled should be 550 Denied.
RFC2821, section 4.2.3 says: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) but the case can be made that a client that's looking at more than the '550' is broken...
2> None Delivery Reports should only be sent for Domains Handled.
There be vicious dragons here. If you get handed a piece of mail, double-check that yes, you *are* a backup MX for the site, accept it with a 250 OK, you've assumed responsibility for it. Now let's say you try to forward it to the destination, and it times out, so you queue it for retry later (and you're PROBABLY going to queue at this point - the original sender wasn't able to reach the primary MX either). You retry later, do the MX lookup again - and get an NXDOMAIN back. The domain doesn't exist, so you don't handle it anymore. But you gave a 250 OK, so now you're morally obligated to send back an NDR. This isn't rare - I get at least 3-4 of these a *day* on our Listserv box. RFC2821, section 3.7: If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path). Formats specified for non-delivery reports by other standards (see, for example, [24, 25]) SHOULD be used if possible. You '250 OK' the mail, you gotta deliver it or bounce it. No other options.
3> That a Firewall should not be doing Domain checking for SMTP
In this case, the firewall would be acting in one of two ways: 1) As a router, just passing the packets to a mailserver in the DMZ. In this case, it probably shouldn't be trying to be clever about examining packets. 2) As a store-and-forward front end - in which case it should be examining *everything* very closely, not just the domain.... (Yes, I know there's fish-nor-fowl boxes that are in between.. They should be avoided - at least once a month there's a Bugtraq posting as yet another fish-nor-fowl box gets bypassed because it doesn't do packet reassembly and/or cross-packet checking of the stream (so sending a short packet to frag the questionable code across multiple packets lets it get through). To return to the original question - there's a large chunk of forest-for-the-trees in your analysis. Yes, somebody could pop out a zillion borked mails so the NDN's bounce to somebody else - it's been done, and it's called Klez. I get dozens of rejections from virus scanners per day for mail I never sent... The crucial point here is that the NDN *itself* is Just Another Email, and the victim's system should have generic protection against *ANY* mailbombing, be they NDN's or just messages. A good option here is to apply some sort of quota or rate limiting to the destination mailbox, and if it's exceeded, return a '450 Requested mail action not taken' if you want legitimate mail to be retried, or a '550' if you want all further mail just dropped on the floor. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
participants (3)
-
Jim Hickstein -
joej＠Rocknyou.com -
Valdis.Kletnieks＠vt.edu