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.
Related
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.
Part of our product involves sending users a weekly email with a status report about their account, and once in a while we get the following reply from their spam filtering service saying the following:
LSMSGCV: You just sent an email to foo#bar.com - please reply
Did you send an email to: foo#bar.com from: foo2#bar.com?
If yes, it got caught as unsolicited email by our spam blocker. You can release the mail from spam quarantine by simply replying to this message. At the same time the spam blocker will recognize you as a trusted sender (from this email address) and automatically add you to my Allow list for this and any future communication.
Many illegal spammers forge email addresses to try to get past spam blocking software. These spammers send hundreds of millions of spam messages a day, clogging email servers and wasting people’s time. We regret that these spammers have forced us to send this message to you.
Original From: foo2#bar.com
Original To: foo#bar.com
LSMSGCV For more information about our spam blocking software please visit www.lightspeedsystems.com
The problem is that our from email address is not a real inbox, it's actually a google group (set up through google apps) that we use to make sure everybody who needs to can receive the reply to this email and answer from their personal company accounts.
For LSMSGCV, does it matter if the "unblocking" reply comes NOT from the original from address? Would that successfully whitelist our from address or would that be insufficient?
Let say I have a website that allows users to send articles on that website to a friend.
The way it works is that when the "send to a friend" link is clicked a form appears and it allows users to fill in the details and an email is sent to their friend.
The user can put in a "from" email address and a "to" email address into this form and a small amount of content.
When the email is received the from email address appears in the FROM and REPLY TO.
This website also sends a great deal of its own email communications to its users.
My question is:
Is there risk to allowing users (bots, attacks etc) to use this application to send emails from my SMTP, and how great is the risk?
My assumption is yes, this is not ideal.
Is it possibly worse than "not ideal"?
I do not know about bots using your form. Should it be a problem? I don't know.. I do know they program bots to be pretty clever, using your custom forms and all.
I do know that some email servers check if the FROM email address has the same IP address as the IP the mail was sent from. So imagine I put in my hotmail email address, and the mail server sees your server, it might flag the email as spam.
In the past I've an e-card websystem. It was a small joint venture with a girl I knew. She created the (cute) cards and I build her an e-card system. The website was pretty simple. Select card, enter email address, placing senders email address in the FROM and sent the email that you would have received an e-card.
Life was good...
Until I found that my entire web server IP was blacklisted at three major spam filtering mechanisms. And that 15% of all email recipients who used to receive e-cards from my site, would not receive their e-cards, because all my emails were blacklisted as spam from the get go. We have receive many many emails from angry "customers" demanding that their e-cards did not arrive. (I still find it funny how some people demanded the service, especially since it was a free service, go figure). My automatic reminder function was telling them the e-card still were not viewed, and they perhaps mistyped the email address, so that might have ticked them off :P
It was pretty annoying for my other customers as well, since they relied on sending out played newsletters and such and calling me that over 20% of the customers did not receive the newsletters.
Sending e-mails is hard. You should also check out Jeff's blog about this. So, learn from my mistake, and please put an email address associated with your email server in the FROM. This will spare you a lot of headaches ;)
yes this is definitely not ideal if this is a public website that any bot can access. but there are easy ways for you to limit spam use.
have your code limit any email
address to send ~50 emails a day and
only ~10 an hour based on your
needs. a bot would probably try to
send a million at once so limit them
on an hourly and daily basis.
store every email communication in a
database and come up with a good
program to monitor the most active
email senders. if you can verify
that an email is trusted, then let
them send as many emails as they
want
think about this site itself, it has very defined actions and reputation guidelines that limit you until you have proved you are trusted.
It may depend on whether you do any authentication to determine who's allowed to send emails. If the user has to be logged in to send articles, then you're probably fine. Bots will fail because they'll never be logged in.
The risk will increase the greater traffic you get to your site, and yes it's probably less than ideal. Unprotected, a bot will inevitably find your unprotected form, and start sending emails from your server.
There are some pretty easy solutions though, the most common probably being to implement something like Captcha
Fairly safe. I assume you do check the "From" address, if only by sending it one (standard!) mail first and asking the owner of that email address to confirm they are really humans ? This prevents most bots from finding and abusing your form. Of course, a directed attack with a human responding to your verification email will still allow spamming. But you've got a much better trail if you have received at least one reply from the alleged "From" address.
However, I don't think this will work reliably. The introduction of techniques like SPF will mean that mails from "example.com" will only be accepted if they originate from an outgoing SMTP server in the *.example.com domain. If you're faking emails with From: addresses #example.com, the receiving SMTP server will see that you are in fact not part of *.example.com and reject the email - and probably blacklist your IP range for good measure.
My application server needs to notify users about some events via email. Usually there will be between 10-100 users to whom the notifications should be sent, but there may be a few cases where there may be a bit more (I don't think it will ever be more than 1000).
What is the best practice in such cases? Should I send a single email per user or one email with all users as recipients or group users and send one email for each group (for example 1 email for 10 users)? If it makes any difference I may add that I am using System.Net.Mail to send emails.
Thanks in advance for your suggestions
Lukasz Glaz
You should send one e-mail per user.
The alternatives either involve putting e-mails in BCC (which will increase your chances of having your mails flagged as spam), or revealing your user A's e-mail address to user B, where user A and user B are in the same "group".
You need to check with your smtp server manager - to avoid being blocked.
if you own the smtp server, than this is not a problem.
I think the best way is to send them in bulks of 50 recipients per message (it will be a little faster than one by one).
I wouldn't definetly put all recipients into a To: field. Even from one place. It's just not a good practice to show other's addresses. And it generates a problem when someone hits "Reply All" and suddenly mails all others with his crap :)
If you own the smtp server, and your application server -> smtp server connection isn't slow, I would just send every mail individually, with each single recipient in To: field. It just looks much less spam'ish then getting a mail with empty (or some bogus) To: field and being in BCC only.
Other advantage is the person recieving your mail will know what email address is used. I got plenty of them, use different ones in different places, and it helps to be able to see which one I used on which site (sometimes I need to use this address for password reset / login, and I forgot, and if all mails had me in BCC, I'm screwed). This is from your user's perspective.
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.