Sorry, I’m just not experienced enough to answer your question. All I know is that the server is running Debian 7.9 and that Postfix is used as MTA…
Where can I find the relevant config file(s)?
Plugin Author
Meitar
(@meitar)
Usually the main Postfix config file is in /etc/postfix/main.cf, then I suppose that means the default config is still trying to actually send email addressed to a .invalid domain. 🙁
Plugin Author
Meitar
(@meitar)
Stefan, here’s another attempt, this time also setting the From: header to a non-routable email so that the failure message shouldn’t get returned to you. Can you try testing patch acdc2f19 and let me know if this works any better?
Sorry, nothing really changed… I still get a “Undelivered Mail Returned to Sender”-Mail before I receive the E-Mail sent with Contact Form 7. The Delivery report looks like before.
Plugin Author
Meitar
(@meitar)
Hmm, is this a server you control (a VPS as opposed to a shared hosting account, for instance)? And can you tell me anything more about your postfix configuration?
Specifically, I am wondering if you’ve included bounce notifications beyond the default resource and software notifications (see Postfix notify_classes configuration parameter) and also is your postmaster address the same as your admin email address for your WordPress site?
I ask because over on GitHub it appears that other condigurations are not seeing the bounceback failure notification so I want to figure out if the error is delivered with a default config or if it’s only delivered with custom configs.
I’m a member of hostsharing.net, that’s a webhosting cooperative – so no, I don’t control the server. But at least I should be able to find out whatever you’d like to know.
In /etc/postfix/main.cf the following notice recipients are defined: 2bounce_notice_recipient, bounce_notice_recipient, delay_notice_recipient and error_notice_recipient. The recipient is always the server’s postmaster, not the domain’s (that would be me).
Plugin Author
Meitar
(@meitar)
So, I’m actually wondering what the value of notify_classes is, too. Is it:
notify_classes = 2bounce, resource, software
or some other list of values, or is there no notify_classes configuration line at all…?
At least in /etc/postfix/main.cf there’s no notify_classes configuration line at all…
Plugin Author
Meitar
(@meitar)
Okay, one more attempt, this time with a different approach in the code: only half-hijacking the wp_mail() call that the plugin issues.
Can you give patch 28dc8568 a try and let me know if you still receive either duplicated emails, unencrypted emails, or failure notification emails?
Thanks again for helping me get this right.
Plugin Author
Meitar
(@meitar)
I’m sorry, my bad. Ignore 28dc8568, please try 7fcd8a9f instead.
Yes, now I get no error message in Contact Form 7 and I receive the sent e-mail without any problems.
However, attached files are still not encrypted (I tried out a JPG and a PNG).
Plugin Author
Meitar
(@meitar)
Great. 🙂
However, attached files are still not encrypted (I tried out a JPG and a PNG).
Yes, encryption for attachments is not included in this specific patch. I wanted to nail down one issue at a time. I’m going to release the fix for this and then integrate it with the topic branch for attachments.
Plugin Author
Meitar
(@meitar)
Hi Stefan,
Back to the issue of encrypting attachments now that the earlier issue is resolved. There is a branch called issue-4 on the GitHub repository that *I think* will encrypt attachments. It doesn’t yet seem to work smoothly (no OpenPGP/MIME support yet) but I wanted to see if this code can at least correctly detect and add attachments. If this method works then I will try to make it compatible with OpenPGP/MIME so that email clients will be able to correctly recognize the encrypted attachments. Right now the attachments just appear as regular attachments, but should be ASCII-armored and encrypted.
Give this branch a shot, let me know?
Thanks.
Hi Meitar,
sorry it took me some time to reply. I was able to send an attachment with issue-4. It is not encrypted.
But I wanted to tell you something I didn’t mention before because it’s not really a problem… But it’s a bit strange. I’m using Evolution as part of GNOME as e-mail client (on Debian testing) and e-mails sent with your plugin look different than other e-mails…
Please have a look at this screenshot: https://tinyurl.com/z5cvkvo
Beneath the message there’s this green area that says that it is signed and encrypted. With the stable branch of your plugin there’s an additional empty field beneath that green area – just like in the screenshot. I have never received an e-mail with such an additional empty field before (and I’m using Evolution everyday for 10 years now).
Between the green area and this additional empty field there’s an additional element in the screenshot. It says that the message is encrypted… So there’s one element that says the message is signed and encrypted and then there’s an additional element that says it’s encrypted. That’s really strange.
In short, with your stable branch plugin there’s one strange additional element (the empty field), with issue-4 there’s another one (the second “encrypted”-element). Sorry, I’m not trying to sound complicated… English isn’t my native language.
Cheers
Sorry, this is wrong:
In short, with your stable branch plugin there’s one strange additional element (the empty field), with issue-4 there’s another one (the second “encrypted”-element).
Both of those strange elements are present no matter which of the two branches (stable, issue-4) I install. In fact I don’t really see a difference between those two branches… I can send attachments without any problems, but they are not encrypted (I tried that out with TXT, ODT, PDF and PNG).
