SMTP email attachment sending method? - email

If SMTP only allows 7-bit ASCII, how do we send pictures/videos/files via email?
Do we encode these objects as 7-bit ASCII? Or basacally we can't send attachments via SMTP protocol?

Yes, we can attach binary files to email messages and send these using SMTP.
The solution is to use MIME and encode the files. One common encoding used is base64.

Related

Sending S/MIME encrypted emails through SendGrid SMTP

I am setting up a WordPress site that will send S/MIME encrypted emails via SendGrid using a plugin called WP PGP Encrypted Emails (looks like it uses PHP's openssl_pkcs7_encrypt). I have successfully sent, and decrypted S/MIME emails with my hosting provider's postfix SMTP servers. However I have to take into account deliverability, so I would like to use SendGrid (which is not a changeable requirement for me) to improve their deliverability.
The issue that I am running into is that first SendGrid's API will reject emails that have the content-transfer-encoding set to "base64". I don't know how significant this header is in the context of S/MIME emails, but whenever I remove it or change it, my emails don't come through as expected. I did some research and found that the API simply doesn't allow changing this header, but that I should be able to modify the content-transfer-encoding header if I send directly to SendGrid's SMTP at smtp.sendgrid.net. If I do that, I can indeed send out an email that arrives with an encrpyted attachment, as expected. The problem is that when I try to decrypt the attachment in Outlook (another requirement), I get a message saying that "the underlying security system cannot verify your Digital ID".
My questions are whether or not anyone has encountered this issue before and been able to resolve it, do SendGrid SMTP servers allow content-transfer-encoding to be modified, and what role does this header play in sending and recieving S/MIME encrypted emails?
Edit: Email Headers
X-Mailer: PHPMailer 6.5.3 (https://github.com/PHPMailer/PHPMailer)
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"; charset=UTF-8

Mail signing and encrypting with Apache Camel

I want to sign and encrypt my mail.
My current camel version is 2.13.0.
Is there a camel feature which I can use for this purpose?
Body is plain text therefore XMLDSig or so cannot be used.
Expected result should be a mail with these headers:
Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data
Content-Transfer-Encoding: base64
I solved the problem for sending.
I created a new MimeMessage with all required parameters like from, recipient, subject and content (Multipart with body and attachments).
With BouncyCastle I signed and encrypted this MimeMessage.
I set the resulting MimeMessage as body and sent it with standard camel mail endpoint. All required parameters will be selected from the MimeMessage itself and not from the exchange headers.
For receiving I will use also the camel mail standard but with the parameter mapMailMessage=false that I can process the received javax.mail.Message itself without preprocessing. For decrypting I will also use BouncyCastle.
I am not a Camel user, but I was curious and played around with it. What you want is S/MIME signing and encryption. This is currently unavailable, but there is a ticket for it which never got any response since it was created in February 2015. Camel has a MIME-Multipart data format, PGP encryption (but only symmetric), Sign/Verify (without encryption) - but I see no way to combine them in order to really get a valid S/MIME envelope for a signed + encrypted e-mail. Besides, PGP is not S/MIME and vice versa.
I do know how to compose and send such e-mail via JavaMail + BouncyCastle library, I even have sample code for it. Theoretically you could create the MIME message via JavaMail + BouncyCastle and then use Camel to send it or create your own S/MIME endpoint or data format (at least one-way for marshalling and skip unmarshalling if you do not need it). But out of the box I have not found a way to do it.
Update:
Even if I put a preconfigured signed & encrypted MIME part on the input endpoint and do this...
.setHeader("From", simple("sender#web.de"))
.setHeader("To", simple("recipient#web.de"))
.setHeader("Subject", simple("Signed & encrypted"))
.setHeader("Content-Type", simple("application/pkcs7-mime; name=\"smime.p7m\"; smime-type=enveloped-data"))
.setHeader("Content-Transfer-Encoding", simple("base64"))
... and the mail is sent, mail clients like Thunderbird cannot really disiplay the mail because the Camel mail endpoint overwrites the Content-Transfer-Encoding by a value of 7bit. There is another ticket for this issue, but also unresolved since June 2014. So for the time being you cannot even use the mail endpoint to send the message after you have built it via JavaMail and BouncyCastle. You even have to send it by yourself (also very simple via JM + BC, but annoying). So presently you cannot really use the Camel infrastructure because endpoints and data formats are unfit for S/MIME message composition.

How to send attachments in mail using amazon ses in grails

I'm using
Message message = new Message(subject, body)
amazonWebService.ses.sendEmail new SendEmailRequest(source, destination, message)
to send emails from my grails application
https://github.com/agorapulse/grails-aws-sdk/blob/master/src/docs/guide/amazonWebService/ses.gdoc
how can I add attachments to the mails and send
It looks like sendEmail takes a Message that only allows a subject and a body. However, you can use sendRawEmail instead. In that case you can add an attachment, but first you have to craft a mime message to pass to sendRawEmail. The linked example shows formatting the mime message with the JavaMail library. Once you have this mime message you can use sendRawEmail to send the message.
Depending on your situation, you can also use any mail library that supports sending via SMTP and simply treat amazon SES like any other SMTP server. That may make dealing with attachments easier depending on the library's features.

How to avoid base64 in smtp email

I am sending emails using powershell and smtp. The email include a csv file as attachment. However, the attachment is being receiving with a base 64 format. How could avoid that?. I need to get the attachment in normal ASCII format

Put raw emails into an IMAP account?

I am working on testing internationalization of an email reader application. As such I'd like to have a bank of emails with unusual subject encodings and the like to test with. I have been successful at identifying some emails with the headers endoded in specific encodings I would like to test, however I'm not sure how to successfully get the emails into an IMAP account (or alternatively a POP3 account would suffice as well) without butchering the existing headers/encodings.
With Outlook, for example, I can drag and drop messages into the IMAP account from my regular POP3 email account, or use the "resend" feature to send the message to a different account, however, with both of those solutions, outlook re-encodes the headers using it's own choice of encodings. So, for example, instead of the subject being base64 encoded, suddenly it's quoted-printable encoded, and I need it to stay base64 encoded.
So can anyone suggest how to get raw emails imported into an IMAP (or Pop3) account without changing the header encodings for fields such as subject?
Just use some IMAP client, you can store messages to IMAP server.
One free C# IMAP client you can get from:
http://www.lumisoft.ee/lsWWW/download/downloads/Examples/
SotreMessage allows you store raw message to IMAP server.
Also if you have messages in IMAP server and wnat to ttransfer them, you can use IMAP sync application from same link.
If it's just for testing, set up an IMAP server locally, and store the messages on that. Choose some fairly transparent storage so that each message is a file on the server. Don't use an email client to write them, they are just text files (and in particular not Outlook!)