Problems sending HTML mail with attachment on iPhone - iphone

I'm trying to send a JPG attachment with a formatted HTML message. Of course I'm using [picker setMessageBody:emailBody isHTML:YES];
The rest of the code is what it is supposed to be, according to various messages on forums.
What I observe: the contents of the resulting e-mail message depends on the configured e-mail account on your iPhone.
E.g.: for a Yahoo mail account, setting isHTML to YES never results in an HTML message, but setting it to NO does! Bug in Apple stuff?
But, for a GMail account, I've never succeeded to send an HTML mail, it is always received as plain text.
The JPG file is sometimes shown inline, sometimes as an attachment.
All I want: send a JPG file, and a message containing some line breaks. Does anybody have some proven code that does just that, working for all kinds of e-mail accounts?

Even if you set isHTML param to YES, your message body can be sent as plain/text if the message body can be represented as such. And attachments in plain/text messages are not always recognized correctly by some email clients (Outlook).
In my case adding a link in the message body helped. Formatting text as bold with HTML tags works too. Tricky!
Tested on iPod 1G 3.1.3.

Related

Send email in Azure Logic App with binary attachment

I am trying to use the "Send an email" on the office365 connector.
I am trying to send an email with a binary attachement. When i receive the email the content appears to be Base64 encoded. In order for my file to work, the content should not the raw binary payload.
How do i avoid the base64 encoding? I tried removing the base64 part: #{base64(body('binaryStuff'))} in the code, but that caused my app to fail, with a "BadRequest" message.
How do i send a binary attachement in my logic app?
After letting the function return Base64 string of the mail attachment instead of byte[], the logic app seems to be able to figure out that the contents is encoded.

Test email rendering - HTML raw source or HTML pre send?

I am testing some HTML email layout, I am not sure to understand which is the HTML I should consider:
use the HTML as it is sent from my server to mailgun (an email service provider)?
use the HTML as I receive it in raw format in the email I receive?
The difference is that in the raw source I receive there are =3D and =20 characters because of the quoted printable format. I'm using testi# but I suppose any rendering software will do, just it's not clear which version of the HTML should be used (needless to say I see =20 everywhere if it's raw, whereas it's perfect if I use the "pure" HTML)
You should use the HTML as it is before being sent. I'm unsure of how testi# works but with other services such as Litmus & Email on Acid you can send a test to them directly from your ESP and they will process that for the previews.
[Added from comment on question to allow close]

Urdu Language Support for sending email to hotmail and yahoo with phpmailer

I am using phpmailer to send my auto-generated text/mail to users. body of the mail contains Urdu (Unicode), which is shown by google perfectly, but hotmail and yahoo mail shows the mail as shown in the following snapshot:
is this a bug or i am missing any Unicode supporting parameter for sending my emails-
You need to ensure that your code tells PHPMailer to use UTF-8:
$mail->CharSet = 'UTF-8';
Note that the property name CharSet is case-sensitive, so ensure it matches exactly. You must also ensure that your content in also UTF-8 format.

Having an HTML body when using the Gmail URL scheme in Swift 3

I'm looking to call the Gmail app with a preconfigured subject and the body contains HTML using the following:
let gmail = URL(string:"googlegmail:///co?subject=Subject&body=<body><H1>testing</H1></body>")
UIApplication.shared.openURL(gmail!)
This will crash the app, I then resort to:
var messageEncoded1 = "<body><H1>testing</H1></body>".addingPercentEncoding(withAllowedCharacters: .urlFragmentAllowed)
let gmail = URL(string:"googlegmail:///co?subject=Subject&body="+messageEncoded1!")
UIApplication.shared.openURL(gmail!)
And this will create a URL and open Gmail, however, body of the email shows: <body><H1>testing</H1></body> and not the work testing like so:
testing
So the question is, is there a way to specify that the body holds HTML so that Gmail can render it as HTML?
No, for now, Gmail doesn't render it as HTML. Moreover, mailto standard RFC2368 itself doesn't obligate to render tags in body property:
The special hname "body" indicates that the associated hvalue is the
body of the message. The "body" hname should contain the content for
the first text/plain body part of the message. The mailto URL is
primarily intended for generation of short text messages that are
actually the content of automatic processing (such as "subscribe"
messages for mailing lists), not general MIME bodies.

could hyperlinks in emails be getting changed by the destination mail server

We send out password-reset emails to business partners who use our intranet. The body of the email contains a hyperlink:
`http://www.ourdomain.com/ResetPassword.aspx?token=....`
But some of the people who receive these emails are saying there's an extra dot in the domain name:
`http://www.ourdomain..com/ResetPassword.aspx?token=....`
I do not see where that could be happening in the program I've written. I store the base url in the web.config:
`http://www.ourdomain.com`
and attach the name of the aspx page and append the token to it.
Are there any corporate anti-virus programs out there which deliberately mangle hyperlinks discovered in the body of emails, to render them invalid and thus unclickable?
This seems to be per the spec of quoted-printable encoding. It just so happens that the length of text in the message breaks to a new line right at the .com (72 characters maybe?). Please verify that this is the case by sending yourself a message and analyzing the quoted-printable source of the message.
System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names
The solution would be to not use quoted-printable encoding if some email programs cannot correctly interpret the spec.
plainText.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
//or base64