I've created a custom transport for CakeEmail (to allow me to use Mandrill to send email). However, whenever I access the content of the message (which is cake email template driven), it doesn't encode the characters correctly (it changes 'é' to 'é', etc). If I use CakeEmail and bypass the transport, it displays the characters correctly in the email. I've narrowed this down to $email->message('html') in the transport code. If I output $email->message('html'), the characters are already incorrect.
App::uses('AbstractTransport', 'Network/Email');
App::uses('HttpSocket', 'Network/Http');
class MandrillTransport extends AbstractTransport {
public function send(CakeEmail $email) {
debug($email->message('html'));exit;
}
}
Thoughts?
You most probably have an encoding mismatch somewhere, if for example your App.encoding doesn't match your CakeEmail::$charset, CakeEmail would try to convert the content from App.encoding to CakeEmail::$charset.
https://github.com/cakephp/.../2.6.2/lib/Cake/Network/Email/CakeEmail.php#L1338
If for example the former were iso-8859-1, and the latter utf-8, just like the content, you would end up with the result you are showing here.
// outputs é when displayed as utf-8/unicode
echo mb_convert_encoding('é', 'utf-8', 'iso-8859-1');
You'll have to do some further debugging to trace down where exactly things are going wrong.
Related
I am trying to read a digitally signed mail from java code using multipart and mime messaging and fetch the attachments (xml, pdf, txt etc.,) and message details.
My code is working fine for mails having Content-Type as : multipart/signed; protocol="application/x-pkcs7-signature";
But For few mails having Content-Type as : application/pkcs7-mime; smime-type=signed-data; name=smime.p7m it is not fetching the attachments and message details. Can anyone explain what is the difference between both of them and how to resolve it.
I recently came across this issue myself, and although this question is three month old, I leave an answer with my findings, just in case.
Both kinds of messages are instances of S/MIME signed messages as specified in RFC2633 (https://www.rfc-editor.org/rfc/rfc2633).
The multipart/signed; protocol="application/x-pkcs7-signature" indicates a clear-signed message (section 3.4.3.3 of the RFC), meaning you can read the original message content without having S/MIME capabilities in your client code. Hence no problem with these.
The application/pkcs7-mime; smime-type=signed-data; name=smime.p7m indicates an S/MIME signedData email (section 3.4.2) Your client code needs S/MIME capability in order to read the original message (even if you don’t care about the signature).
Easiest way (worked for me) is to use bouncycastle's SMIMESigned class (from the S/MIME API, https://mvnrepository.com/artifact/org.bouncycastle/bcmail-jdk15on), like this:
byte[] content = <the signed data's content as byte[]>;
ByteArrayDataSource dataSource = new ByteArrayDataSource(content,"multipart/signed");
SMIMESigned signedData = new SMIMESigned(new MimeMultipart(dataSource));
MimeBodyPart bodyPart = signedData.getContent();
<you can process the body part as normal from here>
With smtp, i know the commands: "HELO", "MAIL FROM", "RCPT TO", "QUIT", but i don't know how can i attach one file. Anyone can help me ?
telnet smtp.xxxx.xxxx 25
helo xxxx.xxxx
mail from: yyy#xxx.xxx
rcpt to: yy2#xxx.xxx
data
subject: hi
hello
.
quit
This is not something that can be easily done. You probably want to use a library (ex : in python) that will take care of formatting your email according to your needs.
In very brief :
Sending an attachement requires the email to be formatted according to the MIME RFC
A MIME formatted message will use some delimiters to separate the different parts of the message (ex : a plain text part, an HTML part, an attachment part, etc...)
Each MIME part will be prefixed by a header detailing the part content
an attachment part will be identified by a "Content-disposition" header, as detailed in RFC 2183.
The representation of your file will have to be specified using the "Content-Transfer-Encoding" header, described in RFC 2045. A common way to encode files for mail transfer is base64.
If you want to get an idea of how complex it is to generate an email with a valid attachment, you can use your email client to check the source of an email with an attachment (most email clients have this feature). That should eventually convince you to avoid doing this manually :)
I'm having trouble getting more than just the snippet for text data for the message I am trying to retrieve using the Gmail API. Here is the piece of test code I am working with:
public string GetMail()
{
GmailService service = (GmailService)HttpContext.Current.Session["service"];
Message messageFeed = service.Users.Messages.List("me").Execute().Messages.First();
UsersResource.MessagesResource.GetRequest getReq = new UsersResource.MessagesResource.GetRequest(service, "me", messageFeed.Id);
getReq.Format = UsersResource.MessagesResource.GetRequest.FormatEnum.Full;
Message message = getReq.Execute();
return message.Raw;
}
For some reason, when I call message.Raw, it is returning null. I am able to retrieve other properties as what the format=minimal setting would based off of the API playground example I was playing with.
However in my code, I am setting the format enum to "full", yet I am still unable to retrieve the full data of the message.
Am I completely missing something here?
Seems like you're mixing up formats and response types. If you want the raw message as a string in Message.raw then you need to set:
getReq.Format = UsersResource.MessagesResource.GetRequest.FormatEnum.Raw;
If you want the parsed message back (in the "payload" field) then you can use getReq.Format of Full like you have.
Acceptable values are:
"full": Returns the parsed email message content in the payload field and the raw field is not used. (default)
"minimal": Only returns email message metadata such as identifiers and labels, it does not return the email headers, body, or payload.
"raw": Returns the entire email message content in the raw field as a string and the payload field is not used. This includes the identifiers, labels, metadata, MIME structure, and small body parts (typically less than 2KB).
from: https://developers.google.com/gmail/api/v1/reference/users/messages/get
When sending emails via javamail, the following is always appended to the bottom of each message:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. This message contains confidential information and
is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. If you
are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.
How does one prevent this?
(NOTE: This problem is extremely frustrating to research on the web due to the fact that a disclaimer of this form is attached to so many indexed documents! :-(
JavaMail is not doing that, it is your outgoing SMTP server appending it to each message, probably set up by IT.
To confirm, you can use gmail's servers (with a personal account) and you will see it does not get added to the messages.
This should work. Pay attention to the form in which email body get parsed. In my case the emailBody string is on one line, so you have to put the "#Your disclaimer Here#" on one line. Answer for who will come in future.
public String deleteDisclaimer(String emailBody) {
String disclaimer = "#Your disclaimer here#";
if (emailBody.contains(disclaimer)) {
System.out.println("Deleting Disclaimer..");
return emailBody.substring(0,emailBody.indexOf(disclaimer));
}
System.out.println("DISCLAIMER NOT FOUND!");
return emailBody;
}
I have developed a program in java which fetches subject, sender, from and datetime of email information from an email account. I have done that using html parser and httpclient. I have two problems.
When I parse a subject string of the email I get some wiered character sometimes. for e.g. if subject is "Hi Mr. müller", I receive subject string as "Hi Mr. müller". As you can see it's not giving ü character properly. Any idea which encoding is this ? Is it UTF-8 ? How do I decode it to get the original string ?
I have also received email information like subject, sender, receiver, datetime etc. from yahoo account with pop3. In that I have noticed when the sender email id contains ü or ue (for e.g. reva.müller#gmx.de), it encodes it like ('=?iso-8859-1?Q?=22Reva_M=FCller=22?= '). Any idea about which encoding is this ? Is it mime encoding ? How do I decode it in java to get correct sender string ?
I would really appreciate any help.....
You need to read the RFC: http://www.ietf.org/rfc/rfc2045.txt. It will tell you how to interpret those = signs.
See "6.7. Quoted-Printable Content-Transfer-Encoding".
Also look for a Content-Type header to clue you in on the encoding.