1

We want to send emails through our webapp. Users of the app provide their email adresses. In some cases, we want to send transactional email from the webapp, using the current user as a sender.

Does using the User's name and email adress in the email from header affect email deliverability reputation? Are there any other (bad) consquences, we should be aware of?

adding details about the use case:

  • Say PersonA uses our app on myapp.com
  • PersonA verified his email adress personA@example.com with a confirmation email we send him (he clicked a unique url in the email he got).
  • Using the app, PersonA can invite other people to do something (attend an event for example)
  • If PersonA invites PersonB we want to send an email, to let PersonB know that he has been invited. To do so, we would like to send an email from personA@example.com to PersonB.
  • Having a sender header with myapp.com is totally fine. But PersonB should see see "PersonA ".

We are not going to send hundreds of emails like that. But we would like to create some trust when PersonB sees, that his good old friend PersonA invited him, not a stupid "notification@myapp.com" he never heard about.

Nils Blum-Oeste
  • 113
  • 5
  • 1
    Can you clarify the nature of the application? i.e., when it will send messages of this nature? You're going to (continue to) get a great deal of feedback about being a potential relay for spammers unless you make it clear that this problem is not a part of your design. – Andrew B Jan 18 '13 at 09:10

3 Answers3

6

You would be opening a whole can of worms if you do not authenticate the email address first.

This would allow users to send emails with any from address. If you get each user to authenticate the email address they want to use, i.e. send an email to the address they specify, and get them to provide information in that email (which should be unique) or click on a unique link.

After an email has been authenticated, you know that they have (or at least had) access to that email account. It is now safer to send emails as that user.

However, this will still cause issues under specific circumstances. If the users domain has SPF enabled (SPF checks that only certain ip's send emails for that domain), it is likely that emails will be tagged as spam ( at least for that users with domains that use SPF).

This may increase the overall spam "rating" of your server with specific servers under specific circumstances. It is possible to alleviate this in various ways but that is a fair bit of work.

Unless there is a really good reason to have the emails show up as from a user, it would be better to not do that.

There is an option to use the "Sender: " header which may resolve this issue for you. https://stackoverflow.com/questions/4367358/whats-the-difference-between-sender-from-and-return-path provides a good example.

I, however, have no experience with this or its impact on messages or servers being tagged as spam.

Community
  • 1
drone.ah
  • 482
  • 2
  • 6
  • I work at SendGrid and I would say this is the best answer here. +1 on @Shri's sentiments. – Swift Jan 18 '13 at 19:40
  • Regarding the `sender` header and the post you linked to: From what I understand, I should set `sender=foo@myapp.com` and `from=personA@example.com`. Is that right and would that prevent us from being marked as spam via SPF checks? – Nils Blum-Oeste Jan 21 '13 at 13:19
  • 1
    yes, that is correct. I do not believe it would stop it from being marked as spam though it should decrease the chances of it being marked as spam. – drone.ah Jan 22 '13 at 11:33
2

Apart from the deliverability issue, the main problem to consider is that if you make it possible for internet users to send emails through your server, you run the risk of a spammer using the server to spam.

Jenny D
  • 27,780
  • 21
  • 75
  • 114
1

Definitely. If you're using it as the envelope sender, yes.

The server which transmits the messages will not have a reverse DNS entry (PTR record) for its IP address that can be identified with the domain of the sender. This is before additional precautions such as SPF records and domain keys come into play. From the perspective of the rest of the internet, you are forging e-mail from the user, which is accurate.

You can get away with something like this when writing an application that is used internally by your company, provided that your company hosts the e-mail domains in question (or the messages are not leaving your internal network), but in this particular case your messages are almost certain to be treated as forgeries/spam.

Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • 3
    The envelope sender doesn't need to be the user's address; it can still belong to the actual server, avoiding this issue. However, that opens a can of worms in dealing with failed messages. – Jenny D Jan 18 '13 at 09:02
  • @Jenny Accurate point, thank you. I really shouldn't compose answers right before bed. :) – Andrew B Jan 18 '13 at 09:03