From: Bob B. Jr. <bl...@da...> - 2011-09-28 14:54:12
|
Trying to send attachments using the mail modules send-email() function, and have run across a very interesting bug. Normal base64 encoders utilize fixed width output, but send-email is producing variable width base64 with extraneous spaces after each newline. Some client-side decoders handle this fine, eg. Evolution on linux, attachments open fine. But the very same email (from the same IMAP server) viewed from Android/Profimail and/or Windows/Outlook, indicate that the attachment is corrupt, and cannot be opened. Below is a small snippet from the email source which shows the space on the second line (both lines truncated for brevity). --eXist.multipart.1.4.1 Content-Type: application/pdf; name="switchlist.pdf" Content-Transfer-Encoding: base64 Content-Description: switchlist.pdf Content-Disposition: attachment; filname="switchlist.pdf" JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! QvGRwP5zYvRmZi ... I have tried both methods of sending (sendmail and SMTP), and have tried different MTAs (Postfix and Sendmail), but the result is always the same. -Bob |
From: Bob B. Jr. <bl...@da...> - 2011-10-04 13:01:27
|
*Re-post - email to list was delayed and back-dated* Trying to send attachments using the mail modules send-email() function, and have run across a very interesting bug. Normal base64 encoders utilize fixed width output, but send-email() is producing variable width base64 with extraneous spaces after each newline. Some client-side decoders handle this fine, eg. Evolution on linux, attachments open fine. But the very same email (from the same IMAP server) viewed from Android/Profimail and/or Windows/Outlook, indicate that the attachment is corrupt, and cannot be opened. Below is a small snippet from the email source which shows the space on the second line (both lines truncated for brevity). --eXist.multipart.1.4.1 Content-Type: application/pdf; name="switchlist.pdf" Content-Transfer-Encoding: base64 Content-Description: switchlist.pdf Content-Disposition: attachment; filname="switchlist.pdf" JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! QvGRwP5zYvRmZi ... I have tried both methods of sending (sendmail and SMTP), and have tried different MTAs (Postfix and Sendmail), but the result is always the same. -Bob |
From: Adam R. <ad...@ex...> - 2011-10-04 21:10:36
|
Bob, Whatever format the xs:base64binary data arrives to the mail function, should be exactly what is written back out into the SMTP or Sendmail payload. So as part of the <mail> that you are passing into the function, you must have something like this - <attachment filename="switchlist.pdf" mimetype="application/pdf">{$pdf-data}</attachment> Can you double check what the form of the text child node of the attachment element that you are using is? It may be that the spacing you see exists there already? Where is that base64 data really coming from? It may also be that I have a bug in the send-email(...) function code, but I would like you to check the above first, if we can rule that out, then you should be able to provide me with your <mail> and I should be able to reproduce this here... On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> wrote: > *Re-post - email to list was delayed and back-dated* > > Trying to send attachments using the mail modules send-email() function, > and have run across a very interesting bug. > > Normal base64 encoders utilize fixed width output, but send-email() is > producing variable width base64 with extraneous spaces after each > newline. > > Some client-side decoders handle this fine, eg. Evolution on linux, > attachments open fine. But the very same email (from the same IMAP > server) viewed from Android/Profimail and/or Windows/Outlook, indicate > that the attachment is corrupt, and cannot be opened. > > Below is a small snippet from the email source which shows the space on > the second line (both lines truncated for brevity). > > --eXist.multipart.1.4.1 > Content-Type: application/pdf; name="switchlist.pdf" > Content-Transfer-Encoding: base64 > Content-Description: switchlist.pdf > Content-Disposition: attachment; filname="switchlist.pdf" > > > JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! > QvGRwP5zYvRmZi ... > > > I have tried both methods of sending (sendmail and SMTP), and have tried > different MTAs (Postfix and Sendmail), but the result is always the > same. > > -Bob > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Bob B. Jr. <bl...@da...> - 2011-10-04 21:47:03
|
Hi Adam, In my particular case, I'm using xsl-fo to generate a pdf. xslfo:render() returns xs:base64binary (see code snippet below). In order to eliminate the possibility of the problem lying with xsl-fo, I took a different pdf from the file system, and sent it via send-email() and had the exact same issue. So regardless of the source of the binary file, when sending via send-email() it has these strange spaces in the base64 encoding. I could send to you off-list direct from send-email() if you wish to see the full email source result. Thanks, -Bob let $fo := local:generatepdf($doc) (: Setup the email and then send it :) let $email := <mail> <from>{concat(data($account), '@dainty.ca')}</from> <to>{data($content/emails/switchlist/@to)}</to>{ for $cc in tokenize($content/emails/switchlist/@cc, ', ') return <cc>{data($cc)}</cc> }<bcc/> <subject>{ concat('Switch List for ', data($date), if (data($doc/sent/@revision) = ('', '0')) then '' else concat(' (Revision #', data($doc/sent/@revision), ')')) }</subject> <message> <text>See attachment for Switch List.</text> <xhtml>{ util:parse-html($content/emails/switchlist) }</xhtml> </message> <attachment filename="switchlist.png" mimetype="image/png">{ xslfo:render($fo, "image/png", ()) }</attachment> <attachment filename="switchlist.pdf" mimetype="application/pdf">{ xslfo:render($fo, "application/pdf", ()) }</attachment> </mail> let $send := mail:send-email($email, "" , ()) On Tue, 2011-10-04 at 21:10 +0000, Adam Retter wrote: > Bob, > > > Whatever format the xs:base64binary data arrives to the mail function, > should be exactly what is written back out into the SMTP or Sendmail > payload. > > > So as part of the <mail> that you are passing into the function, you > must have something like this - > > > <attachment filename="switchlist.pdf" > mimetype="application/pdf">{$pdf-data}</attachment> > > > Can you double check what the form of the text child node of the > attachment element that you are using is? It may be that the spacing > you see exists there already? Where is that base64 data really coming > from? > > > It may also be that I have a bug in the send-email(...) function code, > but I would like you to check the above first, if we can rule that > out, then you should be able to provide me with your <mail> and I > should be able to reproduce this here... > > > On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> wrote: > > *Re-post - email to list was delayed and back-dated* > > Trying to send attachments using the mail modules send-email() > function, > and have run across a very interesting bug. > > Normal base64 encoders utilize fixed width output, but > send-email() is > producing variable width base64 with extraneous spaces after > each > newline. > > Some client-side decoders handle this fine, eg. Evolution on > linux, > attachments open fine. But the very same email (from the same > IMAP > server) viewed from Android/Profimail and/or Windows/Outlook, > indicate > that the attachment is corrupt, and cannot be opened. > > Below is a small snippet from the email source which shows the > space on > the second line (both lines truncated for brevity). > > --eXist.multipart.1.4.1 > Content-Type: application/pdf; name="switchlist.pdf" > Content-Transfer-Encoding: base64 > Content-Description: switchlist.pdf > Content-Disposition: attachment; filname="switchlist.pdf" > > JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! > QvGRwP5zYvRmZi ... > > > I have tried both methods of sending (sendmail and SMTP), and > have tried > different MTAs (Postfix and Sendmail), but the result is > always the > same. > > -Bob > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a > definitive record of customers, application performance, > security > threats, fraudulent activity and more. Splunk takes this data > and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > |
From: Adam R. <ad...@ex...> - 2011-10-04 22:28:47
|
What happens if you call util:log("debug", ("MYFO=", xslfo:render($fo, "application/pdf"))) - you should then see the output in exist.log. Does that output contain these extra spaces? Cheers Adam. On 4 October 2011 21:46, Bob Blanchard Jr. <bl...@da...> wrote: > ** > Hi Adam, > > In my particular case, I'm using xsl-fo to generate a pdf. xslfo:render() > returns xs:base64binary (see code snippet below). > > In order to eliminate the possibility of the problem lying with xsl-fo, I > took a different pdf from the file system, and sent it via send-email() and > had the exact same issue. So regardless of the source of the binary file, > when sending via send-email() it has these strange spaces in the base64 > encoding. > > I could send to you off-list direct from send-email() if you wish to see > the full email source result. > > Thanks, > > -Bob > > let $fo := local:generatepdf($doc) > > (: Setup the email and then send it :) > let $email := > <mail> > <from>{concat(data($account), '@dainty.ca')}</from> > <to>{data($content/emails/switchlist/@to)}</to>{ > for $cc in tokenize($content/emails/switchlist/@cc, ', ') return > <cc>{data($cc)}</cc> > }<bcc/> > <subject>{ > concat('Switch List for ', data($date), > if (data($doc/sent/@revision) = ('', '0')) then '' else concat(' > (Revision #', data($doc/sent/@revision), ')')) > }</subject> > <message> > <text>See attachment for Switch List.</text> > <xhtml>{ > util:parse-html($content/emails/switchlist) > }</xhtml> > </message> > <attachment filename="switchlist.png" mimetype="image/png">{ > xslfo:render($fo, "image/png", ()) > }</attachment> > > <attachment filename="switchlist.pdf" mimetype="application/pdf">{ > xslfo:render($fo, "application/pdf", ()) > }</attachment> > </mail> > > let $send := mail:send-email($email, "" , ()) > > > > On Tue, 2011-10-04 at 21:10 +0000, Adam Retter wrote: > > Bob, > > > Whatever format the xs:base64binary data arrives to the mail function, > should be exactly what is written back out into the SMTP or Sendmail > payload. > > > So as part of the <mail> that you are passing into the function, you must > have something like this - > > > <attachment filename="switchlist.pdf" > mimetype="application/pdf">{$pdf-data}</attachment> > > > Can you double check what the form of the text child node of the attachment > element that you are using is? It may be that the spacing you see exists > there already? Where is that base64 data really coming from? > > > It may also be that I have a bug in the send-email(...) function code, but > I would like you to check the above first, if we can rule that out, then you > should be able to provide me with your <mail> and I should be able to > reproduce this here... > > > On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> wrote: > > *Re-post - email to list was delayed and back-dated* > > Trying to send attachments using the mail modules send-email() function, > and have run across a very interesting bug. > > Normal base64 encoders utilize fixed width output, but send-email() is > producing variable width base64 with extraneous spaces after each > newline. > > Some client-side decoders handle this fine, eg. Evolution on linux, > attachments open fine. But the very same email (from the same IMAP > server) viewed from Android/Profimail and/or Windows/Outlook, indicate > that the attachment is corrupt, and cannot be opened. > > Below is a small snippet from the email source which shows the space on > the second line (both lines truncated for brevity). > > --eXist.multipart.1.4.1 > Content-Type: application/pdf; name="switchlist.pdf" > Content-Transfer-Encoding: base64 > Content-Description: switchlist.pdf > Content-Disposition: attachment; filname="switchlist.pdf" > > > JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! > QvGRwP5zYvRmZi ... > > > I have tried both methods of sending (sendmail and SMTP), and have tried > different MTAs (Postfix and Sendmail), but the result is always the > same. > > -Bob > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Bob B. Jr. <bl...@da...> - 2011-10-05 16:23:48
|
The output does not contain any spaces. I can save the output direct from the logfile, and do a "base64 --decode" on it and it gives me a valid PDF file. -Bob On Tue, 2011-10-04 at 22:28 +0000, Adam Retter wrote: > What happens if you call util:log("debug", ("MYFO=", xslfo:render($fo, > "application/pdf"))) - you should then see the output in exist.log. > Does that output contain these extra spaces? > > > > Cheers Adam. > > > On 4 October 2011 21:46, Bob Blanchard Jr. <bl...@da...> wrote: > > Hi Adam, > > In my particular case, I'm using xsl-fo to generate a pdf. > xslfo:render() returns xs:base64binary (see code snippet > below). > > In order to eliminate the possibility of the problem lying > with xsl-fo, I took a different pdf from the file system, and > sent it via send-email() and had the exact same issue. So > regardless of the source of the binary file, when sending via > send-email() it has these strange spaces in the base64 > encoding. > > I could send to you off-list direct from send-email() if you > wish to see the full email source result. > > Thanks, > > -Bob > > let $fo := local:generatepdf($doc) > > (: Setup the email and then send it :) > let $email := > <mail> > <from>{concat(data($account), '@dainty.ca')}</from> > <to>{data($content/emails/switchlist/@to)}</to>{ > for $cc in tokenize($content/emails/switchlist/@cc, ', > ') return > <cc>{data($cc)}</cc> > }<bcc/> > <subject>{ > concat('Switch List for ', data($date), > if (data($doc/sent/@revision) = ('', '0')) then '' else > concat(' (Revision #', data($doc/sent/@revision), ')')) > }</subject> > <message> > <text>See attachment for Switch List.</text> > <xhtml>{ > util:parse-html($content/emails/switchlist) > }</xhtml> > </message> > <attachment filename="switchlist.png" > mimetype="image/png">{ > xslfo:render($fo, "image/png", ()) > }</attachment> > > > <attachment filename="switchlist.pdf" > mimetype="application/pdf">{ > > > xslfo:render($fo, "application/pdf", ()) > }</attachment> > </mail> > > let $send := mail:send-email($email, "" , ()) > > > > > > On Tue, 2011-10-04 at 21:10 +0000, Adam Retter wrote: > > > Bob, > > > > > > Whatever format the xs:base64binary data arrives to the mail > > function, should be exactly what is written back out into > > the SMTP or Sendmail payload. > > > > > > So as part of the <mail> that you are passing into the > > function, you must have something like this - > > > > > > <attachment filename="switchlist.pdf" > > mimetype="application/pdf">{$pdf-data}</attachment> > > > > > > Can you double check what the form of the text child node of > > the attachment element that you are using is? It may be that > > the spacing you see exists there already? Where is that > > base64 data really coming from? > > > > > > It may also be that I have a bug in the send-email(...) > > function code, but I would like you to check the above > > first, if we can rule that out, then you should be able to > > provide me with your <mail> and I should be able to > > reproduce this here... > > > > > > On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> > > wrote: > > > > *Re-post - email to list was delayed and back-dated* > > > > Trying to send attachments using the mail modules > > send-email() function, > > and have run across a very interesting bug. > > > > Normal base64 encoders utilize fixed width output, > > but send-email() is > > producing variable width base64 with extraneous > > spaces after each > > newline. > > > > Some client-side decoders handle this fine, eg. > > Evolution on linux, > > attachments open fine. But the very same email > > (from the same IMAP > > server) viewed from Android/Profimail and/or > > Windows/Outlook, indicate > > that the attachment is corrupt, and cannot be > > opened. > > > > Below is a small snippet from the email source which > > shows the space on > > the second line (both lines truncated for brevity). > > > > --eXist.multipart.1.4.1 > > Content-Type: application/pdf; name="switchlist.pdf" > > Content-Transfer-Encoding: base64 > > Content-Description: switchlist.pdf > > Content-Disposition: attachment; > > filname="switchlist.pdf" > > > > JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! > > QvGRwP5zYvRmZi ... > > > > > > I have tried both methods of sending (sendmail and > > SMTP), and have tried > > different MTAs (Postfix and Sendmail), but the > > result is always the > > same. > > > > -Bob > > > > > > ------------------------------------------------------------------------------ > > All the data continuously generated in your IT > > infrastructure contains a > > definitive record of customers, application > > performance, security > > threats, fraudulent activity and more. Splunk takes > > this data and makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2dcopy1 > > _______________________________________________ > > Exist-open mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > > > > > > > -- > > Adam Retter > > > > eXist Developer > > { United Kingdom } > > ad...@ex... > > irc://irc.freenode.net/existdb > > > > > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > |
From: Adam R. <ad...@ex...> - 2011-10-05 17:06:35
|
Bob, Can you send me the email from send-email() (off-list), and also provide me with the absolute minimum that I need to reproduce the issue? Cheers Adam. On 5 October 2011 16:23, Bob Blanchard Jr. <bl...@da...> wrote: > ** > The output does not contain any spaces. I can save the output direct from > the logfile, and do a "base64 --decode" on it and it gives me a valid PDF > file. > > -Bob > > > On Tue, 2011-10-04 at 22:28 +0000, Adam Retter wrote: > > What happens if you call util:log("debug", ("MYFO=", xslfo:render($fo, > "application/pdf"))) - you should then see the output in exist.log. Does > that output contain these extra spaces? > > > > Cheers Adam. > > On 4 October 2011 21:46, Bob Blanchard Jr. <bl...@da...> wrote: > > Hi Adam, > > In my particular case, I'm using xsl-fo to generate a pdf. xslfo:render() > returns xs:base64binary (see code snippet below). > > In order to eliminate the possibility of the problem lying with xsl-fo, I > took a different pdf from the file system, and sent it via send-email() and > had the exact same issue. So regardless of the source of the binary file, > when sending via send-email() it has these strange spaces in the base64 > encoding. > > I could send to you off-list direct from send-email() if you wish to see > the full email source result. > > Thanks, > > -Bob > > let $fo := local:generatepdf($doc) > > (: Setup the email and then send it :) > let $email := > <mail> > <from>{concat(data($account), '@dainty.ca')}</from> > <to>{data($content/emails/switchlist/@to)}</to>{ > for $cc in tokenize($content/emails/switchlist/@cc, ', ') return > <cc>{data($cc)}</cc> > }<bcc/> > <subject>{ > concat('Switch List for ', data($date), > if (data($doc/sent/@revision) = ('', '0')) then '' else concat(' > (Revision #', data($doc/sent/@revision), ')')) > }</subject> > <message> > <text>See attachment for Switch List.</text> > <xhtml>{ > util:parse-html($content/emails/switchlist) > }</xhtml> > </message> > <attachment filename="switchlist.png" mimetype="image/png">{ > xslfo:render($fo, "image/png", ()) > }</attachment> > > > <attachment filename="switchlist.pdf" mimetype="application/pdf">{ > > xslfo:render($fo, "application/pdf", ()) > }</attachment> > </mail> > > let $send := mail:send-email($email, "" , ()) > > > > > > On Tue, 2011-10-04 at 21:10 +0000, Adam Retter wrote: > > Bob, > > > Whatever format the xs:base64binary data arrives to the mail function, > should be exactly what is written back out into the SMTP or Sendmail > payload. > > > So as part of the <mail> that you are passing into the function, you must > have something like this - > > > <attachment filename="switchlist.pdf" > mimetype="application/pdf">{$pdf-data}</attachment> > > > Can you double check what the form of the text child node of the attachment > element that you are using is? It may be that the spacing you see exists > there already? Where is that base64 data really coming from? > > > It may also be that I have a bug in the send-email(...) function code, but > I would like you to check the above first, if we can rule that out, then you > should be able to provide me with your <mail> and I should be able to > reproduce this here... > > > On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> wrote: > > *Re-post - email to list was delayed and back-dated* > > Trying to send attachments using the mail modules send-email() function, > and have run across a very interesting bug. > > Normal base64 encoders utilize fixed width output, but send-email() is > producing variable width base64 with extraneous spaces after each > newline. > > Some client-side decoders handle this fine, eg. Evolution on linux, > attachments open fine. But the very same email (from the same IMAP > server) viewed from Android/Profimail and/or Windows/Outlook, indicate > that the attachment is corrupt, and cannot be opened. > > Below is a small snippet from the email source which shows the space on > the second line (both lines truncated for brevity). > > --eXist.multipart.1.4.1 > Content-Type: application/pdf; name="switchlist.pdf" > Content-Transfer-Encoding: base64 > Content-Description: switchlist.pdf > Content-Disposition: attachment; filname="switchlist.pdf" > > > JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! > QvGRwP5zYvRmZi ... > > > I have tried both methods of sending (sendmail and SMTP), and have tried > different MTAs (Postfix and Sendmail), but the result is always the > same. > > -Bob > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Adam R. <ad...@ex...> - 2011-10-07 20:33:09
|
Okay... This issue is now fixed as revision 15429 in trunk and revision 15433 in 1.4.x Basically the MIME specification for email attachments RFC 2045, states on page 24 that - "The encoded output stream must be represented in lines of no more than 76 characters each." So no problem in our base64 encoding, rather that we had a problem in our send mail function where it was not respecting the maximum line length of 76 characters for the base64 encoded attachment. On 5 October 2011 17:06, Adam Retter <ad...@ex...> wrote: > > Bob, > Can you send me the email from send-email() (off-list), and also provide me with the absolute minimum that I need to reproduce the issue? > Cheers Adam. > > On 5 October 2011 16:23, Bob Blanchard Jr. <bl...@da...> wrote: >> >> The output does not contain any spaces. I can save the output direct from the logfile, and do a "base64 --decode" on it and it gives me a valid PDF file. >> >> -Bob >> >> On Tue, 2011-10-04 at 22:28 +0000, Adam Retter wrote: >> >> What happens if you call util:log("debug", ("MYFO=", xslfo:render($fo, "application/pdf"))) - you should then see the output in exist.log. Does that output contain these extra spaces? >> >> Cheers Adam. >> >> On 4 October 2011 21:46, Bob Blanchard Jr. <bl...@da...> wrote: >> >> Hi Adam, >> >> In my particular case, I'm using xsl-fo to generate a pdf. xslfo:render() returns xs:base64binary (see code snippet below). >> >> In order to eliminate the possibility of the problem lying with xsl-fo, I took a different pdf from the file system, and sent it via send-email() and had the exact same issue. So regardless of the source of the binary file, when sending via send-email() it has these strange spaces in the base64 encoding. >> >> I could send to you off-list direct from send-email() if you wish to see the full email source result. >> >> Thanks, >> >> -Bob >> >> let $fo := local:generatepdf($doc) >> >> (: Setup the email and then send it :) >> let $email := >> <mail> >> <from>{concat(data($account), '@dainty.ca')}</from> >> <to>{data($content/emails/switchlist/@to)}</to>{ >> for $cc in tokenize($content/emails/switchlist/@cc, ', ') return >> <cc>{data($cc)}</cc> >> }<bcc/> >> <subject>{ >> concat('Switch List for ', data($date), >> if (data($doc/sent/@revision) = ('', '0')) then '' else concat(' (Revision #', data($doc/sent/@revision), ')')) >> }</subject> >> <message> >> <text>See attachment for Switch List.</text> >> <xhtml>{ >> util:parse-html($content/emails/switchlist) >> }</xhtml> >> </message> >> <attachment filename="switchlist.png" mimetype="image/png">{ >> xslfo:render($fo, "image/png", ()) >> }</attachment> >> >> <attachment filename="switchlist.pdf" mimetype="application/pdf">{ >> >> xslfo:render($fo, "application/pdf", ()) >> }</attachment> >> </mail> >> >> let $send := mail:send-email($email, "" , ()) >> >> >> >> On Tue, 2011-10-04 at 21:10 +0000, Adam Retter wrote: >> >> Bob, >> >> >> Whatever format the xs:base64binary data arrives to the mail function, should be exactly what is written back out into the SMTP or Sendmail payload. >> >> >> So as part of the <mail> that you are passing into the function, you must have something like this - >> >> >> <attachment filename="switchlist.pdf" mimetype="application/pdf">{$pdf-data}</attachment> >> >> >> Can you double check what the form of the text child node of the attachment element that you are using is? It may be that the spacing you see exists there already? Where is that base64 data really coming from? >> >> >> It may also be that I have a bug in the send-email(...) function code, but I would like you to check the above first, if we can rule that out, then you should be able to provide me with your <mail> and I should be able to reproduce this here... >> >> >> On 4 October 2011 13:01, Bob Blanchard Jr. <bl...@da...> wrote: >> >> *Re-post - email to list was delayed and back-dated* >> >> Trying to send attachments using the mail modules send-email() function, >> and have run across a very interesting bug. >> >> Normal base64 encoders utilize fixed width output, but send-email() is >> producing variable width base64 with extraneous spaces after each >> newline. >> >> Some client-side decoders handle this fine, eg. Evolution on linux, >> attachments open fine. But the very same email (from the same IMAP >> server) viewed from Android/Profimail and/or Windows/Outlook, indicate >> that the attachment is corrupt, and cannot be opened. >> >> Below is a small snippet from the email source which shows the space on >> the second line (both lines truncated for brevity). >> >> --eXist.multipart.1.4.1 >> Content-Type: application/pdf; name="switchlist.pdf" >> Content-Transfer-Encoding: base64 >> Content-Description: switchlist.pdf >> Content-Disposition: attachment; filname="switchlist.pdf" >> >> JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoZVhpc3Qgd2l0aCBBcGFjaGUgRk9QKQovUHJvZHVjZXIgKGVYaXN0IHdpdG! >> QvGRwP5zYvRmZi ... >> >> >> I have tried both methods of sending (sendmail and SMTP), and have tried >> different MTAs (Postfix and Sendmail), but the result is always the >> same. >> >> -Bob >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb >> >> >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb >> > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |