ietf-smtp
[Top] [All Lists]

Re: mailing list footer addition to MIME email

2011-01-15 11:44:26

On 14/01/2011 19:56, Steve Atkins wrote:

On Jan 14, 2011, at 11:31 AM, Dave CROCKER wrote:

Can't decide on the right place to ask this question, so you folks got 
elected...


A list member sends a message that contains a MIME body.  (If it makes a difference 
between a simple, since body that is MIME encoded, versus one that has 
"attachments", then clarifying that is part of the exercise.)

The mail list adds a typical footer to the message and sends it out.

How does the footer related to the received MIME?  Is a new MIME body created? 
Is the footer added as a separate MIME attachment? Is the footer somehow 
distinguishable from the original MIME content?

I'm trying to understand the nature of the violence done by a mailing list to 
the body.
It varies.

I've seen at least these variants:

   1. Append a plain ascii footer to the end of the 822 body. (This ends up as 
a non-displayed MIME postlude for any multipart message.)

   2. Same as 1, but only do it for single part messages.

   3. Append an additional text/plain mime section to the existing 
multipart/mixed capsule (works well for mailing lists that are primarily 
text/plain with attached files).

   4. Create a new multipart/mixed message containing two parts, the first 
being the entire (usually multipart/alternative) content of the inbound mail 
and the second being a text/plain footer.

   5. Modify the content of the existing text/html (and sometimes text/plain) 
section, injecting the content into the existing mime part.

Number 5 is mostly used for advertising supported services, where they want to 
make sure that the eyeballs will always see the injected content, and the 
injected content wants to be text/html. It's painful to do compared with the 
others.

Our mailing list server does (5) (which includes (2)). (1) was our first go when we just wanted a quick solution, and we tried (3) and (4) but had problems with some clients not showing the footer in all cases. We've had far less problems with (5) although it's not ideal (it's difficult guaranteeing you're injecting HTML code into the right place - I'm pretty sure someone could make a message which would hide the footer - eg having an 'illegal' message with an unclosed comment before the end </body> would put the footer inside the comment)