WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
please change the topic from "forwarding multi-mime messages broken"
to "any line starting with a dot is broken"
attached 3 files
* HTML-Source with 3 css-classes
* one time sent as plain -> appears with ".." instead "." in the MUA
* one time sent as multimime -> HTML part appears with ".." instead "." in the MUA
so every line in a message received by dbmail3 starting with a dot
is currently damaged
AFAIK this has something to do with RFC 821 wrong proceeded somewhere
this is a regression in dbmail3, not reproduceable with 2.2 in the
same environment (OS, Libraries, MTA, Config....) and currently the
last problem i can find in all my testing on several test-setups
keep in mind i am not that SMTP/LMTP specialist, only try help to
debug as good as i can to polish the dbmail3 final release
Without some provision for data transparency the character
sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
by the user. In general, users are not aware of such
"forbidden" sequences. To allow all user composed text to be
transmitted transparently the following procedures are used.
1. Before sending a line of mail text the sender-SMTP checks
the first character of the line. If it is a period, one
additional period is inserted at the beginning of the line.
2. When a line of mail text is received by the receiver-SMTP
it checks the line. If the line is composed of a single
period it is the end of mail. If the first character is a
period and there are other characters on the line, the first
character is deleted.
The mail data may contain any of the 128 ASCII characters. All
characters are to be delivered to the recipient's mailbox
including format effectors and other control characters. If
the transmission channel provides an 8-bit byte (octets) data
stream, the 7-bit ASCII codes are transmitted right justified
in the octets with the high order bits cleared to zero.
In some systems it may be necessary to transform the data as
it is received and stored. This may be necessary for hosts
that use a different character set than ASCII as their local
character set, or that store data in records rather than
strings. If such transforms are necessary, they must be
reversible -- especially if such transforms are applied to
mail being relayed.