On Wed, Jun 8, 2016 at 12:29 AM, Bill Cole <postfixlists-070...@billmail.scconsult.com> wrote: > I'm hesitant to disagree with Wietse, but as I read the MIME specification > it seems to me that the missing blank line is *before* the boundary line. If > you add a blank line *after* the boundary you are making the MIME headers > that follow just regular body data. As RFC1521 S.7.2.1 says: > > > [...] the initial CRLF is considered to be attached to the encapsulation > boundary > rather than part of the preceding part. The boundary must be followed > immediately > either by another CRLF and the header fields for the next part, or by two > CRLFs, > in which case there are no header fields for the next part (and it is > therefore > assumed to be of Content-Type text/plain). > > NOTE: The CRLF preceding the encapsulation line is conceptually > attached to the boundary so that it is possible to have a part > that does not end with a CRLF (line break). Body parts that must > be considered to end with line breaks, therefore, must have two > CRLFs preceding the encapsulation line, the first of which is part > of the preceding body part, and the second of which is part of the > encapsulation boundary. > > > So if you had an idiosyncratic boundary string from whatever your problem > source is (so that you could write a regular expression sure to match > nothing else) AND if you can figure out a way to get body_checks to PREPEND > a blank line, that could be a solution. However, I have tried everything > obvious and even some unobvious things and cannot get PREPEND to just insert > a line break as needed for it to be a solution.
My fault, sorry I mislead you; I should write "missing CRLF after the MIME header fields". To make it clear the following is wrong: --=boundary1= Content-type: multipart/related; boundary="=boundary2=" --=boundary2= Content-type: text/html;charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> Segue tabella HTML <TABLE> <TR><TD>1A</TD><TD>1B</TD><TD>1C</TD></TR> <TR><TD>2A</TD><TD>2B</TD><TD>2C</TD></TR> While the following is correct: --=boundary1= Content-type: multipart/related; boundary="=boundary2=" --=boundary2= Content-type: text/html;charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> Segue tabella HTML <TABLE> <TR><TD>1A</TD><TD>1B</TD><TD>1C</TD></TR> <TR><TD>2A</TD><TD>2B</TD><TD>2C</TD></TR> In any case I have no assurance the boundary won't change and there is a good opportunity the same boundary will be used in well formatted MIME messages as well. I do not like the idea to take personally the responsibility of altering the content of emails ... also keep in mind digital signatures. All in all what I need here is a valid reason to justify the "new" behavior of Postfix 2.6.6 compared to Postfix 2.3.3 ... and I definitely found it. Again thanks for you contribution. Ciao Luca
