> The latest spate of viruses has caused someone to ask me if attachements
> should be removed from messages that are returned with bounces.
Attachements yes, but not text/plain ones.
> The problem is that Exim doesn't analyse message bodies in any way.
> Properly sorting out MIME parts isn't trivial, as I understand it.
I've done MIME parsing in perl. It was fun. I did that so I could save
each part of a message as a seperate file (Don't ask =)
> Three fairly simple things could be done:
>
> 1. An option called bounce_return_body, defaulting TRUE, which, if
> turned off, would cause only the header to be returned in a bounce.
> I suspect few would set it. Should the default be FALSE?
Definately not in favor of this.
> 2. An option called bounce_something which would do a simple job of
> looking for a "boundary" in a Content-type: header, and just return
> up to the second boundary - i.e. return only the first part of a
> message, assuming that it is not an attachment. I'm not all that keen
> on this one, because it is a hack.
What if the message is a multipart alternative with attachments. You'll
have to look at the boundaries for the nested part.
I just looked at a message I have. It's type is multipart/mixed. First
part under it is multipart/related. First part under that is
multipart/alternative (it was outlook that sent it to me BTW), then finally,
it's text/plain.
IMO, the text/plain should be the *ONLY* part sent and *ONLY* upto the first
"begin xxx somefile" line (where xxx is 3 octal digits) or the size limit
whichever comes first.
Writing the mime parser I played with different aspects of a message
including UUencoded files inside of plain text messages with different MUAs
> 3. The default value of return_size_limit is 100K. It could be reduced
> to, say 10K.
I would be infavor of that since I've been bombarded myself with 100kb
bounces and my server is on dialup.
--
Lab tests show that use of micro$oft causes cancer in lab animals
