[wp-trac] [WordPress Trac] #14888: PHPMailer class uses wrong/no sender for mail envelope

WordPress Trac noreply at wordpress.org
Thu Oct 18 20:18:13 UTC 2012


#14888: PHPMailer class uses wrong/no sender for mail envelope
-----------------------------------------+-----------------------------
 Reporter:  gkusardi                     |       Owner:
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Future Release
Component:  External Libraries           |     Version:  3.0
 Severity:  normal                       |  Resolution:
 Keywords:  reporter-feedback has-patch  |
-----------------------------------------+-----------------------------

Comment (by tigertech):

 Replying to [comment:19 Whissi]:

 > @ tigertech: If you would still vote against such a feature, could you
 please explain why?

 I still disagree with the fundamental premise that it might sometimes be
 okay to send mail from a "foreign" domain name that you don't control the
 DNS records for.

 The argument seems to be that SPF, DKIM, SpamAssassin source rules, etc.
 are things that some people care about, but that other people might simply
 choose to ignore -- that it's a policy decision made by the recipient's
 mail server administrator. While that's literally true, this discussion is
 about the problems this proposed feature might cause for the sender and
 end recipient, who almost certainly have no idea what that policy is.

 You used "foo[@]gmail.com" as an example of an address that a WordPress
 user might think they "own" and is therefore reasonable to use. But look
 at what Google says will happen if someone does that:

 http://support.google.com/mail/bin/static.py?hl=en&page=ts.cs&ts=2411000&rd=1

 So Google's opinion is that "All mail sent from Gmail [addresses] should
 have authentication data in the message that can verify it was sent
 through Gmail". They don't want people sending foo[@]gmail.com mail from
 other servers, and they think it should be flagged as potential phishing.

 Worse, if you're using a decent hosting company that has anti-spam
 protection on the outgoing end, the mail won't ever leave their servers in
 the first place. My company simply doesn't allow scripts to send mail
 from, say, foo[@]gmail.com. (The script can authenticate against the gmail
 SMTP servers if they really need to do that.) Thus, our busy mail servers
 almost never send any phishing mail. This is so clearly a Good Thing that
 eventually almost every company will block outgoing mail from foreign
 domain names. (In case you're thinking that our customers complain about
 this restriction, they almost never do, but we get lots of "thank God I
 switched to you; your outgoing SMTP servers are never blacklisted like my
 old hosting company".)

 The average WordPress user will not understand any of this. Adding this
 proposed feature would make more mail get flagged or bounce, and and
 adding complexity that (on average) causes more problems for users is
 Wrong.


 > I mean, setting it via .user.php/PHP configuration or WordPress
 configuration, what makes the different?

 You're saying "since people can break their WordPress installation by
 entering invalid values in php.ini, there's no extra harm in giving them a
 box in WordPress that they can enter the same invalid values into".

 I disagree with that, though. To me, php.ini changes have an implication
 of "you shouldn't need to touch this unless your hosting company has set
 things up in an unreasonable fashion". That was pretty much the original
 case described here: the hosting company had their PHP mail settings in a
 non-working state. That's a bug, so the uncommon step of modifying php.ini
 was a reasonable "fix" for that unusual situation.

 But the fact that someone had this problem doesn't suggest that it needs a
 WordPress configuration option, any more than it suggests a WordPress
 option is needed for many other php.ini options that might be broken.
 <shrug>

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14888#comment:20>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list