I would like to know whether it is technically possible to created an S/MIME-encrypted E-Mail that also contains un-encrypted part. The idea is that the user would see the un-encrypted part, if and only if the message could not be decrypted (e.g. missing private key). Otherwise, if the message can be decrypted, the encrypted part will be displayed to the user as always.
A possible solution would be to wrap the whole S/MIME structure into a "multipart/alternative" MIME structure. One part would be "text/plain" containing some info text, the other part would be "application/pkcs7-mime" containing the actual (encrypted) payload.
However, I cannot find any information on whether S/MIME does allow this. Also it would be important to know if standard Mail-Clients can handle such construct in the intended way.
Thanks in advance for any information!
Yes, MIME allows this. Whether you'll find any mail clients that support sending it is a completely separate matter.
Related
This document here: https://docs.sendgrid.com/api-reference/mail-send/limitations
States the following:
Unicode encoding is not supported for the from field.
The to.name, cc.name, and bcc.name personalizations cannot include either the ; or , characters.
So I tried a test email to see what happens. I put emojis in the From name, and I sent to a To name of "John,;;, Doe;". There was no error and the email was successfully delivered.
Am I misreading these limitations? I want to make sure that what I build is correctly validating what it sends to the API, but these limitations don't seem to be correctly stated.
While I don't know exactly what the limitations are within SendGrid, I would imagine those limitations were written for a reason. It may well be the case that SendGrid itself can handle each of those characters, but the mailbox you are sending to may not. Obviously the test email that you sent handled those characters too, but that may not be the case for all mailboxes and you could cause yourself delivery problems if you try to send messages that conflict with these stated limitations.
I would stick within the guidelines for the best possible outcome.
I'm tasked with creating an Outlook form that will be used to communicate rate changes to our customers, and ask for their approval. The body of the email must have some fields that are required by the sender, such as customer name, and new rate. And the email must have an approval button or similar from the recipient. Its a relatively basic workflow
As I'm researching Outlook forms, I discovered this might be better suited for Outlook templates instead. But I'm new to this, and I'm not sure the difference between the two.
Any help or advice would be much appreciated!
Custom Outlook forms should be displayed on both sides of communication if you really want them working correctly. It is very inconvenient, so this feature is not really used nowadays.
Instead, you may consider using the MailItem.VotingOptions property which returns or sets a string specifying a delimited string containing the voting options for the mail message. This property uses the character specified in the value name, sList, under HKEY_CURRENT_USER\Control Panel\International in the Windows registry, as the delimiter for multiple voting options. As a result the recipient will see possible options to choose on the UI.
When the response comes back you may check the MailItem.VotingResponse property which returns or sets a string specifying the voting response for the mail message. This property is usually set to one of the delimited values returned by the VotingOptions property on a reply to the original message.
And the third solution is to develop a COM add-in which can handle custom data and provide a convenient UI for voting, for example, a custom form region can be developed for that. Again, this solution, like custom Outlook forms, requires installing the software on both sides of communication.
I'm uploading messages into my IMAP mail server via IMAP store operation. However, I would like to add "comments" to these messages so that when I download these emails again I know the they are created by "store". Basically, I need to add text which will be ignored by the formal semantics of parsing RFC822.
The specification of http://www.ietf.org/rfc/rfc822.txt defines how to add comments but I cannot make it working :(
Does anybody has en example of a RFC822 message with a comment in it?
You are probably looking for IMAP's annotations. However, it's an extension which is far from being common -- quite a lot of IMAP servers do not support it.
It seems that having a special "flag" on each message you created is something which would be enough for you. If that is correct, then simply using IMAP flags (or keywords) is what you're looking for. Simply add one special flag, like thisIsProducedByFooSoftware to the APPEND operation. (You said you were doing that via STORE -- that's wrong, in IMAP, STORE manipulates just FLAGS, it doesn't add new messages. New messages are added by APPEND.)
I'm working on an email project. For reasons that I will not go into here, doing quoted-printable encoding on long email messages is problematic in the customer's environment.
Doing base64-encoding on the HTML and text sections of the SMTP emails we are sending seems like a viable option. In testing it, it seems to work just fine in a couple test clients (like Gmail).
However I'm wondering if this will present any issues across different email clients. From reading the RFC specs, it looks like base64 is a compliant encoding for text sections, but it's unusual enough for text & html sections that I'd like to know if there will be any potential issues to consider.
Things that seem like problematic possibilities:
perhaps some older or less robust clients don't expect base64 in text or HTML email sections, and will fail to encode it
perhaps some email clients do a preview or search based on the raw content, so recipients would see base64 instead of the actual content
perhaps base64 could negatively influence deliverability/spam scoring?
Does anybody have experiences they can share? This seems like a good solution but I'd like to make sure I'm not missing something.
This is hard to answer -- yes, quoted-printable is used more often simply because it wastes less bytes (on a mostly-ASCII text) and because the raw text of the mail body part resembles the decoded output (on a mostly-ASCII text). There is nothing which forbids using base64 for the textual message parts, though.
This is pretty much an open question -- you cannot ever be sure that a MUA somewhere is not hopelessly broken to the extent of not showing anything. There's a lot of "perhaps" in there, and you're right -- but the problem is that you will never know. If it will make you sleep better, the following companies all use base64-encoded HTML in the marketing spam I'm receiving:
Mellanox
Alza.cz
Aukro.cz
Journal of Modern Physics
Any MUA which can display embedded images has to include a base64 decoder. It is definitely possible that a MUA might explicitly refuse to use that code for decoding text/plain and text/html, but in that case, you're just screwed anyway.
As a fun fact, one of these companies is happy to break the UTF-8 encoded subject at the byte boundary, inside a multibyte character, and encode both halves of the text in separate encoded-words (RFC2047 terminology here).
Imagine you want to provide the ability to publish news on your website sending an email to a given address (like for example publish.news#domain.com).
1) The base strategy is: look for something that is text/html and not disposition, and this is the primary body of the email.
2) Then look for any other content that is disposition and is attachment (and you'll get all the attachments).
3) Discard any other content that is disposition and inline because, correct me if i'm wrong, it's kinda stuff like email signature and thus not needed.
So far so good this strategy works good. However i don't know how to:
deal with multipart/alternative content. Some clients seems to compose HTML with this primary/subtype content-type.
deal with multipart/mixed (even don't know what it means).
if any email clients let to compose in html adding your own images and encoding them in some way.
Any help is much appreciated.
multipart/alternative just means that each part is an alternative version of the same thing, just with a different content type (say, an HTML version and a plaintext version).
multipart/mixed is used to put different content types inline. This will allow a client to put (say) an image inline in a message that is otherwise (say) plaintext.
You can read about all the multipart MIME types in the spec at https://www.rfc-editor.org/rfc/rfc2046#section-5.1 or in the Wikipedia article.