We have recently upgraded JavaMail API to latest version 1.5.4. After upgrading we found that attachments (with filename > 60 characters ) are received as .dat filename in Outlook (which is configured with POP3).
Please note this issue only comes when filename is more than 60 characters and Outlook is configured with POP3.
We noted that name and filename attributes are coming as multiple line after JavaMail upgrade.
MAIL HEADER BEFORE JAVAMAIL UPGRADE
Content-Type: application/octet-stream;
name=Automation_Team_Directory_05-Dec-2015_123219_21312_155018252272708.PDF
Content-Disposition: attachment;
filename=Automation_Team_Directory_05-Dec-2015_123219_21312_155018252272708.PDF
MAIL HEADER AFTER JAVAMAIL UPGRADE
Content-Type: application/octet-stream;
name*0=Automation_Team_Directory_05-Dec-2015_123219_21312_155018252;
name*1=272708.PDF
Content-Disposition: attachment;
filename*0=Automation_Team_Directory_05-Dec-2015_123219_21312_155018252;
filename*1=272708.PDF
How can we fix the issue so that it will show attachment properly in Outlook with POP3?
Set the System property mail.mime.encodeparameters to false. This disables the RFC 2231 support when creating messages.
I came here because I had the same issue with attachments being emailed out of newer versions of Coldfusion 11, 2016 and 2018 that had received recent patches upgrading their Java Mail.
This reaffirmed an entry found on a Japanese website that you can put this property into Coldfusion by adding it to the JVM properties, either through the Admin screen or editing the jvm.config file.
http://cfassociates.samuraiz.co.jp/index.cfm/faq/cftech/cfmail-attachfilename-garbled/
The property to add then is:
-Dmail.mime.encodeparameters=false
You will find that it changes the style of header used to define the attachments as described above.
Related
We have a wagtail (2.0.1) install with documents enabled, but uploading a pdf leads to links to that pdf that don't use the correct mime-type for previewing in the browser. Instead they just instantly go to file download.
Looking at the header, the reply contains:
Content-Type: application/octet-stream
which for documents is almost always the wrong mime-type, especially documents that have built-in browser "previews". Is there a way to configure which mime-types to use for which document extensions (settings.py, a mime-type-for-extension admin interface that requires a plugin, etc.)?
I'm working on a custom implementation of a server (VERY basic WebDAV) that accepts Outlook's published calendars.
Outlook seems to have a setting (see the screenshot below) where it accepts a parameter form the server that tells it how often to re-publish the calendar and that's the parameter I'm trying to figure out.
If the setting is not specified Outlook defaults to 60 minutes which doesn't work for me but I cannot find any information on what the parameter might be (I am aware that Outlook's settings can be adjusted within the UI but I need it done automatically via a response from the server). When using Wireshark I see that when first publishing the calendar Outlook sends a PROPFIND method to the URL of the server:
PROPFIND /path/to/url HTTP/1.1
X-Office-Version: 15.0.4771
Depth: 1
Content-Type: text/xml
User-Agent: Microsoft Office/15.0 (Windows NT 6.3; Microsoft Outlook 15.0.4771; Pro)
Host: example.com
Content-Length: 114
Connection: Keep-Alive
Cache-Control: no-cache
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"><D:prop><D:resourcetype/></D:prop></D:propfind>
which then responds with an XML (I'm assuming this is where the setting would be, but cannot find any information on it):
<?xml version="1.0"?><a:multistatus xmlns:a="DAV:"/>
I'm lost at this point and not sure where else to be looking after lots of Googling and traffic sniffing (of Outlook <->Exchange communications but none that I found seem to be using the non-default param). Any suggestion where would be a good idea to look for something like this?
CalDAV (Calendaring Extensions to WebDAV, documented in RFC-4791) uses the iCalendar (Internet Calendaring and Scheduling Core Object Specification, documented in RFC-5545, not to be confused with Apple's iCal) format for the data exchange. iCalendar accommodates non-standard properties that start with a "X-" prefix.
X-PUBLISHED-TTL is the property that maps to the recommended update interval for subscription to the calendar. It's supported by Microsoft for Outlook & Sharepoint, and possibly by some more calendar publishers, but not by Google or Apple.
Example values:
X-PUBLISHED-TTL:PT1H (every hour)
X-PUBLISHED-TTL:PT120M (every 120 minutes)
There's also some work-in-progress to officially add a similar property to the iCalendar spec. According to the latest version of the New Properties for iCalendar draft proposal, the new REFRESH-INTERVAL property would be used in the following way:
REFRESH-INTERVAL;VALUE=DURATION:P1W
There is no Outlook Server setting for frequency of polling. This setting is at the client end. On an email client "check for new messages" is used to avoid overloading the server with requests. See the MS Outlook website .
I'm receiving inbox via pop3 using JavaMail (1.5.0). One of the servers sends the wrong-formated content-type string. There is encoding added after boundaries. It looks like:
Content-Type: multipart/mixed;
boundary="=_NextPart_2rfkindysadvnqw3nerasdf";koi8-r
It causes an error on parsing:
javax.mail.internet.ParseException: Expected '=', got "null" at
javax.mail.internet.ParameterList.<init>(ParameterList.java:250) at
javax.mail.internet.ContentType.<init>(ContentType.java:114) at
javax.mail.internet.MimeMultipart.parse(MimeMultipart.java:580) at
javax.mail.internet.MimeMultipart.getCount(MimeMultipart.java:325)
Is there any possible way to correct mail stream before actual parsing?
I've tried to compile sourses of the library to extend the functionality but this is not as easy as it should be (not sure where to settle bugfix).
See the description of the mail.mime.contenttypehandler property in the javadocs for the javax.mail.internet package. That allows you to write a class that cleans up the Content-Type value before JavaMail uses it.
And of course you should report this bogus header to either the server vendor or more likely the vendor of the mailer that created the message.
My program picks up mail from a PoP3 enabled email exchange server.
This mails have screen shots as part of the body.
I want to save the screenshots in the mail on the local drive.
I am using JavaMail API.
The API doesnot pick up the screenshot as an inline attachment but rather says the mime type of the email message is text/html.
How do I pick up this screenshot using javamail.
All I get is a src:cid
If it's referencing the screenshots using src:cid, the text/html will be one part of a multipart/related and the screenshots will be other parts. You can match up the cid reference with the Content-ID of the parts.
How do I make my Apache 2 server force a browser to open a file transfer dialogue if the URL points to a file with a .pln or .psa extension?
I have a simple LAMP server with CentOS 5, Apache 2, MySQL 5, PHP 5, recently built CentOS 5.2 i386 installation CDs. My web application generates files to be downloaded and imported into a custom application. The file extensions are .psa and .pln. How do I make my server force the browser to open a file transfer dialogue? If I point my browser to a .psa or .pln file on the Apache 2 server, the file's content is displayed in a pop-up window as simple text. I want a file transfer dialogue.
The web-app I am working on is deployed on another web-server and handles the .pln and .psa files as desired. I cannot compare server configuration files because I do not have administrator access to the working server.
How do I change my server's behavior? Does this require code changes to my web-app code (such as sending explicit headers)? If so, why does it work against the other server? Can code changes be avoided by configuring the server's default behavior?
You should be able to use the FilesMatch directive to add the necessary header.
<FilesMatch "\.(?i:pin)$">
Header set Content-Disposition attachment
</FilesMatch>
I tried several configuration changes which had no apparent effect.
I added the following line to my /etc/httpd/conf/httpd.conf file:
AddType application/octet-stream .pln .psa
I restarted the Apache server and it had no effect.
I added the following lines to my /etc/httpd/conf/httpd.conf file:
ForceType application/octet-stream
Header set Content-Disposition attachment
ForceType application/octet-stream
Header set Content-Disposition attachment
I restarted the Apache server and it had no effect.
If you have Firefox (and if not, why not?) install Chris Pedericks Developer Toolbar, and check that the headers are actually being set correctly. If so, it may be the fault of the browser. As I said, you can't be certain that any given browser will "correctly" interpret the response headers. What browser are we talking about here anyway?
If the headers aren't being set correctly, you may need to re-check your httpd.conf file. Possibly the directives you added aren't in the correct section? (e.g. under the wrong <Location > directive)
Forcing a browser to do something is always a tricky proposition, since the browser can ignore you and do what the hell it likes
That said, most browsers will prompt the user with a "save as" dialog box if the "Content-type" header is set to "application/octet-stream". Either write a simple wrapper CGI that serves up the requested file with the correct header, or fiddle with Apache2's mime-types (look in the config directory.)