I have an application that has an agent that converts a document to the MIME format ('memo.convertToMIME (2)') and sends it to multiple external emails: gmail, hotmail, yahoo, etc ... This agent is triggered by a button.O problem is that when the e-mail sent is read by the browser in hotmail, the images do not appear, but the texts, tables and formatting appear normal. As for gmail, yahoo, etc, e-mail usually appears by the browser. The funny thing is that when I send an e-mail address so convecional the lotus, other than by application of a lotus, only using the client, this e-mail test is usually read by hotmail in your browser. Does anyone have any idea what might be happening? PS: This agent is designed to run on the server, because the command 'convertToMime ()' only works for version 8.5 of the lotus forward, but the company has users using lotus client 7.
Asked
Active
Viewed 928 times
0
-
What does the content of the email look like on the different recipients? Are you confident that hotmail will load images? Are you confident that your sender has been placed in a whitelist of some sort for loading images, if hotmail provides such a list? – sarnold Apr 21 '12 at 00:49
-
The question is: this application has a form where the user fills in the fields and then sends it to mostly other users within the company, therefore, these other users have a lotus notes client and view e-mail usually . But there is a field on the form that allows the user to enter an external email, in case any email that is not part of the company domain, example: gmail, hotmail, yahoo, etc. .. – Alexandre Oliveira Apr 21 '12 at 01:05
-
The question is for gmail, yahoo, icloud, mail (client apple), Outlook (windows client), the email is usually seen, but when I access a hotmail account via the web and try to see the email, it shows formatted form, but in the richtext field contain an image, it does not appear, leaving only a white board with an x in the middle. Bad if I open the lotus notes client and send a regular email containing a picture and open through the browser, the image appears normal. So what I think is happening is a problem in the conversion of the application form for the MIME type 'memo.convertToMime (2)'. – Alexandre Oliveira Apr 21 '12 at 01:06
-
The funny thing was that before the same solution worked for hotmail, now that there was a change in hotmail, this solution is no longer working, but for other emails (gmail, yahoo, ect ..) is still functioning normally. – Alexandre Oliveira Apr 21 '12 at 01:09
-
I think the problem is actually in the conversion. I've tried to write the same agent in lotuscript and java, but in both cases the result was the same, the image problem continues. – Alexandre Oliveira Apr 21 '12 at 01:11
-
I'm from Brazil and does not write very well English, I'm using 'Google Translator' as assistance. – Alexandre Oliveira Apr 21 '12 at 01:14
-
It sounds like you need to verify the settings in Hotmail since it works in all other email clients. – Per Henrik Lausten Apr 21 '12 at 05:41
-
2The conversion doesn't do anything different for hotmail than it does for the other sites. What you need to do is turn on a setting on the Domino server that captures a file containing a copy of the exact RFC822/MIME data that is being sent to hotmail, and then edit your question to include the complete contents of the file. We can examine the data in the file to help you figure out why Hotmail has a problem with it. This IBM technote describes the setting: http://www-01.ibm.com/support/docview.wss?uid=swg21088993 – Richard Schwartz Apr 21 '12 at 06:23
1 Answers
0
According to Bob Balaban, there's a glitch in the conversion code deep underneath the C API layer: it does not automatically convert attachment contents to a base-64 encoding (even though the API documentation says it will) - it leaves them in binary format.
See Geek-O-Terica 15: Easy conversion of Notes documents to MIME format (Part 1) for details.
A view of the MIME created/received by an external user would help us too in determining, what is exactly wrong.

leyrer
- 1,444
- 7
- 9