I am just testing this out. I get a message sent to me that has the message but no subject or name or email address of sender. Is that the default setting?
Hummm… it wasn’t when I tested it 
Meaning, you should receive an email with subject, email address, and message in it…
Instead of the senders email, what is in the header of the email you receive? The installs email?
It really should default to the senders mail.
Let me just make sure that I didn’t somehow screw this up (unlikely because not only me tested it but still possible)
I’ll feedback in short.
Yeah so I cannot replicate this.
See screenshots of received email
Mind to open a Git Issue if you can still see this issue?
I think I know the problem. I can see now the subject is there but I am not getting the sender’s name or email address.
I am using AzureCurve’s SMTP plugin and it is putting that sender email address and name into the email; ie, my own credentials.
1 Like
I just disabled the SMTP plugin and tried a couple more times. Neither arrived.
Are you trying to send the email from the website using a non-website email address as the sender? I suspect my email client might be blocking them.
I’d personally feel much more comfortable if the sender’s name and email address was in the body of the email.
Hummm… yes, “of course”, I said at first: the mail from is set to the mail of the “prospect” that uses the form…
And then you got me thinking, you are right, your suggestion is the better approach.
Subject should default to some thing like “You got contact form mail” or whatever, filterable with Filter, and then the “from” should default to your website’s admin mail… also filterable of course.
This way you can avoid getting that mail to spam folder in case the header and from are recognised to not match (classic spoof pattern).
I could additionally set the “reply-to” to use the senders email…
Or just include it in the mail footer like the IP that is already included.
I like the idea and will implement this.
But I don’t think this is anyhow related to the message being sent, while missing subject and from:
either the mail is sent, and then it comes with all of its parts, or it is not sent/spam-foldered and hence never received. wp_mail or a mail server can’t just “strap out” parts of a mail but not others, at least, I never saw that happen.
I created a ticket for the change of who sends the mail and subject line: Change From and Subject to be admin email and default subject, put dynamic From and Subject into mail body · Issue #13 · TukuToi/tukutoi-contact-form · GitHub
EDIT:
Sorry I did not see your pre-previous reply about AzureCurve SMTP plugin.
All clear. I will make sure this gets changed and thus should be fixed with
1 Like
Yes, this is good if it can do this. My users who get a contact message expect to be able to just hit “reply” to respond direct to the sender.
2 Likes
Sent you an inbox with new Plugin version to make sure it works. (Will have to go over code to finalise Tag prior to new release and document new filters.)
1 Like
@anon66243189 I’ve been sick these past few days, and so I wasn’t yet able to try out this plugin.
No problem…
As above seen there’s an issue anyway, which I am correcting now 
2 Likes
@anon66243189 I’ve finally tried out this plugin on ClassicPress 1.2.0 (haven’t updated yet my testing site to 1.3.0), and I encountered some problems.
Context:
- My domain is registered to my webhost, but they aren’t a domains registrar but are working together with one to provide the service.
- My webhost provides DNS and email forwarding, both of which I’m using.
- My site administrator email is
[email protected]which forwards to my ProtonMail account. - My webhost is strict about emails to avoid spam. For example, they filter out emails that are sent by improperly configured servers.
And so the problem is that when I tested the contact form, no email was sent to the site admin email address, only to the user’s email address (the confirmation email).
I checked the records: my website sent two emails, but one was dropped by my webhost. I tested it again, and the result was the same.
I then tried changing the site admin email to one of my Gmail accounts. The result? The website sent two emails, like before, but this time both emails were dropped by my webhost.
I checked my webhost’s FAQ, and this is the relevant information about it:
If a message bounces or is blocked by our outbound spam filters or for noncompliance with best practices…
Hmmm this is strange, as that is exactly the issue that is fixed since 2.2.0
And so the problem is that when I tested the contact form, no email was sent to the site admin email address, only to the user’s email address (the confirmation email).
Based on what is that a problem?
The plugin sends the email from the same email as you set in the WP Settings. If you can send password resets, then you should be able to send these emails too.
What I mean is… the headers can’t be more compliant. They are basically how WP would send the mail as well. It was indeed an issue before, since moron me had set the headers to be those of the prospects’ email (so, the email provided by the people who use the contact form)
That, was plain wrong and caused all proper mail servers to reject the mail as spoof.
But that is fixed, so… I am not sure why it would fail.
Are you sure you used version 2.2.0?
If so, do you have an example of headers expected versus the headers it creates on your server?
You can also pm me those, so the data is not exposed here in any case.
The latest version of the plugin was fine for me but my testing was done using the SMTP plugin (available on the CP directory) and sending it via Mailgun.
Email deliveries are a constant source of problems and my research (and advice here) told me that this was the most reliable solution.
1 Like
This is indeed a troublesome thing.
@anon98749105 maybe your server/host has hints as of what “best practices” would be?
Maybe I miss something in the headers for this specific case.
Yes, I’m using version 2.2.0.
I downloaded from the CP repo, which is, I should note, twice the size of that in WP repo, because of the included “__MACOSX” folder.
I’ll send you pics of email headers for the confirmation email of the plugin, and for comparison, other emails sent to me by both ClassicPress and WordPress. I don’t have copies of email sent by the server, however, and so I can’t show you what the dropped messages were like.
Anyway, maybe this is the problem:
The confirmation email uses the my site admin email for From and Reply-To, and this is sent successfully because the recipient is the user’s email address.
If the notification email to the site admin uses the same From and Reply-To, then the sender and recipient will be the same, and maybe that’s why it is blocked.
Messages sent to me by both CP and WP don’t use my site admin email address in the From field. They use [email protected] or [email protected]
That is rather weird.
I see no __MACOSX folders in that package?
I do see gitattributes, which I obviously missed to remove from the release.
If the notification email to the site admin uses the same From and Reply-To, then the sender and recipient will be the same, and maybe that’s why it is blocked.
I hope not, because… but I can show you how to test this with a filter.
Lets go PM
I administer many client websites and therefore the admin email is mine, I do not want inquiry emails from the site. and mostly the clients do not want “admin” emails.
For the sites I administer I usuall create an amail account (cPanel) that I use as the “from” email and set the “to” email to the clients preferred email address. This might be on the domain, or Gmail address etc. (Hotmail and Outlook address can be very picky about settings)
Does this fit in with your form?
I have not tried it yet I will add to a site this weekend to test.
There are filters with which you can alter the form and headers, so yes, you can change that default.
If you unzip in Windows the file from the CP repo, you’ll get:
I didn’t think anything amiss about this because I had encountered this many times before. Maybe this is just how some files packed in Mac show up in other operating systems. When I unpack this plugin directly on my Unix server, the __MACOSX folder are present too. I just delete it.
I previously mentioned that when I changed my site admin email address to one of my Gmail accounts, both emails sent by the plugin (the confirmation and notification emails) are dropped by my webhost. I realize now the reason for that.
If the plugin is using the site admin email address in the FROM field, then obviously, I cannot send from my Gmail account because Gmail is not my “mail handler” (if that’s the correct term).