Hello!
I could've sworn, there is/was an option to make sendmail automatically
convert base64 messages to 8bit, but I can not find it now :(
Do I have a fake memory, or could someone, please, help me out? Thanks!
-mi
In article
Teterin
>
>I could've sworn, there is/was an option to make sendmail automatically
>convert base64 messages to 8bit, but I can not find it now :(
>
>Do I have a fake memory, or could someone, please, help me out? Thanks!
It's a mailer flag - from doc/op/op.*:
9 If set, do _limited_ 7->8 bit MIME conversions.
These conversions are limited to text/plain data.
This flag is actually set for the local mailer in a default config, and
it's not recommended to set it for non-local mailers as the message may
then end up going through multiple 8->7->8 etc conversions. However IIRC
there is a limitation that perhaps isn't obvious from the above text: I
believe it is only applied when the *message* is text/plain, and not
e.g. to the text/plain part in the common case of a
multipart/alternative message with one text/html and one text/plain
part.
--Per Hedeland
per@hedeland.org
Per Hedeland wrote:
> 9 Ifset,dolimited7->8bitMIMEconversions.
> These conversions arelimited to text/plaindata.
>
> This flag is actually set for the local mailer in a default config, and
> it's not recommended to set it for non-local mailers as the message may
> then end up going through multiple 8->7->8 etc conversions. However IIRC
> there is a limitation that perhaps isn't obvious from the above text: I
> believe it is only applied when the message is text/plain, and not
> e.g. to the text/plain part in the common case of a
> multipart/alternative message with one text/html and one text/plain
> part.
Yes, local mailer and text/plain are what I care about. Could you, please,
post the sample line for my .mc file? I use procmail for local mail delivery:
FEATURE(local_lmtp)
...
FEATURE(local_procmail)
What do I need to add? Thanks!
-mi
In article
Teterin
>Per Hedeland wrote:
>> 9 Ifset,dolimited7->8bitMIMEconversions.
>> These conversions arelimited to text/plaindata.
Oops?
>> This flag is actually set for the local mailer in a default config, and
>> it's not recommended to set it for non-local mailers as the message may
>> then end up going through multiple 8->7->8 etc conversions. However IIRC
>> there is a limitation that perhaps isn't obvious from the above text: I
>> believe it is only applied when the message is text/plain, and not
>> e.g. to the text/plain part in the common case of a
>> multipart/alternative message with one text/html and one text/plain
>> part.
>
>Yes, local mailer and text/plain are what I care about. Could you, please,
>post the sample line for my .mc file? I use procmail for local mail delivery:
>
> FEATURE(local_lmtp)
> ...
> FEATURE(local_procmail)
>
>What do I need to add? Thanks!
As I wrote, the flag is set for the local mailer in a default config -
to verify:
$ grep Mlocal /etc/mail/sendmail.cf
Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=...
^
|
With local_lmtp, your line will be slightly different, but the '9'
should still be there.
--Per Hedeland
per@hedeland.org
Per Hedeland wrote:
> As I wrote, the flag is set for the local mailer in a default config -
> to verify:
>
> $ grep Mlocal /etc/mail/sendmail.cf
> Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=...
> ^
> |
>
> With local_lmtp, your line will be slightly different, but the '9'
> should still be there.
Yep, I have this too:
Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=E...
but the arriving text-only e-mail still arrives (into mboxes) in base64
sometimes...
Thanks!
-mi
In article
Teterin
>Per Hedeland wrote:
>> As I wrote, the flag is set for the local mailer in a default config -
>> to verify:
>>
>> $ grep Mlocal /etc/mail/sendmail.cf
>> Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=...
>> ^
>> |
>>
>> With local_lmtp, your line will be slightly different, but the '9'
>> should still be there.
>
>Yep, I have this too:
>
>Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=E...
>
>but the arriving text-only e-mail still arrives (into mboxes) in base64
>sometimes...
It's probably due to what I described earlier:
>> However IIRC
>> there is a limitation that perhaps isn't obvious from the above text: I
>> believe it is only applied when the message is text/plain, and not
>> e.g. to the text/plain part in the common case of a
>> multipart/alternative message with one text/html and one text/plain
>> part.
Or possibly even due what was clearly stated in my quote from the op
guide. I.e. check the "toplevel" MIME headers on those messages - well,
first check that they actually have any - and verify that
Content-Type: text/plain; charset=
is really among them. Incidentally, when I went to pull up a message
from my mailbox to get that right, the first one I tried had
Content-Type: MULTIPART/MIXED; BOUNDARY=...
in the toplevel headers - and then *only* a text/plain part. I guess
that is legal, but it's really stupid, and if my recollection is right,
sendmail will not do 7->8 conversion on such a message. (Based on the
Message-ID, it appeared to have been generated by Pine.)
--Per Hedeland
per@hedeland.org
Per Hedeland wrote:
> Incidentally, when I went to pull up a message
> from my mailbox to get that right, the first one I tried had
>
> Content-Type: MULTIPART/MIXED; BOUNDARY=...
>
> in the toplevel headers - and then *only* a text/plain part. I guess
> that is legal, but it's really stupid, and if my recollection is right,
> sendmail will not do 7->8 conversion on such a message. (Based on the
> Message-ID, it appeared to have been generated by Pine.)
The difference between "really stupid" or "very smart" is sometimes
only a matter of taste. At least they explain why they do this and how
this can be switched off.
And yes, switching it off was the fist thing I did when I noticed this
new (at that time) default action a few years ago.
From pine's configuration help:
FEATURE: Downgrade-Multipart-To-Text
This feature affects Pine's behavior when sending mail. Internet
standards require Pine to translate all non-ASCII characters in messages
that it sends using MIME encoding. This encoding can be ostensibly
broken for recipients if any agent between Pine and the recipient, such
as an email list expander, appends text to the message, such as list
information or advertising. When sending such messages Pine attempts to
protect such encoding by placing extra MIME boundaries around the
message text.
These extra boundaries are invisible to recipients that use MIME-aware
email programs (the vast majority). However, if you correspond with
users of email programs that are not MIME-aware, or do not handle the
extra boundaries gracefully, you can use this feature to prevent Pine
from including the extra MIME information. Of course, it will increase
the likelihood that non-ASCII text you send may appear corrupt to the
recipient.
Regards,
Kees.
--
Kees Theunissen.
> I could've sworn, there is/was an option to make sendmail automatically
> convert base64 messages to 8bit, but I can not find it now :(
I found it:
define(`confSMTP_MAILER', `smtp8')dnl
Not `esmtp', not `smtp', but `smtp8'.
http://kulichki.com/moshkow/SENDMAIL/base64fiature.txt
Now the messages arrive nicely decoded with:
X-MIME-Autoconverted: from quoted-printable to 8bit by ...
X-Mime-Autoconverted: from base64 to 8bit by ...
I'm surprised, nobody on this forum had an answer :)
-mi
In article
Teterin
>> I could've sworn, there is/was an option to make sendmail automatically
>> convert base64 messages to 8bit, but I can not find it now :(
>
>I found it:
>
> define(`confSMTP_MAILER', `smtp8')dnl
>
>Not `esmtp', not `smtp', but `smtp8'.
>
> http://kulichki.com/moshkow/SENDMAIL/base64fiature.txt
>
>Now the messages arrive nicely decoded with:
>
> X-MIME-Autoconverted: from quoted-printable to 8bit by ...
> X-Mime-Autoconverted: from base64 to 8bit by ...
>
>I'm surprised, nobody on this forum had an answer :)
I had the answer to the question you asked (above), but you apparently
wanted the answer to a completely different question (as given by the
only text I can read on that page) - sorry that my crystal ball was
malfunctioning.
Btw, the smtp8 mailer (i.e. the '8' mailer flag) was basically a
band-aid for way back when the 8BITMIME SMTP extension was new, and many
MTAs were 8-bit-capable without knowing how to advertise it - you must
have a very strange or outdated environment if you need it today.
--Per Hedeland
per@hedeland.org
Per Hedeland wrote:
> Btw, the smtp8 mailer (i.e. the '8' mailer flag) was basically a
> band-aid for way back when the 8BITMIME SMTP extension was new, and many
> MTAs were 8-bit-capable without knowing how to advertise it - you must
> have a very strange or outdated environment if you need it today.
My environment is sendmail-8.14.1. Without smtp8 the arriving e-mail, that
happens to be in base64 or quoted-printable ends up in the mailboxes still
encoded.
With the smtp8 all e-mail in the mailboxes is in 8bit, regardless of how the
previous relay has transmitted it.
I don't, how I could've asked for it more explicitly: "Automatic
base64->8bit conversion"... :)
Thank you very much for trying to help me. Yours,
-mi
In article
Teterin
>Per Hedeland wrote:
>
>> Btw, the smtp8 mailer (i.e. the '8' mailer flag) was basically a
>> band-aid for way back when the 8BITMIME SMTP extension was new, and many
>> MTAs were 8-bit-capable without knowing how to advertise it - you must
>> have a very strange or outdated environment if you need it today.
>
>My environment is sendmail-8.14.1.
With "environment" I was referring to the things surrounding your
sendmail...
> Without smtp8 the arriving e-mail, that
>happens to be in base64 or quoted-printable ends up in the mailboxes still
>encoded.
>
>With the smtp8 all e-mail in the mailboxes is in 8bit, regardless of how the
>previous relay has transmitted it.
>
>I don't, how I could've asked for it more explicitly: "Automatic
>base64->8bit conversion"... :)
There is absolutely, definitely, no way "use smtp8" could be the answer
to that question, since it will *never* cause any base64 (or other 7bit)
-> 8bit conversion to happen. What it *does* do is *skip* 8bit -> 7bit
conversion in (currently rare) scenarios where the RFCs require that you
do such conversion (or bounce the message). But *only* when sendmail
acts as SMTP client (it's only then that the confSMTP_MAILER is used, of
course).
I can think of one or maybe two possible scenarios that somewhat match
your description:
1) Your currently "active" config wasn't what you reported, i.e. it
might have been missing the '9' flag on the local mailer (due to not
having created sendmail.cf from the .mc, or not having installed
sendmail.cf in the right place, or not having restarted the daemon),
and when you applied the smtp8 change, it carried the relevant
setting through as a side effect.
2) You have some convoluted process for local delivery that involves far
more than the procmail usage you reported, perhaps involving
re-submitting the message to sendmail such that SMTP is involved
somewhere in the path, and the actual delivery to mailboxes is done
some other way than sendmail invoking its local mailer.
--Per Hedeland
per@hedeland.org