<snip'd> > > But getting back to RFC 2821, here are its descriptions for > the 4xx codes: > > 421 <domain> Service not available, closing transmission channel > (This may be a reply to any command if the service knows it > must shut down) > 450 Requested mail action not taken: mailbox unavailable > (e.g., mailbox busy) > 451 Requested action aborted: local error in processing > 452 Requested action not taken: insufficient system storage > > Based upon that, 421 and 451 imply trying another server, in > my view. And speaking to the operations center at Road > Runner, they were quite clear that they expect 451 exceptions > to cause mail servers to go to the next one. Those are errors > that are likely to be local to the server. 450 and 452 are > more debatable, however, I will point out that RFC 2821 #5 says: > > When the lookup succeeds, the mapping can result in a list of > alternative delivery addresses rather than a single > address, because > of multiple MX records, multihoming, or both. To provide reliable > mail transmission, the SMTP client MUST be able to try (and retry) > each of the relevant addresses in this list in order, until a > delivery attempt succeeds. However, there MAY also be a > configurable > limit on the number of alternate addresses that can be > tried. In any > case, the SMTP client SHOULD try at least two addresses. > > > To fabricate a case that could justify current behavior, > say I have a > > quota on Joe Smith's mailbox at 10 MB. His mailbox is at > quota, so I > > don't want to accept more messages for Joe. > > That particular example is a mess. The RFC is ambiguous, and > regardless of what some people might say is correct, the > unfortunate fact is that some servers reject with 450, some > with 451, some with 452, and still others with 552. Dreadful. > > > Meanwhile, I have a remote backup server that accepts messages when > > the primary is down. Because it is remote, I can't check whether a > > mailbox is full, so I don't reject based on the quota. > > > Right now our server would see that Joe is overquota, and try again > > later, until either Joe clears some messages or our retry > fails. If > > you change it, you'll deliver to my remote server > > And when the backup server is able to deliver to the primary, > the primary can do the quota checking.
This puts the onus of bouncing the email on the relay. Not a problem for us, as we have sent the email OK (in theory). However this does give us problems when the local mail admin is trying to track a problem, As the mail to that user always seen to be delivered OK. I suppose all we have to do is log the fact that transmission was attempted to a given host for a given mail. > > > But I would have preferred Joe's sister never send those 10 > additional > > 5 MB messages in the first place. > > That is why some servers reject a full mailbox with a 552, so > that the mail is never resent. > > > Sorry the lengthiness > > Don't be! These are good issues. If I didn't want your > view, I would't ask (and I wouldn't be here). > > > it depends on whether 451 is a reply for the domain > > or for this server. On the subject on 451 handling, I think it's a server-only error and you should try another server. > > I agree. It seems to be ambiguous. > > > I tried reading through the RFCs, and am only the worse for it. :) > > I know. They give me headaches, too. > > One thing that we could instead do is change our default > retry behavior. RFC 2821 recommends "favoring a policy of two > connection attempts in the first hour", and every few hours > for at least the next 4-5 days. We default to waiting 6 > hours, and abandon with two days. If we retry sooner, and we > make sure that the MX records are randomized, it should help. > I've just committed a change to do randomization, although > the DNS also does some of that, too. > > By the way, RFC 2821 #4.5.4.1 suggests that we change our > queuing to follow suggestions that we've made earlier. It > says that if we fail in sending a message to a domain, we > should not send other messages to that domain until a timeout > has passed (or we get a message from that domain). > > A client SHOULD keep a list of hosts it cannot reach and > corresponding connection timeouts, rather than just > retrying queued mail items. > > Something for the future queuing model. It would also fit well with a system of limiting the number of simultaneous deliveries to a given domain/host. The ability to do this is critical for large ISPs like AOL etc., as you can find all your deliveries stalling on the slow AOL mail servers. I have implemented a very crude method of doing this, so I might add these features once I've tidied the code up. > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
