[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment

SourceForge.net noreply at sourceforge.net
Tue Apr 18 07:27:25 CEST 2006


Bugs item #1471318, was opened at 2006-04-16 08:22
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Harri Porten (hporten)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing Date header in "requires approval" attachment

Initial Comment:
The message attachment part of the "xxx post from
xxx at xxx.xx requires approval" mails sent to the list
admin are lacking a Date header.

The part currently starts with

   Content-Type: message/rfc822
   MIME-Version: 1.0

while RFC822 mandates a Dates header to exist.

This is with version 2.1.5 compiled with sources on a
Debian 3.1 system. I've seen that the lack of the
header has been fixed for other types of mails but not
the attachment of this admin mail.

Harri.

----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2006-04-17 22:27

Message:
Logged In: YES 
user_id=1123998

I agree that it is mostly harmless either way, but I think
it is correct to include it. The attachment is a
message/rfc822 part and while it never passed through a mail
system as an individual message, it was actually sent as
part of an enclosing message at the time in the header.

Presumably, the recipient list admin will open the attached
message in an MUA and reply to it. When opened, it will look
like a message that was sent at the time in the Date header
we insert which is actually when it was crafted and sent,
and a functional MUA will insert the current time of the
reply in the Date header of the reply, just as it would when
replying to any other message.

I'm not sure what is complaining or what the exact complaint
is in Harri's case, so I don't know what the resultant Date
in his reply will be. I do agree, that if the list admin is
(manually) extracting the confirmation message from the
notice and posting it directly to an MTA, it would probably
be better if we hadn't put the Date in it, but it seems to
be a situation where we can't be 100% right whatever we do,
and both RFC822 and RFC2822 say a compliant message is
required to have a Date, so I lean towards putting it in.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-04-17 21:06

Message:
Logged In: YES 
user_id=12800

I'm not sure I agree that the confirm attachment should have
a Date header.  It's mostly harmless, so I won't argue too
much, but the Date header is supposed to reflect the time
that the originator injects the message into the system. 
The creation of the attachment by Mailman is not the time at
which the confirm message is injected into the system.  That
would be when the recipient of the confirmation uses that
attachment to generate their confirmation.  The header
should reflect the Date of that use, which can be
significantly removed in time from when the attachment was
generated.

I think any MUA that doesn't include it's own Date header in
a reply to the attachment, and sends that to an MTA that
requires a Date header is broken.  But as I say, I think
it's probably harmless to add it anyway, so if you want to
leave it, I won't complain.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-04-17 15:02

Message:
Logged In: YES 
user_id=1123998

Patch committed to subversion trunk.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-04-17 14:37

Message:
Logged In: YES 
user_id=1123998

You are correct. The attached, Mailman generated "confirm"
message lacks a Date: header. This is wrong. The attached
patch against the 2.1.8 base should fix the problem. It will
be incorporated in the next release.

----------------------------------------------------------------------

Comment By: Harri Porten (hporten)
Date: 2006-04-17 12:06

Message:
Logged In: YES 
user_id=873548

Sorry. I just realized that I quoted the wrong set of
headers in my report. My MTA is apparantly complaining about
the lack of the Date header in the *last* part as generated
by Mailman:

--===============0382486014==
Content-Type: message/rfc822
MIME-Version: 1.0

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0
Sender: test-request at example.com
From: test-request at example.com

If you reply to this message, keeping the Subject: header
intact,
Mailman will discard the held message.  Do this if the
message is
spam.  If you reply to this message and include an Approved:
header
with the list password in it, the message will be approved
for posting
to the list.  The Approved: header can also appear in the
first line
of the body of the reply.
--===============0382486014==--

Or does your answer apply to this part as well? I see that
RFC 1521 does indeed relax the 822 restrictions. Not sure
about the Date requirement, though.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-04-16 08:50

Message:
Logged In: YES 
user_id=1123998

RFC822 and RFC2822 only address the top level message
headers. The standard for the headers of sub-parts in
multipart messages is RFC1521.

A Date header is not required in the headers of a sub-part.

If your issue is that the attached message/rfc822 part
itself contains no date header, this is an exact copy of the
message received by Mailman. It was up to whatever sent the
original message to include a Date: header.

If mailman receives a non-compliant message and holds it for
approval, it is not up to Mailman to try to correct defects
in the received message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_id=103


More information about the Mailman-coders mailing list