Use site name in From: header for system e-mails

D6 uses the new function system_site_information_settings_validate, and specifically user_validate_mail to check the site_mail field, which in turns uses common.inc's valid_email function. So, there are three different ways of solving this problem, without adding a new field (and as such having to change even more code for mailing).

1) Modifiy system_site_information_settings_validate in system.admin.inc to execute a regex and split the string based on finding , and only validate the second portion which is the actual e-mail address.

2) Modify user_validate_mail to do the same stripping as above.

3) Modify the core valid_email function (not recommended, as this could have many ramifications).

Even though this was a "feature" in D5, I don't believe that it's a bug just because it's not in D6.

I'm changing the component to point the appropriate place and will leave it as a bug report until discussion can take place on whether this is a bug or a request.

This is not just a "nice to have" feature but a serious bug, as emails w/o sender name are often penalized by raising the SPAM index value, AFAIK.
To make this implicit D5-feature explicit, I'd prefer adding a separate name field to the form. We'll have to add or change one or two strings anyway. The fact that adding a string is the lesser crime during string freeze, would be an additional argument for a separate field.
Some response would be great before any work is done on this.

Shold we follow RFC 2822 and match mailbox definition?:
http://www.faqs.org/rfcs/rfc2822.html

Note that a mailbox is composed of mailbox    =   name-addr / addr-spec

Agree with Arancaytar,
The document defines an address as:

address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
display-name = phrase

So the sender field can be : phrase "<" addr-spec ">".

I vote for modifing the core function.

This patch modifies the core function valid_email_address to adapt it to the spec. The optional new format is:
"display name" <user@domain>, the old format, without the first part, is still valid.

Extensive testing is needed.

Why do you need to use entities in this validation - has the input already been through check_plain?

Oh, so you actually have to *enter* "Name" <mail@mail>. Well... inconvenient, but I suppose that's better than nothing. Perhaps this could be improved in a later patch.

This is the exact content that gets passed to the PHP mail() function as its fourth (mime-headers) parameter:

Somewhere along the line, it ends up as above. My guess is that the entities aren't working out...

@Arancaytar: Thanks!

I've tried to break it on all forms that a valid email is involved but I couldn't and the regex added is optional.
The angle address works ok for me, so I'm attaching #9 again with a comment about the two valid formats.

No, this addresses are not valid, the trick here is the code:
$angle = '(?(1)>)';
Is a conditional regex that *only* is validated when the (1) regex has been tested and is TRUE.

The (1) regex is the display name part including the white space and the first angle:
$name = '((?:"[^\"\f\n\r\t\v]+" <))?';
Here, we specifically look for quotes surrounding a phrase (one or more words, no control characters), but this is all optional so it can be FALSE, when not valid or nothing. Then $angle only is active whe this is TRUE.

Looks like this is a feature addition (in email validation) and also an API break since those expecting that their validation is done on an email *address* will get names sneaking in where they don't want it (like on the user account email field).

Ok, so this should be divided:
a) A feature request to include the validation on the core function: http://drupal.org/node/214114.
b) A patch to modify 'system_site_information_settings' function because this is the part affected by the issue.

This patch looks if there is a display name inside the mail parameter and extracts the address part to pass it to validation.

$allow_name implemented.

As site-info uses user_validate_email for generating the appropriate form errors, user_validate_email takes the $allow_name = FALSE argument and passes it on to valid_email_address.

NOTE - this patch is racing against another one that fixes the "trailing period in hostname" bug. Both patches change the same lines of common.inc, and the losing patch will require a (mostly trivial) conflict-resolving re-roll.

I've tested this patch and it appears to work. I can now enter e-mail addresses with a sender name, a-la Drupal 5.x.
I also tried several almost-correct addresses with sender names and they were all flagged as errors. So I think what's there is good to go.

I think the use of extra variables in the functions and the defaults chosen should prevent any breaks to existing code.

My only concern is whether there are more places where support for a sender name could be enabled. I don't feel I can comment on the entire code base. Perhaps someone else ...

Possible follow-up issue: The installer "recommends" using the same address for site contact and the root user. Javascript code copies the form value from one email field to the other automatically.

With this patch, the site contact address will allow values that a user address does not. It is usually a reasonable expectation that the suggested defaults actually pass validation.

However, that shouldn't be a show-stopper, because it's pretty clear to the user what is happening, and if they know what they're doing when they add a name to the first field, they should also know that the second field may not have a name.

Hm. Okay. Of course, if we had known this two weeks ago, we could have spent more time on critical issues instead of implementing the $allow_name argument to get this into 6.x... ;)

In D6, I'd rather use the site name as name and site email as email in the outgoing mail, if you insist on having a name by default. Checking the format of an email input field is IMHO an improvement not a bad thing to have.

Note: I don't know what characters the site name allows, and if it potentially needs to be check_plained or otherwise filtered before conforming to RFC 2822.

Anyone know what happened here? Thanks!

Subscribing.

This issue is one major release old and needs to be moved up.

Incidentally, on giving this some more thought I am wondering if it might not make more sense to drop support for this completely. Instead of allowing the email address to contain a specific name, just format outgoing From headers as "$site_name" <$site_mail>

I'm not 100% either.

patch (#9) is working fine... i mean email field is accespting both name & mail address.... but while sending a mail from that mail address its giving problem like this

warning: mail() [function.mail]: SMTP server response: 501 5.5.4 Invalid Address in C:\wamp\www\drupal-6.11\includes\mail.inc on line 193.
Unable to send e-mail. Please contact the site administrator if the problem persists.

@GregoryHeller You could also create a custom module and do a hook_mail_alter

This needs to stay at 7.x and back ported from there.

The custom module in #47 is a good approach and works well for me. I do feel that this feature should be in core though.

I meant "Site name" <site mail> in #52 :)

Re-test of valid_email_1.patch from comment #10 was requested by lot007.

+1

#52: nice_from_header.patch queued for re-testing.

If site_name contains 8bit characters, the From header line becomes From: =?UTF-8?B?InTDqXN0IiA8Zm9vQGV4YW1wbGUuY29tPg==?=. My mail server changes this to From: =?UTF-8?B?InTDqXN0IiA8Zm9vQGV4YW1wbGUuY29tPg==?=@mail.example.org, and my mail client displays it as “tést @mail.example.org”.

Subcribing

For now, it looks like the Personalized E-mails module will address this for D6.

My solution to this problem is I was already using the Mime Module and by changing the site email in it's settings page to something like "Site Name" it bypasses the normal validation and also updates the email in the site settings page. I don't even have to have "send html emails" turned on in mime mail's settings, as long as the module is installed.

Mime Module did not work for me. Any other solutions?

Subscribe

I just tested PMail. It works. Didn't even have to configure the module!

I'm confused how such a seemingly simple D6 issue can remain open for over 3 years, and in the meantime get reassigned to 2 versions after the original?! Providing the site name in the From header is basic core functionality. It shouldn't require the addition of a contrib module to fix.

Re-rolled against 8.x using current patch standards.

The last submitted patch, drupal_mail-209672-79.patch, failed testing.

d8 patch still applies.

Rolled d7 and d6 versions.

Note that this fixes a regression of functionality available in d5 (!!!), hence the backports.

The last submitted patch, drupal_mail-209672-84.patch, failed testing.

#86: drupal_mail-209672-86.patch queued for re-testing.

#86 still applies cleanly to 8.x. I think it just needs to be reviewed or is there another reason this issue has stagnated?

#86: drupal_mail-209672-86.patch queued for re-testing.

Please read and understand the backport policy before changing the version, or assigning yourself to an issue. Thank you.

This issue has been stalled for five months while awaiting a review of the patch in #86.

If nobody is willing to provide such a review (and RTBC), this issue should be closed (won't fix).

Just go for mimemail projet http://drupal.org/project/mimemail