On 2 Aug 00 at 21:06, [EMAIL PROTECTED] wrote:
> The removal of the "charset" parameter is probably caused by
>
> (a) some component on your PC or at your ISP attempts to "decode"
> character triplets starting with a = followed by 2
> letters/digits (as the string "charset=" followed by "ISO..."
> got the "=" and the 2 letters "IS" removed), and
>
> (b) your SMTP server software checks the wellformed-ness of
> the mail header lines and removes illegal parameters.
>
> There is nothing wrong with (b), i.e. the removing of the
> misformed "Content-type:"-parameter. The cause of the problem is
> the inappropriate "decoding" in (a).
>
> Therefore the correct place to fix is to find out which component
> incorrectly decodes constructs like "=xx" in your mail headers,
> and to fix or replace this piece of software. (Mail header lines
> must not be MIME-decoded unless specifically marked per RFC
> 2047.)
>
In the last week of July, my internet provider (telecom - iol.cz) finished
their upgrade and the problem seems to be gone (I dare not say solved).
The whole operation took three months while Czech diacritics had not been
working. The people on the provider's hotline had very little understanding
of what was going on, but assured me that in the end it will work as it did
before...
Now, I look forward to the next upgrade. May be then it will not work as
it did before. Or is there anything you can do in order to avoid problems of
this kind? There are two more observations I could make last week:
A.
> > Pegasus produces outgoing mail with Czech diacritical
> > characters in that form:
> > MIME-Version: 1.0
> > Content-type: text/plain; charset=ISO-8859-2
> > Content-transfer-encoding: Quoted-printable
>
> > When I sent these kind of mails to my own address some
> > of them returned with only one line changed:
> >
> > Content-type: text
> >
> > So the mail client could not translate the 7-bit code
> > to the East European charset.
Until April this year, charset encoding had been working without problems.
That time I used SMTPOP11.EXE for mail transport. Then SMTPOP11.EXE
stopped to work on the server iol.cz: The mails prepared by
Pegasus remained in their place. Only download with POP3 from the same
server address worked. Changing the software seemed to be the solution:
SMTPOP.EXE (an older version of SMTPOP with login name and password in
the command line not in a database) successfully uploaded every mail.
Only after some time I realized the loss of the charset information.
Now, I returned to the use of SMTPOP11, and actually the charset problem
does continue as far as I upload mail by SMTPOP. So this program seems to
be incompatible with the transfer of 8bit mails. The question why would not
bother me, if I had some reason to believe that SMTPOP11 will still work even
tomorrow.
B.
As I have WWW and email accounts with another server (VOLNY.CZ) I tested
other ways of sending and receiving mail mainly through an internet
connection with the DOS browser Arachne.
There were some problems: Login on the server VOLNY.CZ is more difficult.
Mail transport with the mentioned programs was possible, but the programs
were always terminated by timeout. Besides that both servers IOL and
VOLNY took some measures against spam, so it became impossible to use
one connection for different email accounts.
On the other hand Arachne turned out to be quite useful for downloading mails
from my different accounts. Obviously Arachne has a more clever way of
authentication at smtp server. So in the end I decided to download all my
incoming mail with Arachne instead of SMTPOP or SMTPOP11.
Doing so I made an interesting observation: My alternative server
pop3.volny.cz handles the charset information completly different than
pop3.iol.cz:
a) header of file received through pop3.volny.cz
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-2
Subject: receive test arachne
Priority: normal
X-mailer: Pegasus Mail v3.31
Message-Id: <[EMAIL PROTECTED]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by mail.volny.cz id
e7AJSOM34562
Status: U
X-UIDL: 965935705.34578.mail.volny.cz
x|Fideg+^2�o/Theta
b) header of file received through pop3.iol.cz
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-2
Content-transfer-encoding: Quoted-printable
Subject: receive test smtpop11
Priority: normal
X-mailer: Pegasus Mail v3.31
Message-Id: <[EMAIL PROTECTED]>
=EC=B9=E8=F8=BE=FD=E1=ED=E9
I cannot sy that I am happy with this kind of autoconversion. Am I right when
I consider this to be an unevitable property of that pop3 server?
Greetings
Christof Lange, Prague
_______________________________________________
Christof Lange
Prokopova 4, 130 00 Praha 3, Czech Republic
phone: (+420-2) 22 78 18 00 / 22 78 20 02
fax: (+420-2) 22 78 18 01
email: [EMAIL PROTECTED]
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
