ietf-smtp
[Top] [All Lists]

Re: Need Help about the conformity of a DSN with RFC

2002-10-04 05:57:42
On Fri, 04 Oct 2002 12:07:29 +0200, 
Nicolas(_dot_)QUENTIN(_at_)fr(_dot_)thalesgroup(_dot_)com  said:

I'll probably regret citing chapter-and-verse before having my morning caffeine,
but.. ;)

The DSN received has for the command part :

      MAIL FROM: <>                                // is it normal to have
an empty adress in the MAIL FROM ?

Not only "normal", but *REQUIRED*.  See RFC821, 1123, and 2821 - this is
how you prevent a mailing loop of bounce notices.

My Main Question is : Is it normal for a DSN to have an empty value in the
Command and to have no From Field in the header part ?

I assume you mean "empty value in the Command" to mean the MAIL FROM:<>, and
yes, that is both normal and required.  However, RFC2822, section 3.6, requires
that there be a 'From:' header.  The usual solution for this is to do the
following:

1) Use an RFC821   'MAIL FROM:<>'   to prevent bounces.
2) Use an invented 822 'From:' header - RFC1894 has this in example 9.1:

9.1  This is a simple DSN issued after repeated attempts
     to deliver a message failed.  In this case, the DSN is
     issued by the same MTA from which the message was originated.


   Date: Thu, 7 Jul 1994 17:16:05 -0400
   From: Mail Delivery Subsystem <MAILER-DAEMON(_at_)CS(_dot_)UTK(_dot_)EDU>
   Message-Id: <199407072116(_dot_)RAA14128(_at_)CS(_dot_)UTK(_dot_)EDU>
   Subject: Returned mail: Cannot send message for 5 days
   To: <owner-info-mime(_at_)cs(_dot_)utk(_dot_)edu>
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=delivery-status;
         boundary="RAA14128.773615765/CS.UTK.EDU"

Note the use of an invented 'From:' header - this would be sent with an
SMTP 'MAIL FROM:<>' (which will normally be made available to an MUA as
the value of the 'Return-Path:' header).
-- 
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech

Attachment: pgpFH3iXCgLqz.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>