#20 Illegal Content-Transfer-Encoding: BASE64 in created message

[Anonymous]

Then sending files with base64 encoding, blat adds a line

Content-Transfer-Encoding: BASE64

to message.
Some mail client expect encoding type in lowercase

Content-Transfer-Encoding: base64

as Microsoft Outlook Express produces.

Please change the source code that it writes base64 in
lower case:

Content-Transfer-Encoding: base64

[Chip]

Logged In: YES
user_id=800692

Which email client complains?

I will have to check the RFCs when I get home, but I believe
BASE64 in uppercase is defined in the RFCs.

Chip

[Chip]

Logged In: YES
user_id=800692

Read RFC 2045, section 6.1
http://www.ietf.org/rfc/rfc2045.txt

=========
6.1. Content-Transfer-Encoding Syntax

The Content-Transfer-Encoding field's value is a single
token specifying the type of encoding, as enumerated below.
Formally:

encoding := "Content-Transfer-Encoding" ":" mechanism

mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token

These values are not case sensitive -- Base64 and BASE64 and
bAsE64 are all equivalent. An encoding type of 7BIT
requires that the body is already in a 7bit mail-ready
representation. This is the default value -- that is,
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
=========

Note that the RFC uses upper and lower case interchangebly.
Also note that the example give above is in uppercase.

If you are using an email client that cannot handle BASE64
in uppercase, then either switch clients or contact the
developer and get the client program fixed to be compliant
with this RFC.

Chip

[andrus]

Logged In: YES
user_id=813345

The same problem occurs with

Content-Disposition: ATTACHMENT;

blat.dll sends ATTACHMENT in uppercase.

Outlook sends and some ill-designed mail clients expect
ATTACHMENT and BASE64 to be in lowercase.

PLEASE correct blat code so that both are in lowercase:

Content-Transfer-Encoding: base64
Content-Disposition: attachment;

This will make blat more compatible with those mail readers.

I cannot change the mail reading programs which are used by
customers. Changing the blat source is only hope.

[Chip]

Logged In: YES
user_id=800692

Which mail clients are the problem? <--- this is most
important.

Please read the relevant RFCs and you will see that it calls
for these two words to be in uppercase, yet it also states
that clients can and should allow a mixture of upper and
lower case.

Within the last year or two, Blat was using lowercase but
this was identified as a problem then because it did not
follow the RFC.

Chip

[Nobody/Anonymous]

Logged In: NO

This problem occurs when reading emails using free Web-
based email account from http://www.mail.ee/

[Chip]

Logged In: YES
user_id=800692

Is that the only client that is a problem?

Have you written to the site admins to inform them of their
non-compliance with RFC 2045 for message formatting? Their
code is using strcmp() function without first converting to
lower case, or their code could use stricmp() function
instead so it would match mixed upper and lower case letters.

I will need to do some checking before I change to lowercase
words.

Chip

[Nobody/Anonymous]

Logged In: NO

I found that the problem is related to empty message body.

I send pdf files with message empty message bodies by
specifying empty file as message body to blat.

In this case, BLAT does NOT create mime part:

.....
This is a multi-part message in MIME format.

--=_BlatBoundary-7nYcWxMim9ZWVoXuESUuJ
Content-Type: application/pdf;
name="=?ISO-8859-1?Q?
ATOBERG__O=DC_Meiliga_lepingu_lisa_Nr__1=2Epdf?="
Content-Disposition: attachment;
filename="=?ISO-8859-1?B?
QVRPQkVSRyAgT9wgTWVpbGlnYSBsZXBpbmd1?=
=?ISO-8859-1?Q?_lisa_Nr__1=2Epdf?="
Content-Transfer-Encoding: base64

JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFI
vRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nO1ay1YcNxDdz1f0spXQst6PJRz7
kNhO7OAxGzsL4hk/YpjEBPjC
...

Message without text part causes some mail readers to
display pdf attachment as message contents.

However, Outlook Express creates an empty part:

....
This is a multi-part message in MIME format.

------=_NextPart_000_30BB_01C570DE.5935DD00
Content-Type: text/plain;
format=flowed;
charset="windows-1257";
reply-type=original
Content-Transfer-Encoding: 7bit

------=_NextPart_000_30BB_01C570DE.5935DD00
Content-Type: application/pdf;
name="=?windows-1257?Q?
ATOBERG__O=DC_Meiliga_lepingu_lisa_Nr__1.pdf?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?windows-1257?Q?
ATOBERG__O=DC_Meiliga_lepingu_lisa_Nr__1.pdf?="

JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFI
vRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nO1ay1YcNxDdz
....

In this case, mail readers show pdf as attachment.

What is the best way fix it? Should I send a space or
newline to blat if message body is empty ?

[Chip]

Logged In: YES
user_id=800692

As a short term solution, create your "empty" file to be a
single carriage return / line feed pair (two bytes).

Chip

[Nobody/Anonymous]

Logged In: NO

I created a file containing space.

Please confirm, is this mail client bug ?