MSRFCs versus RFCs?
Valdis.Kletnieks at vt.edu
Valdis.Kletnieks at vt.edu
Tue Dec 3 05:31:03 UTC 2002
On Thu, 28 Nov 2002 01:53:06 EST, joej at 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'
> 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.
Computer Systems Senior Engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 226 bytes
Desc: not available
More information about the NANOG