You indicated that this is a multipart message. That means that there
should be a Content-Type header in the actual header of the message, and it
should say multipart/(something).
The "something" has a lot to do with it.
* mixed means that this part is perhaps supposed to be an attachment,
although what you supplied doesn't have a corresponding Content-Disposition
header.
* alternative means that the same information is repeated in multiple
formats, such as plain text and HTML.
* parallel means it is a multimedia extravaganza. :-p
At least most of the time.
What's interesting about what you supplied was the line which says
X-MIME-Autoconverted, which leads me to believe that some gateway is
mangling the messages; maybe it is misbehaving and not properly formatting
its output.
Marek Wysmulek <marek(_dot_)wysmulek(_at_)hermes-kredit(_dot_)pl>wrote:
OK.
1) Thanks for explanation
2) They are planned messages - no spam.
3) If there is only one header and one body so what is this mentioned
previous
whether it is not first or second ?
OR should I ask other way. I don't complain that procmail produces this
"third part".
I'm just looking for solution how to get rid of this - how to include it to
header or to body
preventing myself from acting with it.
How are you reading these messages? Are you using a client such as Eudora
or Outlook? That is not going to help you with enough information to find
out what is wrong.
Perhaps create a rule such as
:0 B c:
* ^X-Mime-Autoconverted:
./mail/mangled
and save a few messages that way. Then disable the rule (be sure to do this
first!) and open the file up with a text editor on the server and look at
it.
Look for the boundary string declared in the e-mail header Content-Type
line. For each MIME part it should start with two dashes: --boundarystring.
Then, the MIME headers should follow with NO BLANK LINES, then one blank
line, then the body of the part, etc. At the bottom should be the boundary
string again, with an extra two dashes at the end: --boundarystring--.
Procmail is not producing this "third part" unless you are using it to
mangle the information MIME needs to understand the message: if that's
happening, it's not procmail's fault, it is your recipe.
--
Fred Morris
m3047(_at_)inwa(_dot_)net
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail