I am trying to automate sending an access file to users on a monthly basis
with the following code.

          aRecipient:={xxx@xxx.com}
         cFileName:=aPaths[1]+"\temp\inventory.mdb"
                  FOR X=1 TO LEN(aRecipient)
                     oMail:=MIMEMessage():New()
                     oMail:setFrom     ( MailAddress():New(xxx@xxx.com) )
                     oMail:setSubject  ( "Monthly Inventory Report" )
                     oMail:setMessage  ( "Attached is the Monthly Inventory
Report auto-generated." )
                     oMail:setContentTransferEncoding("base64")
                     oMail:setContentType("application/msaccess")
                     oMail:AttachFile  (cFileName)
                     oMail:addRecipient( MailAddress():New(aRecipient[X]) )
                     SMTPSEND(oMail,"x.x.x.x")
                     oMail:=NIL
                  NEXT

The message is received but the attachment is corrupt.  The file created on
the webserver is fine.  It appears I have something wrong with the encoding.

Any suggestions?

Erik

Erik,

>cFileName := aPaths[1]+"\temp\inventory.mdb"

>oMail:setContentTransferEncoding("base64")
>oMail:setContentType("application/msaccess")
>oMail:AttachFile(cFileName)
>oMail:addRecipient(MailAddress():New(aRecipient[X]))

>The message is received but the attachment is corrupt. The file created on
>the webserver is fine. It appears I have something wrong with the encoding.

>Any suggestions?

Several, but they probably won't do you much good, I'm afraid.

First, add attachments at the very last moment before sending the email, 
which means, add the Recipient before the Attachment in your code:

>oMail:AddRecipient(MailAddress():New(aRecipient[X]))
>oMail:AttachFile(cFileName)

Otherwise, the headers might get corrupted.

Second, using the following two lines in your code does not have any effect 
on the Attachments that are sent:

>oMail:SetContentTransferEncoding("base64")
>oMail:SetContentType("application/msaccess")

ASINET decides by itself, based on the file's extension, what Content Type
and what Content Transfer Encoding it uses for any file that you attach.
For any unknown file extension, it will by default use the following:
"application/octet-stream" for Content Type and "quoted-printable" for the
Content Transfer Encoding.

And because both, the "quoted-printable" encoding as well as the decoding
are broken in ASINET, any binary attachments with "unknown" extensions --
like Access files with extension ".MDB" -- will be corrupted!

The only real workaround is to change the extension to one that is known by 
ASINET and for which ASINET uses "base64" encoding. One way to do this is 
to create a zip file that contains your Access database, and email that Zip 
file. But this requires you to be able to Zip and UnZip the files before 
sending and after receiving the files. I recommend Phil's ZLib wrapper for
this, but if the receiver can't handle the files in zipped form, this might 
not be viable. Another option would be to simply change the extension to 
something like ".JPG", which will be emailed correctly (base64-encoded), and 
then change it back when saving the attachment on the receiver side. But 
this also might not be feasible.

ASTAG refused to give a PDR for any of those issues -- that's probably why
they are gone now.  Maybe ARD or ASIG will issue a PDR or even fix it,
but I wouldn't hold my breath.

You could also use See4XB from Marshall Software or you could write your own 
SMTP EMail procedures, using the ASINET socket functions.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

You are right Andreas,

This is a known issue and we need a definition and solution how to 
manipulate encodings for "userdefined attachment extensions". We have 
allready invested in the issue and have prepared the asinet source code 
for the interfaces required.

For the time being the solution is to attach a zip file.

I will forward this subject to support for further validation. Thus 
priority will be pushed a little and you will have feed back on this 
newsgroup soon.

Just for notification:
We have allready fixed the base64 encoding bug. The algorythm failed for 
small strings. The fix will be available with next release.

We are not aware of a bug with our "quoted printable" routines and would 
be very glad about a tiny sample demonstrating the problem.

Andreas Herdt

Alaska Research & Development

Andreas Gehrs-Pahl wrote:


> Erik,
> 
> 
>>cFileName := aPaths[1]+"\temp\inventory.mdb"
> 
> 
>>oMail:setContentTransferEncoding("base64")
>>oMail:setContentType("application/msaccess")
>>oMail:AttachFile(cFileName)
>>oMail:addRecipient(MailAddress():New(aRecipient[X]))
> 
> 
>>The message is received but the attachment is corrupt. The file created on
>>the webserver is fine. It appears I have something wrong with the encoding.
> 
> 
>>Any suggestions?
> 
> 
> Several, but they probably won't do you much good, I'm afraid.
> 
> First, add attachments at the very last moment before sending the email, 
> which means, add the Recipient before the Attachment in your code:
> 
> 
>>oMail:AddRecipient(MailAddress():New(aRecipient[X]))
>>oMail:AttachFile(cFileName)
> 
> 
> Otherwise, the headers might get corrupted.
> 
> Second, using the following two lines in your code does not have any effect 
> on the Attachments that are sent:
> 
> 
>>oMail:SetContentTransferEncoding("base64")
>>oMail:SetContentType("application/msaccess")
> 
> 
> ASINET decides by itself, based on the file's extension, what Content Type
> and what Content Transfer Encoding it uses for any file that you attach.
> For any unknown file extension, it will by default use the following:
> "application/octet-stream" for Content Type and "quoted-printable" for the
> Content Transfer Encoding.
> 
> And because both, the "quoted-printable" encoding as well as the decoding
> are broken in ASINET, any binary attachments with "unknown" extensions --
> like Access files with extension ".MDB" -- will be corrupted!
> 
> The only real workaround is to change the extension to one that is known by 
> ASINET and for which ASINET uses "base64" encoding. One way to do this is 
> to create a zip file that contains your Access database, and email that Zip 
> file. But this requires you to be able to Zip and UnZip the files before 
> sending and after receiving the files. I recommend Phil's ZLib wrapper for
> this, but if the receiver can't handle the files in zipped form, this might 
> not be viable. Another option would be to simply change the extension to 
> something like ".JPG", which will be emailed correctly (base64-encoded), and 
> then change it back when saving the attachment on the receiver side. But 
> this also might not be feasible.
> 
> ASTAG refused to give a PDR for any of those issues -- that's probably why
> they are gone now.  Maybe ARD or ASIG will issue a PDR or even fix it,
> but I wouldn't hold my breath.
> 
> You could also use See4XB from Marshall Software or you could write your own 
> SMTP EMail procedures, using the ASINET socket functions.
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Regards
   Andreas Herdt
   [Alaska Research & Development]

Andreas,

> This is a known issue and we need a definition and solution how to 
> manipulate encodings for "userdefined attachment extensions". We have 
> allready invested in the issue and have prepared the asinet source code 
> for the interfaces required.

application/octet-stream with base64 encoding is a generic way of saying "I
haven't a clue what this is, you deal with it". (as oppposed to e.g.
application/pdf which says "use a pdf viewer").

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

WindowError 020: Keyboard locked. Try anything you can think of!

Andreas,

>Just for notification:
>We have allready fixed the base64 encoding bug. The algorythm failed for 
>small strings. The fix will be available with next release.

This was probably PDR 5306. Interestingly, I never had any problems with 
that, for some reason -- all base64 encoding in ASINET worked fine for me.

>We are not aware of a bug with our "quoted printable" routines and would 
>be very glad about a tiny sample demonstrating the problem.

I had two email exchanges  with Gogo about the SMTP Client and related 
implementations and problems in ASINET; the first one between October 13
and October 22, 2003, and the second one between November 18 and 20, 2003.

During those conversations, PDRs 5312, 5313, and 5315 were created, and I
even got a PFL for PDR 5313, which works excellent, BTW! But the problems 
with quoted-printable encoding were never resolved and no PDR was ever 
created.

Here is a slightly streamlined copy of my error description from November 
18, 2003, once again:

ASINET is incorrect in two places, when doing quoted-printable encoding:

a) CR and LF of the original file are not converted/encoded correctly in
   all cases. The current behavior is as follows:

* CR by itself becomes "=0D", which is ok.

* CRLF stays CRLF, which only works for ASCII (not binary files), which is
  what 'quoted-printable' was actually designed for, but ASINET encodes also
  binary files, and if converted back, CRLF will become a "New Line 
  Character (combination)", which depends on the converting system, and is 
  not always "CRLF", UNIX/LINUX uses only LF, Mac OS uses only CR, etc.

* LF by itself becomes CRLF -- that means chr(13) + chr(10). This creates
  problems when converting it back, even with ASINET's own "FromQP()" 
  function!

* LFCR becomes chr(13) + chr(10) + "=0D", adding an additional CR in front
  of the LFCR after converting it back, even with ASINET's own "FromQP()" 
  function!

The LF conversion seems to be an attempt to convert Unix/Linux "New Line
Characters" to Dos/Windows "New Line Characters". This is of course a bad
idea for binary files! This needs to be fixed -- just don't do it!

b) If there is a White Space character (chr(32) or chr(9)) at the very end
   of a line (of the original file), it MUST be converted to "=20" or "=09",
   and can not simply be indicated by adding a "=" to the (converted) line,
   as ASINET is doing it! Otherwise those lines are truncated! ASINET 
   actually behaves differently for a) attachments that it creates, and b) 
   when using the ASINET function "ToQP()" directly -- both incorrect! -- as 
   follows:

* Using "ToQP()", the converted string has an "=" + CR + LF attached to it,
  instead of converting the last white space character of each "source" line
  into a "=20" or "=09". When converting those lines back, this results in
  endlessly long lines without any "New Line Character", as "=" by itself at
  the end of a line (meaning "=" + CR + LF) is considered a "Soft Return",
  and the decoding program will simply remove those three characters! Of
  course, ASINET's "FromQP()" cheats, and does not follow the RFC rules,
  either, probably to be compatible with "ToQP()".

* Attaching a file that is 'quoted-printable' encoded by ASINET will 
  actually NOT have any "=" character (only CR + LF) following any trailing 
  spaces (I did not explicitly test for Tab characters, though). This 
  results in those white space characters being truncated completely by the 
  decoding program (as it should, and as it is described in RFC 2045). If 
  there is no other (non-white-space) character in that converted line, and 
  the previous line ends with a "Soft Return" ("=" + CR + LF), the following 
  line is simply added to the end of the previous line, which in effect 
  combines those lines after removing all Spaces, Tabs and even valid 
  New-Line Characters between them.

Both of those behaviors corrupt and truncate binary files, and remove valid 
white space characters from the end of all lines of ASCII text files.

I hope I explained those problems detailed enough that you can reproduce,
acknowledge and (hopefully) fix them.

Like base64 encoding, quoted-printable encoding should allow the encoding of 
any kind of data/file and the decoding of the created data should result in 
an exact copy -- a binary-identical copy -- of the original file under 
normal circumstances. In addition, if an ASCII-text file is encoded, the 
quoted-printable method allows for the conversion of New-Line characters to 
OS-specific New-Line characters -- similar to the ASCII transfer setting in 
the FTP protocol. This option should not be used by ASINET (at least not by 
default), as binary files might have to be encoded, and the programmer does 
not have any influence over this feature (at this time).

Thanks,

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

Thank you for your detailed report. Your observations seem to be right.
I have to verify them and I am about for preparing a pdr on the subject. 
I will post into the newsgroup as soon it is available.

Regards
   Andreas Herdt
   [Alaska Research & Development]


Andreas Gehrs-Pahl wrote:

> Andreas,
> 
> 
>>Just for notification:
>>We have allready fixed the base64 encoding bug. The algorythm failed for 
>>small strings. The fix will be available with next release.
> 
> 
> This was probably PDR 5306. Interestingly, I never had any problems with 
> that, for some reason -- all base64 encoding in ASINET worked fine for me.
> 
> 
>>We are not aware of a bug with our "quoted printable" routines and would 
>>be very glad about a tiny sample demonstrating the problem.
> 
> 
> I had two email exchanges  with Gogo about the SMTP Client and related 
> implementations and problems in ASINET; the first one between October 13
> and October 22, 2003, and the second one between November 18 and 20, 2003.
> 
> During those conversations, PDRs 5312, 5313, and 5315 were created, and I
> even got a PFL for PDR 5313, which works excellent, BTW! But the problems 
> with quoted-printable encoding were never resolved and no PDR was ever 
> created.
> 
> Here is a slightly streamlined copy of my error description from November 
> 18, 2003, once again:
> 
> ASINET is incorrect in two places, when doing quoted-printable encoding:
> 
> a) CR and LF of the original file are not converted/encoded correctly in
>    all cases. The current behavior is as follows:
> 
> * CR by itself becomes "=0D", which is ok.
> 
> * CRLF stays CRLF, which only works for ASCII (not binary files), which is
>   what 'quoted-printable' was actually designed for, but ASINET encodes also
>   binary files, and if converted back, CRLF will become a "New Line 
>   Character (combination)", which depends on the converting system, and is 
>   not always "CRLF", UNIX/LINUX uses only LF, Mac OS uses only CR, etc.
> 
> * LF by itself becomes CRLF -- that means chr(13) + chr(10). This creates
>   problems when converting it back, even with ASINET's own "FromQP()" 
>   function!
> 
> * LFCR becomes chr(13) + chr(10) + "=0D", adding an additional CR in front
>   of the LFCR after converting it back, even with ASINET's own "FromQP()" 
>   function!
> 
> The LF conversion seems to be an attempt to convert Unix/Linux "New Line
> Characters" to Dos/Windows "New Line Characters". This is of course a bad
> idea for binary files! This needs to be fixed -- just don't do it!
> 
> b) If there is a White Space character (chr(32) or chr(9)) at the very end
>    of a line (of the original file), it MUST be converted to "=20" or "=09",
>    and can not simply be indicated by adding a "=" to the (converted) line,
>    as ASINET is doing it! Otherwise those lines are truncated! ASINET 
>    actually behaves differently for a) attachments that it creates, and b) 
>    when using the ASINET function "ToQP()" directly -- both incorrect! -- as 
>    follows:
> 
> * Using "ToQP()", the converted string has an "=" + CR + LF attached to it,
>   instead of converting the last white space character of each "source" line
>   into a "=20" or "=09". When converting those lines back, this results in
>   endlessly long lines without any "New Line Character", as "=" by itself at
>   the end of a line (meaning "=" + CR + LF) is considered a "Soft Return",
>   and the decoding program will simply remove those three characters! Of
>   course, ASINET's "FromQP()" cheats, and does not follow the RFC rules,
>   either, probably to be compatible with "ToQP()".
> 
> * Attaching a file that is 'quoted-printable' encoded by ASINET will 
>   actually NOT have any "=" character (only CR + LF) following any trailing 
>   spaces (I did not explicitly test for Tab characters, though). This 
>   results in those white space characters being truncated completely by the 
>   decoding program (as it should, and as it is described in RFC 2045). If 
>   there is no other (non-white-space) character in that converted line, and 
>   the previous line ends with a "Soft Return" ("=" + CR + LF), the following 
>   line is simply added to the end of the previous line, which in effect 
>   combines those lines after removing all Spaces, Tabs and even valid 
>   New-Line Characters between them.
> 
> Both of those behaviors corrupt and truncate binary files, and remove valid 
> white space characters from the end of all lines of ASCII text files.
> 
> I hope I explained those problems detailed enough that you can reproduce,
> acknowledge and (hopefully) fix them.
> 
> Like base64 encoding, quoted-printable encoding should allow the encoding of 
> any kind of data/file and the decoding of the created data should result in 
> an exact copy -- a binary-identical copy -- of the original file under 
> normal circumstances. In addition, if an ASCII-text file is encoded, the 
> quoted-printable method allows for the conversion of New-Line characters to 
> OS-specific New-Line characters -- similar to the ASCII transfer setting in 
> the FTP protocol. This option should not be used by ASINET (at least not by 
> default), as binary files might have to be encoded, and the programmer does 
> not have any influence over this feature (at this time).
> 
> Thanks,
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Andreas,

>Thank you for your detailed report. Your observations seem to be right.
>I have to verify them and I am about for preparing a pdr on the subject. 
>I will post into the newsgroup as soon it is available.

Thank you!

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

You wrote on 03/23/2004 (over two weeks ago):

>Thank you for your detailed report. Your observations seem to be right.
>I have to verify them and I am about for preparing a pdr on the subject. 
>I will post into the newsgroup as soon it is available.

I haven't heard anything (from Alaska about this issue) since then, and 
after the Full-Text-Search of the KB worked (for a while), I didn't find 
anything new about ASINET or SMTP there either. BTW, I just checked the 
Full-Text-Search again, and it is not finding anything anymore, even though 
it worked a couple of days ago, at least for a while.

I would appreciate a follow-up. It seems that really vague and obscure 
errors get PDRs right away, while errors that are well-documented, and 
in-detail explained -- just shy of having instructions on how to fix the 
problem -- get ignored for months (or for ever).

While I am at it, when (if at all) can we expect an SMTP authorization 
option for the ASINet SMTP class? More and more IPs (Internet Providers) 
require authentication for SMTP now, and SMTP over POP3 does not seem to 
work in many cases. I won't asked for any FTP enhancements anymore, as there
are now a lot better (than ASINet's implementation) and even free options 
available for FTP, but I would really like to use ASINet for something.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

The truth is -> I was not fast enough here (the thread really was marked 
blue on my newsreader all the time (don't ask "Why blue?" )).
However, I was not lazy 

Ok, here is the update:
You are right, the function ToQP() does not work correct. The truth is
I was not able to produce a PDR since I did not know what to write since 
it was not clear to me what is correct. This kind of encoding was never 
ment to encode binaries, thus you can not expect that every single byte 
will be sent to receiver unchanged. (RFC1521 leaves space for 
interpretation here).
This fact on the other hand influences how MimeMessage should encode 
attachments (However this is a different story and will be solved at a 
different place).

In the meantime I have started to reimplement the encoding algorythm and 
hoped to post it (the fix) to this newsgroup today so you can try it out 
over eastern, however, I am not finished yet.

I decided to do the following:
Encode all CRLF everytime. This way we get rid of the trailing white
space problem (there are only trailing whitespaces possible at the end 
of file) and no decoder will come to the idea that CRLF will be 
transformed to LF (this is explicitely allowed according RFC).

CR/LF/ and some other chars will be encoded always as proposed by
RFC1521:
chr(33-36), chr(64), chr(91-94), chr(96) and chr(123-126)

My goal is to make the encoding as robust as possible in respect of 
transportation safety. The drawback will be that the encoded text will 
no longer be as readable as possible (the initial purpose of this 
encoding algorythm).

The reason why I was in such a hurry and have not created a PDR was also 
  due to the fact that we are currently prepering a PFL, and I was 
focusing on solving the problem and not in documenting the current 
problem. Thus, we had the chance that the issue is PDRed AND Fixed with
the PFL. (Information on what will be fixed by next PFL will follow next 
week).

Smtp Auth:
Will be available with next release for shure.

Andreas Herdt
   [Alaska Research & Development]



Andreas Gehrs-Pahl wrote:

> Andreas,
> 
> You wrote on 03/23/2004 (over two weeks ago):
> 
> 
>>Thank you for your detailed report. Your observations seem to be right.
>>I have to verify them and I am about for preparing a pdr on the subject. 
>>I will post into the newsgroup as soon it is available.
> 
> 
> I haven't heard anything (from Alaska about this issue) since then, and 
> after the Full-Text-Search of the KB worked (for a while), I didn't find 
> anything new about ASINET or SMTP there either. BTW, I just checked the 
> Full-Text-Search again, and it is not finding anything anymore, even though 
> it worked a couple of days ago, at least for a while.
> 
> I would appreciate a follow-up. It seems that really vague and obscure 
> errors get PDRs right away, while errors that are well-documented, and 
> in-detail explained -- just shy of having instructions on how to fix the 
> problem -- get ignored for months (or for ever).
> 
> While I am at it, when (if at all) can we expect an SMTP authorization 
> option for the ASINet SMTP class? More and more IPs (Internet Providers) 
> require authentication for SMTP now, and SMTP over POP3 does not seem to 
> work in many cases. I won't asked for any FTP enhancements anymore, as there
> are now a lot better (than ASINet's implementation) and even free options 
> available for FTP, but I would really like to use ASINet for something.
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Regards
   Andreas Herdt
   [Alaska Research & Development]

Andreas,

>Ok, here is the update:
>You are right, the function ToQP() does not work correct. The truth is
>I was not able to produce a PDR since I did not know what to write since 
>it was not clear to me what is correct. This kind of encoding was never 
>ment to encode binaries, thus you can not expect that every single byte 
>will be sent to receiver unchanged. (RFC1521 leaves space for 
>interpretation here).

I agree that the quoted-printable encoding was not meant to encode binaries 
per-se, but you should (and have to) expect that every single byte COULD be 
encoded, so that it will be decoded by the receiver to create an identical 
file. And Xbase++ MUST do it that way, unless the user/programmer has an 
option to enable or disable that feature -- or select a different encoding 
type altogether.

>This fact on the other hand influences how MimeMessage should encode 
>attachments (However this is a different story and will be solved at a 
>different place).

I was trying to tell you (actually originally Frank++ and then Gogo) the 
same thing for quite a while. Using base64 as the default (instead of 
quoted-printable) would make much more sense. 

>In the meantime I have started to reimplement the encoding algorythm and 
>hoped to post it (the fix) to this newsgroup today so you can try it out 
>over eastern, however, I am not finished yet.

That's okay, take your time. A few days more or less won't make any 
difference, really.

>I decided to do the following:
>Encode all CRLF everytime. This way we get rid of the trailing white
>space problem (there are only trailing whitespaces possible at the end 
>of file) and no decoder will come to the idea that CRLF will be 
>transformed to LF (this is explicitely allowed according RFC).

I am not quite sure what the above paragraph means. The "trailing white 
space problem" is somewhat unrelated to the CR and LF encoding problem. 
Those are two different issues. Please re-read my post and the RFC, and then 
try to encode a test file with lots of (trailing) spaces (between 20 and 200 
per line) using ASINet. Also make sure to try both, the function "ToQP()" 
directly, as well as the MimeMessage:AttachFile() method. 

The encoded text will be incorrect If you decode this with a working 
decoder, you will notice that either the trailing spaces are missing (when 
using the ":AttachFile()" method) or the lines are endlessly strung together 
(when using "ToQP()" directly). The problem is somewhat obscured if you use 
the ASINet function "FromQP()", because that function compensates for some 
of the problems.

The simple fact that the behavior/result differs between the function and 
the method, indicates that they don't use the same code. So please make sure 
that both copies are fixed!

>CR/LF/ and some other chars will be encoded always as proposed by
>RFC1521:
>chr(33-36), chr(64), chr(91-94), chr(96) and chr(123-126)

Good! This is basically a requirement for the (successful) encoding and 
decoding of binary files, when using quoted-printable encoding. But don't 
forget the other issues related to white spaces, chr(9) and chr(32), at the 
end of (encoded) lines! Of course, all those other non-printable and 
non-ASCII characters, chr(0) through chr(31) and chr(127) through chr(255), 
must be encoded, too, but I assume those were already covered. You might 
want to check RFC 2045, though, as it seems to supersede RFC 1521 (even 
though the quoted-printable part seems mostly identical to me).

>My goal is to make the encoding as robust as possible in respect of 
>transportation safety. The drawback will be that the encoded text will 
>no longer be as readable as possible (the initial purpose of this 
>encoding algorythm).

I don't think that matters to anyone who wants to send an Excel, DBF, or SDF 
file as an attachment using ASINet -- trust me on this. 

If it is not a big deal/major problem, you could make this a configuration 
option, which would allow the programmer to decide if the encoding has to 
deal with a binary or text file. But for this to work, you also MUST fix the 
"trailing white space" problems!

>The reason why I was in such a hurry and have not created a PDR was also 
>due to the fact that we are currently prepering a PFL, and I was 
>focusing on solving the problem and not in documenting the current 
>problem. Thus, we had the chance that the issue is PDRed AND Fixed with
>the PFL. (Information on what will be fixed by next PFL will follow next 
>week).

Great! I am looking forward to this! Any chance that PDRs 5312, 5313, and 
5315 will be fixed, too?

>Smtp Auth:
>Will be available with next release for shure.

That is very good news! Thanks!

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas Gehrs-Pahl wrote:

> Andreas,
> 
> 
>>Ok, here is the update:
>>You are right, the function ToQP() does not work correct. The truth is
>>I was not able to produce a PDR since I did not know what to write since 
>>it was not clear to me what is correct. This kind of encoding was never 
>>ment to encode binaries, thus you can not expect that every single byte 
>>will be sent to receiver unchanged. (RFC1521 leaves space for 
>>interpretation here).
> 
> 
> I agree that the quoted-printable encoding was not meant to encode binaries 
> per-se, but you should (and have to) expect that every single byte COULD be 
> encoded, so that it will be decoded by the receiver to create an identical 
> file. And Xbase++ MUST

I have to disagree here,

> do it that way, unless the user/programmer has an 
> option to enable or disable that feature -- or select a different encoding 
> type altogether.

agreed.

> 
> 
>>This fact on the other hand influences how MimeMessage should encode 
>>attachments (However this is a different story and will be solved at a 
>>different place).
> 
> 
> I was trying to tell you (actually originally Frank++ and then Gogo) the 
> same thing for quite a while. Using base64 as the default (instead of 
> quoted-printable) would make much more sense. 
> 
> 
>>In the meantime I have started to reimplement the encoding algorythm and 
>>hoped to post it (the fix) to this newsgroup today so you can try it out 
>>over eastern, however, I am not finished yet.
> 
> 
> That's okay, take your time. A few days more or less won't make any 
> difference, really.
> 
> 
>>I decided to do the following:
>>Encode all CRLF everytime. This way we get rid of the trailing white
>>space problem (there are only trailing whitespaces possible at the end 
>>of file) and no decoder will come to the idea that CRLF will be 
>>transformed to LF (this is explicitely allowed according RFC).
> 
> 
> I am not quite sure what the above paragraph means. The "trailing white 
> space problem" is somewhat unrelated to the CR and LF encoding problem. 
> Those are two different issues. Please re-read my post and the RFC, and then 
> try to encode a test file with lots of (trailing) spaces (between 20 and 200 
> per line) using ASINet.

You want the file decoded as it was, this means that CRLF combinations 
must be encoded, otherwise there is no guarantee the decoder will emit 
CRLF. If CRLF is encoded then whitespaces can no longer be at end of 
line since last encoded characters are CRLF (exception from the rule: 
the last line, since this one need not be ended by CRLF).

> Also make sure to try both, the function "ToQP()" 
> directly, as well as the MimeMessage:AttachFile() method. 

of course.

> The encoded text will be incorrect If you decode this with a working 
> decoder, you will notice that either the trailing spaces are missing (when 
> using the ":AttachFile()" method) or the lines are endlessly strung together 
> (when using "ToQP()" directly). The problem is somewhat obscured if you use 
> the ASINet function "FromQP()", because that function compensates for some 
> of the problems.
> 
> The simple fact that the behavior/result differs between the function and 
> the method, indicates that they don't use the same code. So please make sure 
> that both copies are fixed!

They do definetly. I have to investigate in this.

>>CR/LF/ and some other chars will be encoded always as proposed by
>>RFC1521:
>>chr(33-36), chr(64), chr(91-94), chr(96) and chr(123-126)
> 
> 
> Good! This is basically a requirement for the (successful) encoding and 
> decoding of binary files, when using quoted-printable encoding. But don't 
> forget the other issues related to white spaces, chr(9) and chr(32), at the 
> end of (encoded) lines! Of course, all those other non-printable and 
> non-ASCII characters, chr(0) through chr(31) and chr(127) through chr(255), 
> must be encoded, too, but I assume those were already covered. You might 
> want to check RFC 2045, though, as it seems to supersede RFC 1521 (even 
> though the quoted-printable part seems mostly identical to me).
> 
> 
>>My goal is to make the encoding as robust as possible in respect of 
>>transportation safety. The drawback will be that the encoded text will 
>>no longer be as readable as possible (the initial purpose of this 
>>encoding algorythm).
> 
> 
> I don't think that matters to anyone who wants to send an Excel, DBF, or SDF 
> file as an attachment using ASINet -- trust me on this. 
> 
> If it is not a big deal/major problem, you could make this a configuration 
> option, which would allow the programmer to decide if the encoding has to 
> deal with a binary or text file. But for this to work, you also MUST fix the 
> "trailing white space" problems!
> 
> 
>>The reason why I was in such a hurry and have not created a PDR was also 
>>due to the fact that we are currently prepering a PFL, and I was 
>>focusing on solving the problem and not in documenting the current 
>>problem. Thus, we had the chance that the issue is PDRed AND Fixed with
>>the PFL. (Information on what will be fixed by next PFL will follow next 
>>week).
> 
> 
> Great! I am looking forward to this! Any chance that PDRs 5312, 5313, and 
> 5315 will be fixed, too?
> 
> 
>>Smtp Auth:
>>Will be available with next release for shure.
> 
> 
> That is very good news! Thanks!
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Regards
   Andreas Herdt
   [Alaska Research & Development]

> The reason why I was in such a hurry and have not created a PDR was also
>   due to the fact that we are currently prepering a PFL, and I was
> focusing on solving the problem and not in documenting the current
> problem. Thus, we had the chance that the issue is PDRed AND Fixed with
> the PFL. (Information on what will be fixed by next PFL will follow next
> week).
PFL for 1.9 or 1.82 ?

>
> Smtp Auth:
> Will be available with next release for shure.
That sounds nice. Thanks.

Anand

Anand Gupta wrote:

>>The reason why I was in such a hurry and have not created a PDR was also
>>  due to the fact that we are currently prepering a PFL, and I was
>>focusing on solving the problem and not in documenting the current
>>problem. Thus, we had the chance that the issue is PDRed AND Fixed with
>>the PFL. (Information on what will be fixed by next PFL will follow next
>>week).
> 
> PFL for 1.9 or 1.82 ?

1.82

>>Smtp Auth:
>>Will be available with next release for shure.
> 
> That sounds nice. Thanks.
> 
> Anand
> 
> 

Regards
   Andreas Herdt
   [Alaska Research & Development]