On Fri, 2008-03-28 at 11:15 +0900, John Summerfield wrote: > Craig White wrote: > > > You're 'not sure that a server really *has* to resend' ? > > You are implying it must. What text of rfc 2821 does it violate ifit > doesn't? ---- A temporary fail code of 450 occurs at the RCPT stage as you know and there is no way that the sending server can mistake this to be a successful delivery. A permanent fail code like 55X renders redelivery pointless and the original sender should be notified. As for handling re-delivery, this section covers it... 4.5.4.1 Sending Strategy The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable. As to the notions of 'has to' or 'violated' sections...there is only that which is reasonable and prudent and by all custom (and the language above), it's obvious that re-delivery is expected, customary, and standard practice for all SMTP servers I have dealt with. You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it. Craig -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
