Sending emails with Reply-To

[Baptiste Darthenay]

I would like to pass a Reply-To in the email.

Use case: I need to set the reply-to with a generated email address which will be hooked by the email service (MailChimp, SendGrid, Mailgun, Sparkpost…), so when users hit the Reply button on their email client, it doesn't go to the default from email, but would actually create a new message.

It would be nice if we could pass a function with the sender.

[Patrick Samson]

There are two reasons to send an email:

1. inform a visitor (it's the only way)
2. inform a User, as a fallback when there is no notifier app

The feature was designed as a notification means, not to engage a further exchange.

If I understand your use case, a Reply-to would only make sense for a visitor and in the case of a response delivery (not for a deposit rejection).

My proposal is:

• a new setting

def get_params_email(context):
    # context is the same as for the subject/body templates:
    # {'site': ..., 'object': ..., 'action': ...}
    # return a dictionary of EmailMessage parameters (or empty).
    # In case of django-mailer (v1.2.2), only 'headers' is supported and
    # to the condition that a HTML-version email template is involved.
    return {
        'reply_to': ['[e-mail]'],
        'headers': {'X-my-choice': 'my-value'}
    }
POSTMAN_PARAMS_EMAIL = get_params_email  # default is None

• It will be used in case 1 only
• You should restrict the return of parameters to the condition: if context['action'] == 'acceptance'. It could be filtered upstream by the app but I prefer to leave the opportunity to add headers even in the case of a rejection (suppose a 'bcc' for example).

Notes:

• 'reply_to' is available as of Django 1.8. For previous versions, you can embed it under 'headers' as: {'Reply-To': '[e-mail]'}.

[Baptiste Darthenay]

· It will be used in case 1 only

Could you precise which case exactly?

In my use case, anonymous users don’t use the postman messaging app.

[Patrick Samson]

"case 1" refers to the first of the two cases in the beginning of my first comment. If it isn't your use case, then I don't understand it. Would it mean that a User replies to a notification email just saying "you have receive a message"? It doesn't make sense.

[Baptiste Darthenay]

I don't assume the users go often to the site, so notification emails are the biggest interaction with our website. When a message is sent to another user, they can read the content of the message, and they can see big action button "Reply to the message" that links to website postman. However, a non negligible amount of users won't click on this link button, and just press Reply on their gmail or whatever. So we, administrators, get 1-2 messages per day from users who thought the replied to their recipient.

So the first step is #93, force this amount of users to reply to a no-reply address, then they get a Delivery Error. This way we don't have to deal with these misdirections. But it's not user friendly.

The second step would be this one, when a user hit Reply, it will send a email to a unique generated address, which will be captured by Mandrill/SendGrid/SparkPost which will fire a POST request on our website with the parsed reply message. Then we create a Postman message, and hopefully, if the API permit it, send a notification email, with a custom Reply-To.

[Patrick Samson]

It's clearer, the missing point was that you provide the message body in the notification email, so going to the site is not mandatory and the temptation of a direct reply is high.

Here is a revised proposal:

• The restriction to a visitor context is withdrawn.

About your hook to process the reply, would it be?

1. A new Postman message, unrelated to the first one, so not really a reply.
2. A real reply, bound to the first one in a conversation.

In case 2, then:

• The generated address should not derived from the sender only, more probably from the message ID.
• Currently the API has a pm_write() function but nothing dedicated to a reply message. Nothing prevents you to compose a Message() with well tuned fields but it may be tricky to ensure consistency in all cases.

In all cases, don't forget to think about the security and protect yourself against forged addresses that could spam any User.

[Patrick Samson]

Fixed in repository.