This content has been marked as final. Show 5 replies
I further investigated it to be "something to do with MIME Encoding"
There is this MIME option in the JFEMAIL.INI where we set to NO and it was send OK buy now Our Lotus Notes Server trucates the PDF extension so users are unable to open the file.
I wonder if your upgrade of Lotus Notes implemented a safety feature for "blocking" viruses & worms. At one time, for a short while, there was a version of PDF files that could be manipulated by the virus/worm designers - at least that is what I vaguely recall; for all I know it was just a rumor. Anyway, one way of getting by that would be to strip the extension so that a person could not blindly click on the attachment and have it open and do its dirty work. They would have to save the flie with the correct extension and then use Acrobat/Reader to open the file.
If this is the case, then there might be an option within the server software for not messing with certain extensions.
It might be helpful for you to know if the extension is being dropped by the server or by the user's client. If that is known you would have a better idea of where to look for an option to have it stop doing it.
In the Microsoft Exchange/Outlook world it will totally drop the attached file if it has certain extensions. There is a client add-on product that allows a person to specify which extensions are to be allowed.
Yeah Tom you're right. The extension is being droped off by the User's client. Its a mail reader preference set by the user to a user. When the user preference is set to Notes Rich Text Format, the extensions are being dropped off.
Yep, the easier way is to detach file and rename the extension.
But 'dull' users will still complain.. I was thinking if higher version of Adobe Output Server will solve this problem. I mean it should encode it in Mime Format correctly so that the Lotus Notes or whatever Mail Servers should decode it properly. I am more sure that It is the MIME thing encoding/decoding that is causing the problem.
Here is part of the README.TXT file that Adobe sent together with the patch to correct this problem.
Patch Update to Messaging Agent 5.5
There is a known issue with Messaging Agent sending messages by SMTP (not MAPI) in these environments:
Windows Exchange 2000 Server
Windows Exchange 2003 Server
Domino Server 5.0.13a
The symptoms of the problem include the e-mail to, from, and date sent information found in the body of the message
but blank on the envelope of the message, empty attachments, or attachments in the body of the message displayed as base-64 encoded data.
The problem occurs because of a conflict between the line termination characters required by SMTP and the Exchange and Domino Servers. The SMTP standard stipulates that messages sent by it use CR/LF line termination characters. The Exchange and Domino Servers require that messages use LF line termination characters only, which is non-standard.
We recommend that you install the patch ONLY if you meet the following criteria. Only install the patch if you are using the SMTP protocol to communicate with an Exchange or Domino Server from Messaging Agent OR if you encounter these symptoms with another SMTP-based mail server.
With the patch, Messaging Agent recognizes two new settings that control the selection of the line termination characters. Specify the value of yes for one of these settings in order to resolve the issue described above: