If you have already exchanged certificates with somebody and you already encrypt emails, do you sign the following emails anyway/again? What is the accepted standard procedure for this? Where is this described?
The purpose of a (cryptographic) signature on an email is to prove that the sender is who the sender claims to be, and not some one who found an open relay mail server to forge a From:. Therefore one would sign any message that one wants to have proof of origin on, which one presumes would be all messages.
Encrypting means that only the intended recipient(s) can read it, but doesn't say anything about who sent it. So, great, an encrypted mail had an attachment... still throwing it in the trash. Or, I might have a policy to not decrypt it at all because it's bigger than 100kb and unsigned (I don't know of any client that has policies like that, but they're not unreasonable).
Related
at the moment we're using Microsoft Flow for specific workflows.
The Flow does detach the attachment of an E-Mail. This step is not working when an E-Mail is send with a certificate. I've attached an example for what I mean:
Thanks for your help.
Microsoft Flow seems not to support content inspection of S/MIME-signed emails including finding their attachments. I have tested this for clear signed emails as well as enveloped signed emails.
You could possibly write a MIME or S/MIME parser in Flow, but I think it will be ugly.
Instead, you can at least create a condition to detect S/MIME signed emails and do some error handling like pushing a warning notification that the flow failed due to the incompatibility. If you have a foreach-loop for the attachments, then inside the loop, the following condition detects S/MIME signed mails (use advanced mode to enter):
#or(equals(items('Apply_to_each')?['ContentType'], 'multipart/signed'),equals(items('Apply_to_each')?['ContentType'], 'application/pkcs7-mime'))
multipart/signed is for clear signed S/MIME signatures, application/pkcs7-mime is for enveloped S/MIME signatures.
I will be sending legitimate emails to a list of recipients and some of them are probably obsolete by now.
I wish to know, based on the email bounces, which are obsolete and delete them from the database. Except VERP I haven't seen anything standardized for this task.
Is there some other way that you know about?
There is no other way than VERP. DSN mails are good to extract the precise reason of bouncing, but not all servers send standard DSN mails. In addition to that, DSN mails can be forged which may be an issue. You can add a simple digital signature to a VERP address.
There is absolutely a way to do this. I run the engineering team at Kickbox. Our product takes a list of emails and will tell you which are valid and which are not (without sending to them). We have an API too.
You want to avoid bounces by sending to bad emails. Send to too many and your IP address will be globally blacklisted.
You can technically verify emails yourself through regular SMTP (just stop the SMTP commands before actually sending the email), but there are plenty of weird SMTP edge cases and for any serious number of emails you'll want to do this through a proper email network (like ours :-).
Hope that helps
I'm implementing an application in ruby on rails (although this is a minor detail) that needs to send emails. Everything works fine, but I'm surprised cause when the app sends a mail, as long as it's authenticated against the smtp server, the sender it's going to be whatever it's specified in mail from. My point is, I can authenticate in a smtp server with "myuser#mydomain.com" and "mypassword" and be able to send a mail in which the recipient would see whichever address I want as sender.
This doesn't make any sense for me, and I'm sure it can't be so easy. I know it's surely a completely silly question for most of you, but would really appreciate anyone could make it clear for me.
Cheers!!
You authenticate as a generic user, it is only an accident that your login name is similar to a mail address. And yes, usually you can send mail with any reverse-path (reverse-path is the address in the MAIL FROM SMTP command). This may be necessary, for example a list manager uses VERP and sends mails with many unique reverse-paths.
However, some mail servers and mail administrators do place restrictions on the reverse path and the address in the From header. Especially, if the server signs the message.
Moreover, if the receiving server checks SPF records, it is useless to impersonate a remote domain, even if it is allowed, because the mail will be rejected anyway (if the domain publishes an SPF DNS record).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have to send sensitive information (name, address, social security number etc.) collected from a website, that has been entered by a user, to an e-mail address.
What is the best course of action to make the information secure and easy to extract on the receiver side?
Edit: I will be using ASP.NET for the website, not sure what it has for capabilities on this matter.
Edit: If I decide to store the information in a database and just send a mail when a new entry has been made, would this be better? And create some secure way to dump the information instead.
The best course of action would be to run the other way, fast. Redesign your application so that it doesn't enable identity theft.
You can use S/MIME or PGP to send secure email to most non-Web email clients, but it takes a lot of set up either way: the recipient has to have a certificate, and you have to get the right certificate for each recipient.
As an example of a better design, consider one where the recipient is mailed a notification, and then returns to the web site to view the information after authenticating securely over SSL.
While it helps to reduce the complexity of the system needed by the recipient, the bigger win is that it strengthens control over the distribution and retention of the sensitive information, and aids in auditing the access to that information. Sending someone an email makes it that much easier for them to store it unsafely, forever, or forward it to unauthorized recipients.
Encryption, Encryption, Encryption!!! Nothing else :)
Put the data into an encrypted attachment of the mail. The attachment can be any format you like. This will make parsing on the other side reliable. You can use any codec which ASP.NET supports, so you can choose anything that the other side can read.
Sadly, I don't think there is a practical solution for you here if you are taking about a mailto: URL.
The only secure way to send things over email is encryption. You can use PGP or S/MIME, but neither of those are easy to deploy for arbitrary users on web forms, since you can't easily set the user up with a PGP key or an X.509 certificate.
If you are deploying a web site from a hosted environment, it is possible that the code you control could encrypt the data and then send it. You could, for example, use GPG to encrypt with a public key of your own, and then send the results out in an email message. But that requires code, not just a mailto: url.
Unless you can find a public key encryption library in Javascript.
In short no. Email by default is un-protected. You use encryption programs to protect the information inside, but that requires the end user to be able to decrypt it.
The easiest way would probably be to create an ssl encrypted site where the user can log in and access the information.
You may want to look at http://ecocrypt.com/SecureMessage/
This will allow you to create an encrypted message that can be sent over standard email.
I think they have an API you can use for purchase/license( very low cost...)
But users can encrypt/decrypt in the cloud without having any set up requirements.
This will create a message like:
Encrypted Message Using http://ecocrypt.com/SecureMessage
To read this secure message do the following:
1. go to http://ecocrypt.com/SecureMessage:
2. Copy this ENTIRE message into the encrypted message area:
3. Enter the message pass phrase:
4. Press the Decrypt button:
NOTE: the message pass phrase was sent in a separate message, or the sender assumed you already have it.
NOTE: If you need or lost the pass phrase contact the sender at:test#ecocrypt.com
------------------HEAD--------------------------------
ECOCRYPT:67570:95992fad87a1165c100a0b915f86ce7f:
------------------START--------------------------------
GyuyjmHF68edfoSGM0YqtICXPrA6P69Pf7pXdgZ22g1PjzoANDOVy+0UJ/P0Pb+B09O+IsXqWPus
BO1gsVOA1BnMEE5r68A2fa02nRC9F3anVV8rvZDiZdfu9up2uDWrtsGhlLcHI6iKau4z7dAxq6qV
k7C/o2l3
------------------END--------------------------------
It can be decrypted if the user knows the correct pass phrase.
Same address in the cloud: http://ecocrypt.com/SecureMessage/
The message Decrypted:
Greetings,
This is a test Message.
Sensitive Information Goes Here:
name ss and other sensitive info.
Thanks.
I use Gmail SMTP which uses TLS. I'm not a .NET person but it's very easy to connect to through a Rails app for instance. And it's free!! Of course I think you only get about 200 msgs a month, but you can pay for more
If you have "control" of the receiver side (by this, I mean if the receiver is not a lambda user), I'll go for public/private key encryption with PGP. This article has a fully working example using GnuPG with .NET.
Let me rephrase the information flow to see if I got it right.
a) User U puts information into form at website W,
b) W then sends information to U via eMail.
That makes two communication processes that have to be protected. As you are only asking for protection of b) I assume you are already using TLS/SSL during a).
To protect b) you need some keys for encryption. I see two solutions: either some symmetrical secret that is exchanged during a) or some asymmetric public key that is exchanged during a). The latter one doesn't need any secrecy during a), which is an advantage, but you still need to authenticate that this key is indeed coming from U.
Both types of keys may be transferred during a), you probably just have to insert a new field into your form. In both cases U needs to have the necessary software to decipher any encrypted communication received in b). Having x509-Certificates or PGP-Keys as the two standard encryption algorithms these are probably the best guesses to start with. I am not sure how much is supported by ASP.NET, but even if I assume eMail encryption is not supported directly, some encryption should be supported.
Problem still is, that you will not find a solution that does not assumes some features of U's mailclient (above reading eMails, for some of us encryption is a fairly common feature).
Encrypted email - sounds like a great thing, right? Problem already solved, right? Well... I don't think so and I'm hoping I'm wrong!
To understand what I'm asking, please understand what I'm NOT asking: I am not asking how I encrypt and sign messages sent over public networks. This is a bit different.
I want to set up a mail server where email clients can both read and post and their messages to the mail server encrypted in both directions, preferably using standard clients available at internet cafes, etc, without requirement for specialized software or encrypted port-forwarding a-la SSH.
The key here is that there is a trusted mail server which can deliver email to a community using a local-delivery-agent. One can then send email to and receive from anyone and everyone who also uses that same system without concern for the security of their communications. There's no need to encrypt every message using the public key of every recipient - what pain THAT would be! - and instead all we're talking about here is a bidirectional communication that's encrypted from clients to this system.
Of course, public messages come in unencrypted via the usual port 25 process to all participants of the email server. They may or may not be encrypted as they were - we're not worried about them. Email Clients connect from anywhere and the responding code on the server system encrypts those messages for reading, even though they were sent through the public network in plain text already... This much I can already get fairly easily with encrypting IMAP servers like Dovecot.
What I want to add to this is that connected email clients can send email, encrypted, back to the system of which they are a client wherein that system forwards externally unencrypted, wherever it needs to go. If it's a local mailbox, the message is delivered via a local delivery agent. No keys involved there. The advantage of this design is that there's NO exposure of the email to external, untrusted systems or networks, and if the delivery is local, it's effectively protected end-to-end WITHOUT having a point-to-point hassle of encrypting individual messages in the more typical use.
This would be "god send" because as it is now, it's impossible to send secured mail through clients on the public internet to groups of people within an internal network.
I guess another way to phrase what I’m asking for is: Has someone created a package that gives us the other half of the encryption that IMAP (and POP?) servers already do – that distant clients on untrusted networks can hand-off out-bound unencrypted email through an encrypted link to the server on the other end?
ANOTHER ALTERNATIVE occurred to me: Encrypting SMTP / ESMTP servers that talk mail server to mail server in an encrypted form. (Similarly, clients should be able to hand off unencrypted email through an encrypted link, much as https works.) Anybody know of such a package? This is not quite as good, but an important part of email architecture...
If this doesn’t exist today, it should!
Thanks for your thoughts, pointers, etc.
Most existing email clients support message submission (either using SMTP or MSA) via TLS/SSL. I just checked in Outlook and Opera and both support it.
And I know for a fact that Courier's email suite supports TLS/SSL for both SMTP and MSA (and IMAP), so it's not an obscure setup; just a little uncommon. And it supports requiring TLS/SSL for any or all protocols.
Here is an example client SSL config screen.
Outlook Express: