james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Webb" ...@inovem.com>
Subject RE: Improving temporary failure handling in RemoteDelivery
Date Thu, 19 Jun 2003 08:25:17 GMT


> 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 # 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: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message