zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 · 2017-02-21 06:28:35

Kjeld wrote #304168:

I just installed zem_contact_reborn v4.5.0.0 on a site using MLP.

The English side works well, but on the Japanese side, I get messages like zem_contact_email_thanks instead of the actual Japanese language strings.

What am I missing?

Japanese language strings are missing? Some time ago I had a project where that was needed, and I had sort-of-promised to provide the translation. Unfortunately, that project felt through, or rather was reduced by half (only English language pages).

p.

johnstephens · 2017-02-23 19:35:15

I’m experiencing a problem with a client’s Textpattern installation hosted by DreamHost. I’m sure the problem is somewhere with DreamHost, but I don’t know what steps I can take to troubleshoot it.

The site is failing to send all email, including zem_contact_form submissions. It is also failing to send password reset messages from Textpattern’s reset page here: /textpattern/index.php?reset=1

The problem began sometime after the Textpattern 4.5.7 upgrade in April of 2015, when I last verified that it was working. I’ve just upgraded the site to Textpattern 4.6.2, using Spiridon’s MLP fork for Textpattern 4.6+, and this version of zem_contact_reborn. I also changed the server settings to use PHP 7 instead of 5.6, and everything else is working just fine.

When I submit the zem_contact_form, the plugin redirects me to a ZCR URL, like this #zcrcb508ec1467263173240937e291d19ec, as expected. But I notice that the ZCR success message—this form uses the default “Thank you, your message has been sent”—isn’t showing up at all. I have looked at the server’s access and error logs before and after submission, and the submission is not generating an error in the logs.

Textpattern’s password reset page does generate a success message, and redirects to Textpattern login: “A confirmation message was sent. Please check your email and follow the instructions.” But no such confirmation email is generated. And like the zem_contact_form submission, no error is logged in the server’s error logs.

I know that this isn’t the right forum to ask for DreamHost support, but I thought it might help to ask here since people are familiar with ZCR. I hoped that the form’s failure to generate a “thanks” message might help someone who knows ZCR to pinpoint the issue, so I can provide DreamHost more useful information to trace and resolve the problem.

I contacted DreamHost support already, and the agent who responded said that they could not troubleshoot the problem without an error or specific information. They suggested I get in touch with the “developer of the form”.

Thanks in advance for any guidance you can provide!

phiw13 · 2017-02-23 23:37:36

@johnstephens

Are you sure the emails are not sent? I have ZCR working just fine on Dreamhost. The thing I noticed is: if I fill in one of my own email addresses (same as the domain that hosts the ZCR form), the email messages ended up in the spam folder.

Bloke · 2017-02-23 23:56:12

johnstephens wrote #304244:

The site is failing to send all email, including zem_contact_form submissions. It is also failing to send password reset messages from Textpattern’s reset page

When you say all email, is it to email across all domains or do you find that maybe it’s specific domains that don’t get through? The reason I ask is that I’ve had a devil of a job on some servers from getting (for example) messages to send to gmail accounts, but they’ll get through to hotmail fine. Or vice versa. It seems that some domains are just overly sensitive about the origin of the messages (which domain they are from) and just blacklist you.

Things you can try, besides different recipient addresses to see if it’s a blanket sending problem or just a few recipient domains:

Play with the SMTP envelope sender address and Send login details from this email address settings in prefs.
Tinker with Dreamhost settings (if you can) to add SPF or DKIM records.

These steps can increase the trustworthiness of your domain, which may then help with delivery of mail as it’ll add the relevant headers on outgoing messages which recipient servers use to gauge spaminess.

Note that adding DKIM records is an uphill slog if you don’t run your own VPS and may not be possible because ZCR uses sendmail and not SMTP. However, with the new callbacks in the plugin it is possible to write a small module that will intercept all outbound contact information and route it through SMTP instead. I did actually look at that once and wrote a hook for it, but I can’t for the life of me find the code, sorry. Maybe I didn’t store it anywhere on my laptop, and posted it directly in the forum somewhere instead? Dunno.

Anyway, doing that won’t help with reset messages being swallowed. But adding an SPF might be a first step if you can do it.

These type of things are difficult to debug, unfortunately. If there are no error messages in the logs, chances are that Textpattern thinks it’s done its job just fine, but the receiving end simply doesn’t trust what it receives and silently bins everything. This is my biggest bugbear with server intervention measures. If I wanted a server/service to vet my messages, I’d ask them to do so. It’s my mail: let me write my own filters to weed out spam. Let me turn off the server-level meddling because I assert that I know what I’m doing and accept the consequences. But that’s rarely (ever?) an option now. Companies take it upon themselves to employ crappy heuristic tests as a “feature” to protect customers from spam, and end up ditching swathes of legit mail in the process. And the worst part is that the recipient never gets to find out about discarded messages, because it’s sent to a black hole. Grrrrr. </rant>

jsoo · 2017-02-26 13:38:14

Hi John, see https://help.dreamhost.com/hc/en-us/articles/215036058-Sender-domain-policy-and-spoofing-overview. Per Dreamhost policy email can only be sent using a from address from the same domain. I have some DH sites and had ZCR set with the from address that of the user filling out the form and got the same behavior you describe. Changing this to a same-domain address fixed it.

I’m not sure when this policy went into effect, but I think it was fairly recently.

Last edited by jsoo (2017-02-26 13:38:48)

ovekaaven · 2017-02-27 03:26:35

I, too, run ZCS fine on Dreamhost. The thing is that Dreamhost is very strict about the default sendmail, and much less strict when using SMTP. However, as far as I know, with ZCS, you can only use sendmail, not SMTP, which means you need to comply with the strict policy.

However, I found complying to be fairly simple: just use zem_contact’s “from” attribute. The from address must be an email account that is fully hosted on Dreamhost (i.e., forwarding-only addresses aren’t good enough).

(For the other stuff, make sure to also set Admin / Preferences / Admin / “Send login details from this email address”, and probably “SMTP envelope sender address”, to an email account that is fully hosted on Dreamhost.)

For spam control, Dreamhost already enables DKIM on your domains by default (assuming you use their SMTP service), but you can add SPF manually for additional protection. (I did for my domain.) Note that Dreamhost does not enable DKIM if you use sendmail, so you probably can’t get it with ZCS.

Last edited by ovekaaven (2017-02-27 03:38:19)

jstubbs · 2017-03-30 01:52:08

Anyone use ZCR on WebFaction with email served by Fastmail? Running into some problems and any pointers appreciated…

Destry · 2017-03-30 13:01:28

This plugin should have been called smd_death_to_zem_contact_reborn, or just smd_comms, or whatevz.

wornout · 2017-03-30 13:45:52

I have an error with zem_contact_reborn. After submit the form any email are sent.
In the error log it’s noticed:

Thu, 30 Mar 2017 15:36:07 GMT [error] [client 0.0.0.0] - www.stoneone.it - AH01215: sendmail: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol: /php-wrapper/php-cgi, referer http://www.stoneone.it/it/contatti/

Thu, 30 Mar 2017 15:36:07 GMT [error] [client 0.0.0.0] - www.stoneone.it - AH01215: postdrop: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol: /php-wrapper/php-cgi, referer http://www.stoneone.it/it/contatti/

Any suggestions?

Last edited by wornout (2017-03-30 13:47:13)

GugUser · 2017-03-30 17:39:21

Destry wrote #305145:

This plugin should have been called smd_death_to_zem_contact_reborn, or just smd_comms, or whatevz.

Hm, not very friendly.

jstubbs · 2017-04-05 03:33:34

jstubbs wrote #305131:

Anyone use ZCR on WebFaction with email served by Fastmail? Running into some problems and any pointers appreciated…

In case anyone else comes across this issue, the problem was caused by an over zealous spam filter on outbound emails from WebFaction.

Bloke · 2017-04-26 10:55:10

A heads-up: anyone on the bleeding edge of 4.7.0 will notice that the plugin outputs labels twice. There’s a temporary patch you can apply, as outlined in the GitHub issue linked above, but I don’t know if it has other side-effects yet. I suspect it does, though it at least stops the duplicate labels.

Investigation is ongoing. In the meantime (and this is primarily aimed at Oleg, but if anyone has any insight, please chime in) the only reason the plugin uses its own lAtts() attribute parser is to do some extra manipulation for legacy reasons. Namely, to permit “on” and “yes” as alternatives to “1”. I also chose to use this function to enable the plugin’s own implementation of “global attributes” for atts that are common to most input tags:

    $zem_contact_globals = array(
        'accesskey'  => '',
        'autofocus'  => '',
        'dir'        => '',
        'disabled'   => '',
        'hidden'     => '',
        'id'         => '',
        'lang'       => '',
        'list'       => '',
        'readonly'   => '',
        'spellcheck' => '',
        'style'      => '',
        'tabindex'   => '',
        'title'      => '',
        'translate'  => '',
    );

That saved me having to add them to every tag by hand.

Instead of doing that, could I (a.k.a any plugin) hook into the core’s shiny new global attributes system and augment the available attributes for specific tags? i.e. register the above attributes as valid options only for the plugin’s tags? If not yet, could it be done that way? Is that desirable? Or too slow?

If it’s possible I could perhaps remove the plugin’s custom attribute processing and replace it with the core lAtts(). Although, the label attribute for some of the plugin tags are set to some gTxt() value’s default in the attribute list, so I’m not sure how compatible that is with core global attributes. Probably okay, I guess. Untested.

If not, how could I implement something in the plugin that played nicely with the core system? Bonus marks if it’s backwards compatible with 4.6, but not essential.

Textpattern CMS

Textpattern CMS support forum

#181 2017-02-21 06:28:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Kjeld wrote #304168:

#182 2017-02-23 19:35:15

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#183 2017-02-23 23:37:36

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#184 2017-02-23 23:56:12

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

johnstephens wrote #304244:

#185 2017-02-26 13:38:14

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#186 2017-02-27 03:26:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#187 2017-03-30 01:52:08

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#188 2017-03-30 13:01:28

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#189 2017-03-30 13:45:52

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#190 2017-03-30 17:39:21

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Destry wrote #305145:

#191 2017-04-05 03:33:34

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

jstubbs wrote #305131:

#192 2017-04-26 10:55:10

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Board footer