Yes, I was aware of that, but as Mhonarc is normally working with the
archive (we don't use encriptation at the moment, eventhough it was a
good point), I didn't know if it was possible to detect this last part
and added to the contain of the body of the message (so restructuring
the mail). When the mail reaches the inbox of an user normally this
footer is already lost (cut by the majordom software). In any case it's
good to know that is a behavior based on the standards.
Thanks a lot for you explanation,
Earl Hood wrote:
On February 5, 2003 at 18:34, Ruben Gaspar wrote:
I have seen that using mhonarc on mail (coming from a distribution list
with a footer definition) which also contains an attachment, this footer
is lost. Looking at the archive I can see that the mail and footer is
properly archived, in this order:
Mohnarc is not rendering the last one. Is there a possibility to avoid
this behaviour (my Mhonarc version is: MHonArc v2.4.5 (Perl 5.00503)) .
I'm not sure how good your technical knowledge is, but I will
try to explain:
A message with an attachment is MIME encoded, and MHonArc is MIME-aware.
A message of the type you mention would be formated like the following:
Content-Type: multipart/mixed; boundary="XXX"
This is the main body text that you see.
Content-Disposition: attachment; filename="somfile"
[base64 encoded data of attachment here...]
[list footer here...]
According to the MIME specs, everything before the first boundary
(i.e. the first "--XXX") is ignored by a MIME-aware client. Also,
everything after the final boundary "--XXX--" is to be ignored.
The problem is that the list software blindly tacks on the message
footer and does not check if the message is a multipart message.
If the list software wanted to be sure that the footer would get
rendered, it needs to detect then main content-type of the message
and potentially restructure the message. For a multipart message,
it will need to insert the footer as the final part. If the
content-type is a non-text type, it would need to convert the
message into a multipart message to avoid potentially corrupted
the body data.
Actually thinking about it a little more, to avoid problems with
encrypted/signed messages, if the main content-type is not a simple
text type, it would need to convert the message into a multipart type
with the first part being the contents of the message and the last
part being the footer. And, I am not sure that this can be
done properly without invalidating encrypted/signed messages.
In general, I think it is better for list software to utilize
the List-* headers as described in RFC 2369 vs appending data
to messages bodies for the technical reasons highlighted above.
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-USERS
EUROPEAN LABORATORY FOR NUCLEAR RESEARCH
IT Division - Mail Service
Telf: +41 22 7679349
Fax: +41 22 7677155
CERN,CH-1211 GENEVA 23