We have a web app that is able to interact with users by email messages. So a user sends a email message to us then we identify user by from/sender fields from header.
But I detected headers fields can easy be spoofed!
Is it possible somehow exactly identify email of sender? Any ideas?
Thank you!
E-mail protocol doesn't provide security. There are no standard ways to protect the header fields.
A sender can attach some secret code on each letter but it's not e-mail protocol scope.
Related
I'm trying to implement List-unsubscribe. I have added a mailto: header but what's not clear to me is what e-mail is actually being sent when e.g. hotmail or gmail are sending an e-mail to this unsubscribe address.
Is it sending an e-mail with From: containing the e-mail address in question, or is it some hotmail/gmail service address?
Does anyone know a way to actually test it, since gmail and hotmail only activate this feature with highly trusted addresses (I've tried and it won't show).
http://download.microsoft.com/download/e/3/3/e3397e7c-17a6-497d-9693-78f80be272fb/enhance_deliver.pdf
This states:
- Include a List-Unsubscribe header
- Send an immediate confirmation message
I understand this as replying to the unsubscribe e-mail with a confirmation e-mail. Does anyone know if there should be any specific headers or contents in that message (e-mail)?
The unsubscribe should simply come from the address of the user who opted to unsubscribe. This is a very simple mechanism which should work with even extremely basic email clients.
The notation mailto:list-admin#example.net?subject=unsubscribe causes an email message with the Subject: header unsubscribe to be sent to list-admin#example.net.
There is an optional extension of the mailto: URI protocol specifier to allow you to put something in the body of the generated message, but this is less widely supported, and should not be relied on.
Maybe put a special unique identifier in the subject= field and set up the receiving server to handle that if these pedestrian facilities are insufficient for your needs.
If you are asking whether the confirmation message should follow any specific conventions, there's nothing beyond what you put in auto-generated confirmation messages in general. As a recipient, I would expect the unsubscribe confirmation to be pretty similar to the confirmation / welcome message when I originally signed up, only of course with the opposite contents.
What I am trying to do is, sending an email to one person but I want to add more email addresses in the TO field and don't want that users to get the email. Is it possible to somehow configure this?
Yes, this is completely possible. SMTP doesn't actually use the headers for anything; the envelope recipient list controls who actually receives a message (though many user-visible email programs will simply copy the To:, Cc:, and Bcc: headers into the envelope on submission).
Because you are not asking about any particular language, I won't post code which probably won't be useful to you anyway. In pseudocode, something like
s = smtp.connect(server)
s.ehlo()
s.from(envelope.sender)
for r in envelope.recipients:
s.rcpt(r)
s.data('''From: me#example.net
To: you#example.org
Subject: SMTP doesn't care
By the time SMTP transmits the actual message,
the recipient information has already been sent
separately.''')
I created an application which uses SendGrid's Inbound Parse Webhook. Whenever someone emails "whatever#mydomain.com", the email goes to SendGrid, and then SendGrid hits our server with a POST containing the email's contents. We can then feed that email data back into our main application.
I have it all working. But now I do not know how I am supposed to authenticate the messages SendGrid posts to our server. Does anyone know the best course of action for doing this? Verifying that our inbound emails actually come from authorized users of our main application?
Obviously we can check the "From" address in the headers, but I've read that these can be completely spoofed. Apparently "dkim" and "spf", two attributes of the incoming mail from SendGrid, have something to do with authorization. But i cannot find anything in the documentation, or really anywhere else for that matter, that tells me how I should be consuming these "dkim" and "spf" fields to verify message authenticity.
If anyone has any help, general, specific, or otherwise.. It would be greatly appreciated. Thanks in advance.
Well. Since this doesn't seem to be getting a lot of traction I thought I'd post my own janky-ass solution to the problem, on the off chance that anyone else runs across this issue in the future.
Disclaimer: this could be total garbage nonsense. But it appears to be working all right.
Basically I ended up taking some critical contextual information about the original message that initiated the inbound email. We encode that information in the local-part of the "Reply To" address that we set up with the SendGridMessage. Then I encrypt the encoded local-part.
When SendGrid POSTs to our server with the inbound email, we decrypt the "TO" local-part and validate the result. If it decrypts successfully, we check the "FROM", and verify that they are an actual authorized user of our main application. THEN, we verify that THAT user in question has the correct permissions to edit the information associated with the original encoded local-part of the "Reply To".
A forum-like app I'm working on will send an email notification to the thread starter when a new replied is received. It would be nice if the owner can just reply the email to add a new reply to the thread.
How can I implement the feature, i.e. "reply to this email to comment" like Facebook?
Option A: scan the subject line/body? I don't like it 'cause what if the user modified the subject line by mistake?
Option B: use a unique reply-to e-mail address that links to the thread ID. Is this a common function for mail server? like set up a *#addComment.domain.com ? Or does the app server needs to setup a new email account before sending the email with reply-to?
Any other options?
Thanks!
Using strings in the subject and body can be easily erased by a user of the system.
Use plus addressing (reply+UNIQUEIDENTIFIER#yourapplication.com) as the REPLY-TO address in the mail message. With CFIMAP you can retrieve the messages and parse the TO.
Wildcard domain (replyto#UNIQUEIDENTIFIER.yourapplication.com) is also an option, but if your email server supports plus addressing I would go that route.
You could stuff the thread ID or the parent message ID (the message that is being replied to) in the Msgessage-ID: header of the email, or a custom email header, and put the processing after accepting the message.
However, using custom Reply-To: addresses is quite common.
an option is to embed an identifier in both the subject and the body of the original email. something small, like bit.ly's 6-8 character code. that way, they're less likely to mess it up, and you have the safety of the email body, which most people leave in anyway.
Using a custom email header is not advised as there is no guarantee that any server along the route would not strip it off (or simply fail to pass it on). A friend who worked at a huge email data center for AT&T said the techs there warned him off that idea.
This may also be true of the Message-ID: -- don't know.
I've got a web app which I'm sending emails from. I want the emails to appear to come from users of the system, but guessing that these will appear as spoofed emails as they aren't coming from where they are saying they come from.
I've looked around and it appears that the SENDER header fits the bill. Is this a good solution? Also which way round should it be used? SENDER is the users email? or SENDER is the an email address from the domain I'm sending from?
Thanks in advance
Dave
Who is doing the sending of the emails? From your description I would guess that some action of a user triggers sending an email. In that case, the user's email address belongs in the From header, and in any case, an email address for your web app should be in the Sender header because that is doing the actual sending of the email.
Of course, this is how it ideally works. I have encountered broken email programs that actually use the Sender header for replies if that is present instead of From, so if the receivers of the emails start replying to you, you will probably need to reconsider, but for now go with the "correct" approach.