An Admin Dashboard Request

  • Resolved sffandom

    (@sffandom)


    11 years, 4 months ago

    I use this plugin on many Websites and it is quite popular and useful. However, as I add the plugin to more sites and more people sign up for notifications I have to deal with an increasing number of bounce messages.

    About 1% of the people who subscribe for notifications are receiving email via Internet Service Providers whose email filters reject the messages for a truly esoteric reason. They are looking at the RETURN-PATH: header in the emails, and if that RETURN-PATH is set to an unresolvable domain name the emails are bounced.

    Why is there an unresolvable domain name? That is just the way some Web hosting companies handle their server names. The INCLUDES/PLUGGABLE.PHP script is setting this value by looking up $_SERVER[‘SERVER_NAME’] and this is really a problem with core WordPress but I’m not ready to go barging in there and make a request when I don’t understand why the developers settled on that to begin with.

    The “wp_mail()” function allows you to override the default headers with the “$headers” variable in your function call. Although this is a band-aid fix, it’s a relatively simpler resolution than waiting for WordPress Core to integrate some other solution (if one is even feasible — most people cannot even find their server names).

    To send email we cannot change the server names on the machines we are using. We have to leave those as they are set by the hosting providers.

    So what I would like to see in Subscribe2’s SETTINGS page is a simple way for overriding headers, at the very least “RETURN-PATH:”, which should really be going to some address at the domain sending the email.

    Alternatively, if you could just force the plugin to set RETURN-PATH to the admin email address that sends the email anyway, that would be even better.

    I hope this makes sense. I know I can edit PLUGGABLE.PHP but I would have to do that for every site I administer every time WordPress is updated and that is really not something I want to do.

    https://wordpress.org/plugins/subscribe2/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Matt Robinson

    (@mattyrob)

    11 years, 4 months ago

    @sffandom

    How about the ‘s2_email_headers’ hook in Subscribe2:

    Documented here:
    http://subscribe2.wordpress.com/support/api/

    Thread Starter sffandom

    (@sffandom)

    11 years, 4 months ago

    If you’re suggesting that I modify a hook file on each Website, that might work unless the hooks are overwritten each time the plugin is updated; in which case, it’s not a desirable solution.

    Any change I make must be persistent across updates. That is why I am requesting a dashboard option.

    Matt Robinson

    (@mattyrob)

    11 years, 4 months ago

    @sffandom

    That’s not really what I meant. Hooks are created in the code to allow users and developers to change certain aspects of the code without having to edit the code directly.

    So, in your example, the ‘s2_email_headers’ hook takes the email headers created by Subscribe2 and allows you to change them, add to them or take details away before passing them back for Subscribe2 and WordPress to use.

    Thread Starter sffandom

    (@sffandom)

    11 years, 4 months ago

    That’s really not a suitable solution for several reasons. First, I am not a PHP developer; although I can learn to write my own plugins and have in fact created a few child themes over the years, this is a universal problem. It’s not just MY problem, and even if I were to upload a plugin not everyone who uses Subscribe2 would known to download it.

    Second, I suspect that most people who use the plugin don’t even monitor their bounce messages; they may have only limited access to their system administration. They won’t know if they need to change this behavior (although my guess is that as email spam becomes worse more ISPs will be checking more headers in an attempt to block suspicious email). It would be better if the plugin marries itself to the idea of ensuring proper headers are sent out.

    Third, if there is no hope getting this plugin fixed then I need to find another plugin, not try to fix it myself. I administrate over 100 WordPress installations. I don’t have time to take on support for a plugin or hook. If I did I would have contributed something to the libraries already.

    I appreciate your suggestion, which eliminates waiting on my part, but it’s better to press for an achievable solution that helps all plugin users than to try to make a band-aid that only fixes my problem.

    Matt Robinson

    (@mattyrob)

    11 years, 4 months ago

    @sffandom

    Let’s rewind a little to your original problem and then perhaps you’ll understand the current situation better.

    Subscribe2 creates several email headers, including the Return-Path headers. The Return-Path is set to the same email address as the Sender address. See the source code here.

    So, your issue is really that your hosting provider is resetting that header. That is not something that can really be fixed in Subscribe2 because once the emails have been created in subscribe2 tey are passed over to WordPress and the wp_mail() function, from there they go to the PHPMailer class and then onwards via an SMTP server or the ‘sendmail’ binary on the webserver. Nothing gets reported back down the chain other than success or failure and there are no more opportunities to intervene.

    In some respects it may be worthwhile investigating using a plugin like Configure SMTP that pushed the emails via an authenticated SMTP server rather than the sendmail binary on the webserver – that makes a server side re-write of the header less likely.

    Thread Starter sffandom

    (@sffandom)

    11 years, 4 months ago

    “So, your issue is really that your hosting provider is resetting that header.”

    No, they are not.

    Core WordPress is grabbing the machine name and injecting that into the headers.

    This is something that SHOULD be fixed in Core WordPress. However, convincing everyone to see the problem, to acknowledge that it is a problem, and getting an appropriate solution worked out will take forever.

    The plugin, on the other hand, can take advantage of EXISTING Core behavior and overwrite the Return-Path header.

    That’s not ideal for all WordPress users because other plugins will be relying on Core code to set the headers, too. In the long run the problem should be addressed in Core. But in the short run I need the problem fixed in THIS plugin; otherwise I will have to replace it with something else that can do the job.

    Thread Starter sffandom

    (@sffandom)

    11 years, 4 months ago

    Okay, if I read the code you’re pointing me to correctly, you ARE trying to override the headers with a valid Return-Path.

    That still points to a problem with WordPress (not the hosting provider). I will try to determine if there is a breakdown in the communication between the plugin and WordPress.

    You may mark this thread as resolved. Thanks for taking the time to dig into it with me.

    THIS COMMENT HAS BEEN EDITED AND SUBSTANTIALLY REVISED.

    Matt Robinson

    (@mattyrob)

    11 years, 4 months ago

    @sffandom

    Thanks for the update, as you point out the code I directed you too demonstrates that Subscribe2 does set a Return-Path header.

    If you end up with the server machine name in there I have to say I honestly think it’s happening on the server – I don’t think the WordPress wp_mail() function over write any pre-existing header. Put it this way, I’m certainly not seeing that on either of my main blogs.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘An Admin Dashboard Request’ is closed to new replies.