MSRFCs versus RFCs?

Mailman List Mirror (Read Only)
1

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

2

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. :slight_smile:

Or you could just ask Eric.

3

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.