headers
David Van Stone | 10 Nov 2005 17:37
Picon

carriage return as ctrl-char?


Hi,

  I've been using nail for several months now and have been quite 
happy with it.

  I have a question. When I send a message with a carriage-return
character in the body, the message gets flagged with "MIME_CTRLCHAR" 
in mime.c and gets encoded as quoted-printable. The preferred
behavior (from my standpoint) is to keep it as text/plain and keep
the 7bit encoding. (I have CRLF at end of some of the lines.)

  From what I've read online, it seems like form-feed, tab, carriage-
return, and line-feed should all be valid ASCII characters to send
in the body.

  Here's my suggested change.

  In mime_isclean, line 746:

from
      } else if ((c < 040 && (c != '\t' && c != '\f')) || c == 0177) {

to:
      } else if ((c < 040 && (c != '\r' && c != '\t' && c != '\f')) || c == 0177) {                                     ^^^^^^^^^

  Let me know if this sounds reasonable and if I should figure out
how to use the CVS repository and patch it myself.

-David Van Stone-
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gunnar Ritter | 10 Nov 2005 18:10
Picon
Favicon

Re: carriage return as ctrl-char?

David Van Stone <dvs@...> wrote:

>   I have a question. When I send a message with a carriage-return
> character in the body, the message gets flagged with "MIME_CTRLCHAR" 
> in mime.c and gets encoded as quoted-printable. The preferred
> behavior (from my standpoint) is to keep it as text/plain and keep
> the 7bit encoding. (I have CRLF at end of some of the lines.)

From my standpoint, it is not. If one of my files has a carriage
return character in it, I do want to send it as binary.

Also see the NOTES section of the manual page.

>   From what I've read online, it seems like form-feed, tab, carriage-
> return, and line-feed should all be valid ASCII characters to send
> in the body.

Not exactly, cf. RFC 2045 section 2.7 and POSIX.1-2004 XBD 3.392.

What happens in nail is: Unix text files, which use only LF as line
endings (both by tradition and by the POSIX standard), get converted
to CRLF when they are passed over an Internet protocol (but not when
they get passed to sendmail). In the reverse direction, CRLF received
via an Internet protocol gets converted to LF.

If a Unix file contains a CRLF, it is still a text file according to
POSIX, but it is not a file just with a line ending, but a file with
a line ending and a control character before. This control character
has no representation in MIME text data, so the file cannot be sent
as MIME text. Just discarding the CR might destroy data, and CRCRLF
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Van Stone | 10 Nov 2005 19:06
Picon

Re: carriage return as ctrl-char?


> David Van Stone <dvs@...> wrote:
> 
> >   I have a question. When I send a message with a carriage-return
> > character in the body, the message gets flagged with "MIME_CTRLCHAR" 
> > in mime.c and gets encoded as quoted-printable. The preferred
> > behavior (from my standpoint) is to keep it as text/plain and keep
> > the 7bit encoding. (I have CRLF at end of some of the lines.)
> 
> From my standpoint, it is not. If one of my files has a carriage
> return character in it, I do want to send it as binary.

Gunnar -

  I appreciate your prompt response and your explanations. I'll find a 
way to work out the issues I'm having without this change. 

Thanks,

David Van Stone

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
Permalink | Reply | 0 comments |
headers
yuki | 18 Nov 2005 08:12
Picon
Favicon

Re:

Š®„«‘S„«–³„«—¿„«•„«Žg„«‚¢„«•ú„«‘è„«
„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®„ª„®
 <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at> ¤¤¤¤¤¤
http://www.checkcheck-zero.net/?id=pc120

Ÿ“ü‰ï”ï^”N‰ï”ï
žƒ[ƒ‹ŽóM•‘—M
Ÿ—‘z‚Ì‘ŠŽè^‚²‹ßŠŒŸõ
žŽÊ^^“®‰æ‚Ì“o˜^•‰{——
ŸZŠ^ƒAƒhƒŒƒX^“d˜b”ԍ†‚ÌŒðŠ·

’j«‰—«Š‚Æ‚à‚ÉŠ®‘S–³—¿‚Å‘S‚Ä‚²—˜—p’¸‚¯‚Ü‚·B
http://www.checkcheck-zero.net/?id=pc120

ˆÀSƒTƒCƒgéŒ¾
EEEc„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ªš
ƒ‰ƒuƒŠ[ƒ[ƒ‹‚̓Xƒ|ƒ“ƒT[ƒTƒCƒg—l‚©‚ç‚̍L—¿‚݂̂ʼn^‰c‚µ‚Ä‚¨‚è‚Ü‚·B
‚»‚ׁ̈A‘SƒT[ƒrƒX‚ðŠ®‘S–³—¿‚Å‘S‚Ä‚²—˜—p’¸‚¯‚Ü‚·B
—‘z‚Ì‘ŠŽè‚ð‹‚ß‚é•ûX‚ɈÀS‚ƐM—Š‚ð‘æˆê‚ɍl‚¦‚È‚ª‚çA
‹CŒy‚É‚¨Žg‚¢’¸‚¯‚éƒT[ƒrƒX‚ð–ÚŽw‚µA
–œ‘S‚̃Tƒ|[ƒg‘̐§‚ÅŠF—l‚ɍ‡‚Á‚½‚¨‘ŠŽè’T‚µ‚ð‚¨Žè“`‚¢‚µ‚Ä‚¨‚è‚Ü‚·B
š„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ªcEEE
http://www.checkcheck-zero.net/?id=pc120

--
”zM‹‘”ہF
kissme_rej@...

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
(Continue reading)

Permalink | Reply | 0 comments |
headers
pascal.bombardier | 18 Nov 2005 10:17
Picon

Bug when sending PDF attachment

Hello

I use nail to send PDF files as attachment.
In case of the joined PDF file, it gets corrupt, and I noticed that LF
where changed to CRLF inside the PDF file.
Try to send this file with nail and it gets corrupt.
(See attached file: 109.pdf)

When analysing the situation, it seems that in this particular case the PDF
is sent as 'quoted-printable' instead of 'base64'.
I made this modification in file 'mime.c' to correct the error

============================================================
int
get_mime_convert(FILE *fp, char **contenttype, char **charset,
            enum mimeclean *isclean, int dosign)
{
      int convert;

      *isclean = mime_isclean(fp);
/*    if (*isclean & (MIME_HASNUL)) {     */
      if (*isclean & (MIME_HASNUL) || *contenttype == NULL ||
                  ascncasecmp(*contenttype, "application/", 12) == 0) {
============================================================

Explanation
if mime type is not found or the mime type is of type application, then
data should
be considered as binary data.
Hasnul is not sufficient, because in the pdf sample, no null is present in
(Continue reading)

Permalink | Reply | 1 comment |
headers
pascal.bombardier | 18 Nov 2005 10:30
Picon

Bug when sending PDF attachment (2)


============================================================
int
get_mime_convert(FILE *fp, char **contenttype, char **charset,
            enum mimeclean *isclean, int dosign)
{
      int convert;

      *isclean = mime_isclean(fp);
/*    if (*isclean & (MIME_HASNUL)) {     */
      if (*isclean & (MIME_HASNUL) ||
                  ascncasecmp(*contenttype, "application/", 12) == 0) {
============================================================

Explanation
if the mime type is of type application, then data should be considered as
binary data.
Hasnul is not sufficient, because in the pdf sample, no null is present in
the file.

Pascal Bombardier
pascal.bombardier@...

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
Permalink | Reply | 0 comments |
headers
Gunnar Ritter | 18 Nov 2005 15:52
Picon
Favicon

Re: Bug when sending PDF attachment

pascal.bombardier@... wrote:

> I use nail to send PDF files as attachment.
> In case of the joined PDF file, it gets corrupt, and I noticed that LF
> where changed to CRLF inside the PDF file.
> Try to send this file with nail and it gets corrupt.
> (See attached file: 109.pdf)

If I send _and_ receive/decode the file with nail, the result is
correct. Same when decoding with mutt or Mozilla Thunderbird.

> When analysing the situation, it seems that in this particular case the PDF
> is sent as 'quoted-printable' instead of 'base64'.

The quoted-printable encoding is principally able to transport
binary data. Which application did you use for decoding?

> I made this modification in file 'mime.c' to correct the error
>
> ============================================================
> int
> get_mime_convert(FILE *fp, char **contenttype, char **charset,
>             enum mimeclean *isclean, int dosign)
> {
>       int convert;
>
>       *isclean = mime_isclean(fp);
> /*    if (*isclean & (MIME_HASNUL)) {     */
>       if (*isclean & (MIME_HASNUL) || *contenttype == NULL ||
>                   ascncasecmp(*contenttype, "application/", 12) == 0) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
pascal.bombardier | 18 Nov 2005 16:11
Picon

Réf. : Re: [nail-devel] Bug when sending PDF attachment


I send the pdf file from a unix server to a lotus server (don't know if it
is unix or windows), and then I read my mail with Lotus Notes from a
windows PC.
Somewhere in the process the LF inside the PDF are converted to CRLF, which
corrupts the file.
Using base64 solved the problem for me, but I understand it is not a
solution for everybody.
In fact, I don't know if it is the right solution, the fact is that it
works in this case.

Thanks a lot

                                                                                                                                       
                      Gunnar Ritter                                                                                                    
                      <gunnarr@...         Pour :   pascal.bombardier@...,
nail-devel@...                   
                      >                        cc :                                                                                    
                                               Objet :  Re: [nail-devel] Bug when sending PDF attachment                               
                      18/11/2005 15:52                                                                                                 

pascal.bombardier@... wrote:

> I use nail to send PDF files as attachment.
> In case of the joined PDF file, it gets corrupt, and I noticed that LF
> where changed to CRLF inside the PDF file.
> Try to send this file with nail and it gets corrupt.
> (See attached file: 109.pdf)

If I send _and_ receive/decode the file with nail, the result is
(Continue reading)

Permalink | Reply | 501 comments |
headers
Gunnar Ritter | 18 Nov 2005 16:30
Picon
Favicon

Re: Réf. : Re: [nail-devel] Bug when sending PDF attachment

pascal.bombardier@... wrote:

> I send the pdf file from a unix server to a lotus server (don't know if it
> is unix or windows), and then I read my mail with Lotus Notes from a
> windows PC.
> Somewhere in the process the LF inside the PDF are converted to CRLF, which
> corrupts the file.

The software you use is widely known for its ignorance regarding
Internet standards.

Throw it away.

If your employer insists on keeping it, calculate the money you
wasted in pursuing this issue for them.

	Gunnar

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
Permalink | Reply | 502 comments |
headers
phutchis | 18 Nov 2005 22:21
Favicon

Broken MUA's (Re: Bug when sending PDF attachment)

> > I send the pdf file from a unix server to a lotus server (don't
> > know if it is unix or windows), and then I read my mail with
> > Lotus Notes from a windows PC.
> > Somewhere in the process the LF inside the PDF are converted to
> > CRLF, which corrupts the file.
>
> The software you use is widely known for its ignorance regarding
> Internet standards.

I've never used Lotus anything, but it's interesting -- and a bit
disconcerting -- to hear that something so well-known, and not
from Redmond, is broken.  Is it even worse than Exchange/Outlook?

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
Permalink | Reply | 1 comment |

Gmane