More flexible message headers

This looks really like something we'd like to have. However, as this is not only about email, but also sms, im, etc, we need to architect some better solution here.

The messaging module already supports some mail specific features, and the notifications part already can pass on the 'sender_account' plus we have some hook_message_alter().

So I'll be thinking of some better solution for the messaging layer, but in the meanwhile that feature can be implemented using already existing hooks.

Attached the current Notifications options, that I think should be enough at that level

References:
messaging_mail_headers()
hook_message_alter(), from messaging_message_send()
Mail2web module, http://drupal.org/project/mail2web

Hi,
I´m using latest stable releases from OG and this module (2.x versions).
And I cannot get neither of those things that you´ve said:
Broadcast messages won´t be sended with this from: @user_name <@site_mail>
Nor the attachment notifications option would work (I´ve set it exactly as the screenshot), the broadcasting emails will be send as from the site´s email address.
Maybe I´m doing something wrong?
Thanks for your help!
Rosamunda

Sorry, didn´t saw this issue post whith the info about this bug

I think this issue http://drupal.org/node/463796 concerning a request for realname support in email from address could be easily incorporated here and should be. To me it seems we should go the route of making the usual message part for 'from' and providing standard defaults per send method and all the relevant tokens if they don't exists already. The handling code for when notifications talks to messaging might have to change a bit to incorporate that and send on the from information. Check http://drupal.org/node/371596 for an easy example in the patch of sending on additional info to messaging. I could get on this and/or the attachments issue.

David

Also, perhaps we should incorporate flexible To fields in this as well. Maybe make just one part called "Addresses" or something, and each line would be parsed depending on which method it applies to--Mail method might look for from then to then bcc etc, others for just from and to, etc... See http://drupal.org/node/463098. This is just a thought and would need to be reviewed, specced out a bit.

David

I'm making this critical because at least two other requests could be remedied by a sufficiently robust solution to this one and should be postponed pending a resolution here.

David

Looks like a great idea! I think this would be a huge boon for Notifications, and looks like a very elegant / extensible way of solving several other issues.

I agree that being able to configure the "from" and "to" addresses for each sending method using Tokens would be a great idea. I'm thinking this should be implemented at admin/messaging/template or admin/messaging/settings/method. Also, just to be clear, we are talking about using actual Tokens here, correct? (rather than our own implementation of "tokens")

I'm not clear on how configuring sending options such as BCC and CC recipients would play into this. I feel like that is still a separate issue. David, can you give us a clearer idea of how you think this should be incorporated?

Would this be something better implemented in the Notifications Add-ons package? Perhaps as a notifications_address or messaging_headers module?

Actually "tokenizing" the from headers turned out to be fairly trivial to implement for mail methods by simply modifying messaging_mail_prepare and adding a couple of options to admin/messaging/settings/overview. This code probably isn't perfect but works fine.

If we take this approach, do we even need to have the "Notifications sender" option at admin/messaging/notifications? Right now I think that will override any tokens you use to configure the mail headers, which is somewhat non-intuitive and redundant if we allow headers to be customized for each method.

Adding options to modify the sender (i.e. to add the sender's name) will not be quite as easy and will need to be implemented here as well as in each individual sending method I think.

Gonna test it... THANKS!

Whoops... small typo.

I am noticing some strange behaviour that may or may not be related to this patch. Let me know if you see anything like this or know what it might be. I can't reproduce it or discern any pattern, but every now and then I get an email with the following header:
Joe Schmo <Joe Schmoe <">"@siteaddress.example.com> when it should obviously be Joe Schmoe <joeschmoe@example.org>

Ah, figured it out- I was feeding it the tokens for the currently logged-in user rather than for the node author. Silly me :)

This patch fixes that, plus is a bit tidier and fixes another minor bug.

If this looks like a good solution to people, I can work on polishing it up and getting it ready for committing.

This looks good. Moving to Messaging.

I think this should be a pair variables, one for 'user mails', one more for 'site mails' both like: [user] <[mail]>

I'm going to release a new version this week, will consider this for the beginning of the next release cycle, so it can be tested properly.

Subscribing.

This has been working beautifully on our site for some time now, can we go ahead and get it committed to 2.x so we can focus on getting it ported to 4.x?

It would probably help if someone could verify that patch and bump this to "reviewed and tested"...

This has been fixed in 2.x but needs to be ported to 4.x

Added these features and #542022: Set correct Return-Path

I've done a simplified (just two tokens) more consistent settings: New tab for mail settings, renamed variables to 'messaging_mail_*'

How far away is this?
Would it make sense to implement an intermediate solution that just allows to set one "from" email address for all notifications (to replace the site default), and do the rest in a later step?
I imagine a lot of people are waiting for this, and the simple intermediate solution would make most of them much happier already.

This is also necessary for compatibility with Mail Comment / Mailflow 2.x - otherwise replies go to the sender rather than the site.

Ah- I see that this has been committed in 4.x, but it has been modified to only apply to the MIME sending method :/ Can it be generalized to work with all mail-based sending methods, or at least copied for PHP Mailer?

Oh now that's just confusing- apparently this is already completely ported and working in 4.x. It appears that PHPMailer inherits Simple Mail settings, so when you set the header format at admin/messaging/settings/method/mail it will also affect PHPMailer (and presumably any other email-based methods).

That's fine and all, but there should probably be a warning on the page that settings will affect all mail-based sending methods, as well as a notice on the PHPMailer config page that the sender format can be configured at admin/messaging/settings/method/mail.

Subscribing...

Here's a patch that simply adds help text to clear up this confusion.

Patch looks good to me.

Heh... apparently I still have commit access. Awesome.