|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MSRFCs versus RFCs?
On Thu, 28 Nov 2002 01:53:06 EST, [email protected] 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 Attachment:
pgp00001.pgp
|