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.
Related
I have a community where users can send emails to each other and/or multiple users.
Problem: I often get the feedback that emails are being received, not even in the Spam folder.
Currently I do the following:
From: noreply#mydomain.com
To: recipient#gmx.com
Reply-to: sender#yahoo.com
The problem is that I see from bounces that emails are rejected because the "From" and "Reply-to" do not match.
What I tried?
Putting the original sender address "sender#yahoo.com" in the "From" field. Result: Even more emails get rejected by the servers, because I am not allowed to send emails on behalf of this user (I totally understand that behaviour from the mail-servers)
Removing the "Reply-to" Header. Result: Users click on reply and send answers to "noreply#mydomain.com" and they never get to the intended recipient.
What I plan to do?
Next idea that I have is to send emails from #mail.mydomain.com and have a individual user hash for each sender. e.g.:
From: h7ga310acc8de509a7d884ab#mail.mydomain.com
To: recipient#gmx.com
When the recipient hits the reply button and replies to h7ga310acc8de509a7d884ab#mail.mydomain.com, then I need to send a new email with the content of that email to sender#yahoo.com, if this was the user assigned to h7ga310acc8de509a7d884ab#mail.mydomain.com
My questions:
Is this a "Best practice" or are there better solutions?
Are there any tools/libraries (preferrably in typescript) which would help me to do this last step of email forwarding to the original sender
Thanks a lot for all kind of feedback, thoughts, links to helpful pages, etc.
I've implemented List-Unsubscribe (RFC 2369) for marketing emails we send. I am providing both an unsubscribe email address and an unsubscribe URL. An example of a generated header looks like this:
List-Unsubscribe: <mailto:unsubscribe#myserver.com?subject=unsubscribe>, <https://myserver.com/unsubscribe?email=recipient#email.com>
In the past few email campaigns we've done, it has worked great. There's only one problem. Sometimes we receive unsubscribe requests from email addresses we didn't actually send mail to. I think this happens when the user has multiple email addresses and the email we send is forwarded to some other destination. So we send to user-a#email.com, but the recipient opens it at user-b#email.com. When they click the "Unsubscribe" link provided by their email client, it generates an email to us telling us to unsubscribe user-b#email.com.
Sometimes we can find the intended address if the address we sent to was very similar, or if the user has a unique name, but sometimes it's impossible to determine which email address we should unsubscribe. That's frustrating because we know the user will be upset if they receive another email from us in the future.
I tried to fix this by adding a unique identifier to the subject line, so that a subject looks like unsubscribe_20934832034820348, but when we do that, email clients stop showing the Unsubscribe button. It's as if they will only show the Unsubscribe button if the subject line is exactly "unsubscribe".
I didn't see anything in the RFC about the subject line needing to take a particular form, and we are also taking care not to put the user's email address directly in the subject line. (It is a hashed combination of their email address and a portion of the original message, making it unique across all emails we send.)
Is there some sort of convention around this? If so, how can I reliably determine the original address we sent to when we receive unsubscribe emails?
It looks like there is no problem using this sort of subject line. However, it seems that each email client decides in its own proprietary way when and how to display the Unsubscribe button/link, and it does seem that that when you change from a simple "unsubscribe" to "unsubscribe" plus some unique identifier, some clients might subject you to some sort of test period before showing the link to users. In my testing, Gmail did not show me the link when sending small batches of test emails, but after I sent a large batch of emails, the link did start appearing, and I did indeed receive the generated unsubscribe mails properly.
I hope this helps someone out there.
Trying to get a list of my email recipients who have seen my email, and then to use a different medium to address who didn't see (via SMS/Call).
I could get the number of people who saw the email by having a hit counter set up in a web server, looking for a method to get this done now. Any help?
Thanks.
It can't be done reliably. Popular email clients will not do anything to alert the sender that an email was received because this allows spammers to detect if the email address is valid. That's why most email clients block remote images until the user clicks "Show Images" because the images could be used for this purpose.
Email system support something called a "read receipt" that is intended for this use but most clients will never send one.
You can detect if an email bounces but receiving an email and viewing an email are two different things.
I'm creating an email a friend type system where I need our mail server to send emails from the user of the site to their friend, i.e. from fred#gmail.com, to tony#gmail.com.
If, as is the case in this example, the user's are both part of Gmail the friend would receive an email with the warning "This message may not have been sent by: fred#gmail.com.
I thought that by then adding a 'sender' header with our email (e.g. us#company.com) this should indicate to Gmail that we are the sender and are effectively openly spoofing the sender at their request. Is this true, can you get around Gmail's warning using the 'sender' header?
I realise this is similar to the following question but I'm more interested in whether the sender header should have an effect: Email sent from web server causes gmail to treat as phishing. How to get rid of this?
More info:
I'm using netmailbot to send emails from our mail server using the '-customheader' parameter with 'sender' and 'x-sender' e.g. '-customheader sender:us#company.com x-sender:us#company.com'
If gmail doesn't fail miserably, you have no way to suppress this warning.
Google is in control of both accounts and therefore knows, that this mail wasn't send by fred using their infrastructure.
There was used some third party infrastructure (yours) and this is all this warning is about.
You can set an arbitrary email address as "from" and Google has no knowledge if this is legitimate use (if fred really wrote the message). Anyone could have written that message. Normally fred would use Googles infrastructure to send mails and then they would know its him.
A cleaner solution would be to put your email address ("noreply#company.com") as from header (that would be honest) and set fred#gmail.com as reply-to header (so he gets the replies).
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.