ERROR in Attachments from Outlook & others

[acidroad]

I was so happy for getting the efax/iaxmodem to finally work, than I decided to send to my ISP some emails from an Outlook or other microsoft product, including hotmail...
none of them work!
why? I really don't lnow yet..
This is what I get

22 Dec 2006 08:39:39,201 DEBUG Found 1 messages.
22 Dec 2006 08:39:39,201 DEBUG Processing message
22 Dec 2006 08:39:39,343 DEBUG Placing message in fax queue
22 Dec 2006 08:39:39,346 DEBUG FaxManagerOutBound message recieved for delivery.
22 Dec 2006 08:39:39,346 DEBUG FaxManagerOutBound passed message to channel Zap/g1 Both from-internal priority(1) count(1) for delivery.
22 Dec 2006 08:39:39,347 DEBUG Dequeued fax on channel Zap/g1 details:ID=7, To=[502], From ["Fábio Torres Balsemão" <yyyyyyy@hotmail.com>], Time(sec)=0, Pages=0, Subject=""
22 Dec 2006 08:39:39,347 INFO Loading submitter au.com.noojee.asterfax.outbound.submitter.EfaxSubmitter
22 Dec 2006 08:39:39,347 DEBUG Checking if submitter is already busy
22 Dec 2006 08:39:39,348 INFO No valid license found
22 Dec 2006 08:39:39,348 DEBUG Submitter is not busy. Mark busy now
22 Dec 2006 08:39:39,355 DEBUG Found part application/pdf; name="PP VBA Object Model.pdf" searching for compatible converter.
22 Dec 2006 08:39:39,355 DEBUG Converter found for part application/pdf; name="PP VBA Object Model.pdf"
22 Dec 2006 08:39:39,355 DEBUG Saving attachment to file /var/spool/asterfax/tmp/QWWWxx25772.pdf
22 Dec 2006 08:39:39,357 ERROR Error in encoded stream: needed at least 2 valid base64 characters, but only got 0 before padding character (=), the 10 most recent characters were: "0Y=\r\n----="
java.io.IOException: Error in encoded stream: needed at least 2 valid base64 characters, but only got 0 before padding character (=), the 10 most recent characters were: "0Y=\r\n----="
        at com.sun.mail.util.BASE64DecoderStream.decode(BASE64DecoderStream.java:227)
        at com.sun.mail.util.BASE64DecoderStream.read(BASE64DecoderStream.java:116)
        at java.io.BufferedInputStream.fill(Unknown Source)
        at java.io.BufferedInputStream.read(Unknown Source)
        at au.com.noojee.asterfax.messagestore.AttachmentExtractor.saveAttachment(AttachmentExtractor.java:344)
        at au.com.noojee.asterfax.messagestore.AttachmentExtractor.handlePart(AttachmentExtractor.java:284)
        at au.com.noojee.asterfax.messagestore.AttachmentExtractor.handleMultipart(AttachmentExtractor.java:240)
        at au.com.noojee.asterfax.messagestore.AttachmentExtractor.extractAttachments(AttachmentExtractor.java:194)
        at au.com.noojee.asterfax.outbound.Fax.getTiffFile(Fax.java:228)
        at au.com.noojee.asterfax.outbound.submitter.EfaxSubmitter.sendFax(EfaxSubmitter.java:58)
        at au.com.noojee.asterfax.outbound.SubmitFax.send(SubmitFax.java:110)
        at au.com.noojee.asterfax.outbound.Channel.run(Channel.java:105)


don't really know what this means, but I suspect of some sort of Java misinterpretation on the stream format??
Any body got this before??

[acidroad]

I've found somewhere that the problem might actually be on the mail header created by Outlook or other M$...
the thing seems to be the content-disposition tag that's set to attachment on such products...while the others use inline style... So I guess the built-in java routine is not taking care of that...
Could that be possible??

Please, if some one knows a workarroud for this, I'll be glad... since it's the last thing to finally get it to Production Boxes...

Thanks

[acidroad]

Is there the posibility to get a fix for this? or even the sources of the api that process the isp incoming mails??

[acidroad]

---------- UPDATING ----------

So, after a lot of work, we found out that the problem is with the multipart messages...
Something obout the boundary statement of the header seems to be malformed?? we try several mail clients (Outlook, express, gmail, hotmail, sendEmail, Thunderbird) and just Thunderbird and sendEmail worked fine
After that we get dirty, and modify mail headers by hand, using AsterFax External Inbound configuration....
We concluded that the emails containing a boundary statement wich includes an = sign are really tricky...
they worked fine without attachments, but when we added some attached files we got the previous error.....

So we were wondering....
Anyone got in this situation before??
can anyone who knows a little more about emailing and base64 encoding explain that???

whe are working on a way to get this to work on production enviroment, and be glad to know a bit more on this....

Thanks everybody

[warrick.zedi]

Sorry for the delay getting back to you. Please send me a sample .eml file from your spool directory. I'll work on a fix. I've had various challenges with mail formats, particularly multipart.

[acidroad]

Hi Warrick.

We workarround this problem with a little shell scripting, just to change de boundary strings on the incoming email, but it sure be nice to haven't got this problem.

The thing is just that, some email clients (and web mails) generate an "invalid" boundary for multipart emails.

some "invalid" (at least for asterfax) examples:

Outlook:    boundary="----_=_NextPart_001_01C73320.FCEDA030"
gmail:        boundary="----=_Part_25916_30515199.1167994684319"

Using thunderbird it just works

Thunderbird: boundary="------------020004060201070203000900"

So after a lot of reading, incluiding some base64 research, we found out that
the first 4 characters of the boundary must be "----" as can be seen on all of them
the tricky part is after that, where some mail agents send something containing an = sign (in base64 = is used as padding)

So what we did was:
Instead of receive the emails via AsterFax ISP method we used Fetchmail+Postfix to get the messages into the asterisk box. Then a shell script alters the invalid boundary strings to a valid one we've created manually, and move the files to another folder where AsterFax External method polls for new emails.

It was certainly not easy to figure it all out, so it will be nice to get the new versions to be able to handle boundary directly from the ISP method.

Let me know if you need more on this.
be glad to help you.

[warrick.zedi]

Thanks for the perseverance and the information. I'll look at making our process more robust using this info.

[wwwdrich]

Thanks for the perseverance and the information. I'll look at making our process more robust using this info.

I'm seeing something odd with multipart/alternative on my system as well.  Our web site sends e-mail with a mulipart message that contains both a text and html version of the information.  From the logs, it looks like AsterFax is only trying to convert the text portion, not the html portion.  What is your logic for which part to convert?

When in look in spool/tmp, the .body files are all the text/plain portions of the message.

[warrick.zedi]

The code grabs the first part in a multipart/alternative. Can you suggest better logic? I suppose it makes sense to pick HTML over plain text to preserve all intended formatting and presentation but it won;t always be HTML/text. What happens when there are other formats involved? So I always take the part that isn;t plan text? What if none of the alternatives are plain text? What happens if there are more than two alternatives?