I apologize for the length of this post. It involves an argument posed by my ISP regarding my (Eudora) "Redirection" of approved posts to LISTSERV supporting their adulterating of the Date header, and on which I do not believe they stand on good ground. Given the argument relying upon RFCs 822 and 2822 and LISTSERV behaviour in this situation, I have copied this to LSTSRV-L. I am not certain of my interpretation of the RFCs, but I have not encountered SMTP behaviour like this, and I have utilized this configuration and procedure with others in the past without a problem.
My list is configured as follows:
Review= Owners
Subscription= By Owner
Reply-To= List,Ignore
Owner= my_name@my_isp
Send= Editor
Editor= my_name@my_isp
Moderator= my_name@my_isp
For several years (more than one list, same configuration) I have been using Eudora Pro 3's "Redirect" function ("forward" with preservation of From and Date headers) to send approved posts back to LISTSERV for distribution. To ensure that LISTSERV recognizes me as Editor. and Moderator, as the case may require, I have added to one of my Eudora's INI files a line to force the addition of a "Resent-From" header with:
ExtraHeaders=Resent-From: my_name@my_isp
Mid-month, I subscribed to the services of a second (new) ISP for the purposes of LISTSERV and other work-related activities. As I Redirect posts received from LISTSERV back to it with the forced Resent-From header added, my new ISP adds:
Resent-Date (datetime of receipt by SMTP)
Resent-Message-ID (their totally-composed ID)
When the post is processed by LISTSERV, the Resent-Date replaces the Date and the Resent-Message-ID replaces the Message-ID. Where an approved (returned by Moderator) post is sent back to LISTSERV and distributed, instead of it showing with the Date from the subscriber's machine, it now displays the Resent-Date as Date, as generated by my ISP (in another time zone).
I brought this to the attention of my ISP, indicating that I could find no RFC indicating that a server should inject the additional Resent-From headers, to which their technical support replied:
QUOTE
...... section 3.6.6 of RFC 2822 states:
"When resent fields are used, the "Resent-From:" and "Resent-Date:"
fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
"Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
identical to "Resent-From:"."
I believe this suggests that a mail server receiving a message
with a Resent-From: header but not a Resent-Date: is operating
properly by adding a Resent-Date: header.
I believe that the error instead lies with the Listserv software
for chosing (sic) to rewrite the original Date: header with the contents
of the Resent-Date: header. I don't believe that this is the
correct behaviour. In other words, if Listserv would ignore the
Resent-Date: header, there would be no problem.
ENDQUOTE
RFC2822 (April, 2001), as far as I can determine, has yet to be adopted, and is only a proposal. It is *my* machine that has added the Resent-From header, not theirs, and to the extent that RFC2822 is applicable, I interpret the requirement that Resent-Date be sent to apply to the party which adds the Resent-From, not my ISP. Sections 4.2 and 4.4 of RFC822 state:
4.2 FORWARDING
"Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
"Whenever the string "Resent-" begins a field name, the field
has the same semantics as a field whose name does not have the
prefix. However, the message is assumed to have been forwarded
by an original recipient who attached the "Resent-" field. This
new field is treated as being more recent than the equivalent,
original field. For example, the "Resent-From", indicates the
person that forwarded the message, whereas the "From" field indi-
cates the original author.
"Use of such precedence information depends upon partici-
pants' communication needs. For example, this standard does not
dictate when a "Resent-From:" address should receive replies, in
lieu of sending them to the "From:" address.
"Note: In general, the "Resent-" fields should be treated as con-
taining a set of information that is independent of the
set of original fields. Information for one set should
not automatically be taken from the other. The interpre-
tation of multiple "Resent-" fields, of the same type, is
undefined.
In the remainder of this specification, occurrence of legal
"Resent-" fields are treated identically with the occurrence of
fields whose names do not contain this prefix.
4.4. ORIGINATOR FIELDS
The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
Does this not mean that either it is I, if anyone, who should:
a) add Resent-Date and Resent-Message-ID headers, the former updating the Date field; or
b) not add them, leaving the Date and Message-ID headers to take precedence, passing directly through LISTSERV, reflecting the information as generated by the subscriber's machine?
The Resent-Date and Resent-Message-ID headers are not included in the posts as processed by my ISP's SMTP back to LISTSERV but do serve to update the Date and Message-ID fields. They appear only if I email myself.
I almost suspect this new ISP, an offshoot of a Internet software developer, is in actual fact an IntraNet, taking the position of updating my (and my subscribers') information as though I was a workstation on their server, and subject to their interpretation that they are the "Sender". This is the first ISP that I've experienced doing this.
As an aside, it seems also that when I send email through them using Eudora Pro 3.05, any paragraphs exceeding 256 characters are broken with a carriage return one or two lines near the end, with Cyrillic characters preceding the carriage return.
Any ideas?
Thanks!
Michael
|
