[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