Serge, The particular error I received:
451 4.7.1 Please try again later follows RFC 2034 (http://www.ietf.org/rfc/rfc2034), The 451 code is from RFC 2821, and the 4.7.1 is from RFC 3463 (http://www.ietf.org/rfc/rfc3463.txt), which tries to clean up the SMTP status code mess. Mind you, the use of 4.7.1 seems wrong, although common to both qmail and sendmail. The RFC says (in two parts): 4.XXX.XXX Persistent Transient Failure A persistent transient failure is one in which the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay of attempts to send the message. If this code accompanies a delivery failure report, sending in the future may be successful. X.7.1 Delivery not authorized, message refused The sender is not authorized to send to the destination. This can be the result of per-host or per-recipient filtering. This memo does not discuss the merits of any such filtering, but provides a mechanism to report such. This is useful only as a permanent error. 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. > 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. 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. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
