[RFCI-Discuss] multi-MAIL commands appearing in the same mail-transaction?

Peter Kosinar goober at ir.ksp.sk
Tue Jun 6 10:55:40 EDT 2006


Hello,

I'd also like to point out that the original poster apparently referred to 
RFC821 instead of RFC2821. The latter states (section 3.3):

    Historically, the <reverse-path> can contain more than just a
    mailbox, however, contemporary systems SHOULD NOT use source routing
    (see appendix C).

Nevertheless, it's quite interesting to note that RFC2821 still requires 
servers to accept source routes in MAIL FROM: and RCPT TO: commands 
(appendix C):

    Historically, the <reverse-path> was a reverse source routing list of
    hosts and a source mailbox.  The first host in the <reverse-path>
    SHOULD be the host sending the MAIL command.  Similarly, the
    <forward-path> may be a source routing lists of hosts and a
    destination mailbox.  However, in general, the <forward-path> SHOULD
    contain only a mailbox and domain name, relying on the domain name
    system to supply routing information if required.  The use of source
    routes is deprecated; while servers MUST be prepared to receive and
    handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
    transmit them and this section was included only to provide context.

Has anyone investigated whether this is indeed the case with common MTAs?

> A 2nd MAIL FROM command inside a mail transaction is forbidden. See
> rfc2821 2.3.8 and 4.1.4

What should the server do, according to the robustness principle, if the 
client actually issues two MAIL FROM's in one transaction? Section 4.1.4 
of RFC2821 states that:

    If the transaction beginning command argument is not acceptable, a
    501 failure reply MUST be returned and the SMTP server MUST stay in
    the same state.  If the commands in a transaction are out of order to
    the degree that they cannot be processed by the server, a 503 failure
    reply MUST be returned and the SMTP server MUST stay in the same
    state.

However, the first part refers only to unacceptable "command argument", 
not to the command itself, so it doesn't seem to apply to this case. 
The second part would (imho) apply, but it leaves the decision to the 
server ("out of order to the degree that they cannot be processed by the 
server").

Peter

-- 
[Name] Peter Kosinar   [Quote] 2B | ~2B = exp(i*PI)   [ICQ] 134813278




More information about the RFCI-Discuss mailing list