----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: "ietf-822" <ietf-822(_at_)imc(_dot_)org>
Cc: "Pete Resnick" <presnick(_at_)qualcomm(_dot_)com>
Sent: Thursday, January 27, 2005 1:57 PM
Subject: Re: Mandatory From field, anonymity, and hacks
As a result of our discussion starting July 15, 2004, I
have prepared an Internet Draft; draft-lilly-from-optional-00.txt
should be available from the usual places [*]. Public comments
may be posted to the ietf-822 list; private comments to the
author are also welcome.
* E.g.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lilly-from-optional-
00.txt
Bruce, I don't wish to be combative here so please bear with me here.
We never depended on the 822.From, but obviously this is going to change a
few things. So I wish approach this by asking what as the expected "design"
behavior for SMTP, GATEWAY software that do more than just move mail, but
also help prepare the expectations of the edge software.
The first question.
Which software is responsible to make sure the format is correct? The MUA?
The SMTP Receiver?
Most, if not all SMTP receivers detect valid headers and add what is
necessary.
Based on RFC 822 (A.3.1. Minimum required), a valid RFC 822 header is one
that has:
Valid RFC header = Date: && From: && (cc: || bcc: || To:)
This was relaxed in RFC 2822 , where a valid RFC 2822 header is one that
has:
Valid RFC header = Date: && (From: || Sender: || Reply-To:)
Are you proposing further relaxation as follows?
822: Valid RFC header = Date && (cc || bcc || To)
2822: Valid RFC header = Date && (Sender || Reply-To)
I guess a comment can be made about valid versus completeness.
From a point of view of Completeness:
Technically, a message needs no headers at all.
In a 822 model, a missing Date: is the time of the transport and the To:
can be the 2821.RCPT TO, and any CC: can be the 2nd and additional 2821.RCPT
TO: in the transaction.
In the 2822 model, the missing Date is the time of the transport, and the
Originator can be the 2821.MailFrom.
So the next and final question is:
Is a RFC header required in the DATA stage at all?
This is important because it is always import in the AVS arena.
If a system allows for no RFC headers, than the new message will have based
on your proposal:
Return-Path:
Received:
Date: <-- Transport Time
Sender: <-- 2821.MailFrom
To: <-- 2821.RCPTO(1)
cc: <-- 2821.RCPTO(2..n)
From a point of view of Validity:
A system can view the lack of such information for message
validity/integrity with possible rejection logic behind it. I personally
don't know of any server who does this, but it is possible.
I guess basically what would really help in this proposal (as well as
others) is what is the expected design for the software when such
information is not available and/or it needs to make an adjustment. There
is talk of "Should, Must" etc, but what does that mean today?
I understand fully and agree 100% that mail integrity must be maintain, but
where is the borderline here? What makes the message header valid and if
one or more "required" parts are missing? What does RFC 2822 and your
proposal say should be done?
Start with the obvious. No headers provided.
I bring this up because it is more than just the receiver that we are asking
the vendors of software to do. We are asking the creator of mail to do
more, to be more consistent, be it for mail authentication etc, we need to
look at how one system is expected to behave versus how we can use this
information for verification just as well.
Thanks
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com