Contact Us emails failing validation

[mc12345678]

Site is running 1.5.1. I am thinking it may be the quick form for the contact us that is in the mega menu header I have up. The errors don't specify what page as it is in the sending of the mail that it fails, thinking that that tells me the built in anti spam is doing it's job.
The issue now is that over the holiday weekend I didn't receive any of my order confirmation emails... strange thing are brewing

Are you still getting the same type of error message as first reported?

I traced through the email code: STOREDIRECTORY/includes/functions/functions_email.php

That error message is provided (failed validation) if it doesn't pass the zen_validate_email function... If the email truely is of a valid type (Ie., properly formatted) and the code has not been changed, then you may have an observer that is looking for: NOTIFY_EMAIL_VALIDATION_TEST that is modifying the $valid_address variable to state FALSE... Check using DTK to see if that notifier is being listened for.

In a search of my files I only found that in one location, the function itself...

[mc12345678]

interesting... it looks like for some reason the send to email address is missing. Grabbing randomly from the massive amount of errors they all look to be the same:

[02-Dec-2013 08:03:27] ERROR: Failed sending email to: "" <> with subject: "Website Inquiry from sicassracing.com" (failed validation)

I am going to yank the quick contact us from the header now, see if that helps.

So, iil tell you what I did. I've onlyhadthe modified version of. Themega_manu up foor 12 hours, so I still have some testing to do/see. First, I made it so that the contact us dropdown didn't load (didn't hide it, literally made it not load so there would be no trace of it for anything to reference). Then I added what some have called the honey pot (hidden field added by ZC 1.5.1) between the two form boundaries of the mega_menu dropdown.

With those two basic modifications in place,I have been able to receive a contact us email when sent from either the quick dropdown and if one goes straight to the contact us link. Since then I have also seen that attempts have been made by outside computers to access parts of that process. Mostly they have gone to the success page of the contact us, but there have been no emails sent, no errors logged. It is as if they are simply trying to go to the success page without submitting a query. (Unless that is the next page to arrive at when improperly submitting a request, and if that is the case, the process is working as expected/desired).

I also added some functionality by including the who to contact drop down, but that has no effect on the problem you are describing.

[mc12345678]

Site is running 1.5.1. I am thinking it may be the quick form for the contact us that is in the mega menu header I have up. The errors don't specify what page as it is in the sending of the mail that it fails, thinking that that tells me the built in anti spam is doing it's job.
The issue now is that over the holiday weekend I didn't receive any of my order confirmation emails... strange thing are brewing

Two ways you can tell where they were: one post mortem, the other would require adding another plugin to your site. There may be others, but these two come to mindh 1) review your access logs from the server/host, and 2) install the plug-in user tracking.

[mc12345678]

So, iil tell you what I did. I've onlyhadthe modified version of. Themega_manu up foor 12 hours, so I still have some testing to do/see. First, I made it so that the contact us dropdown didn't load (didn't hide it, literally made it not load so there would be no trace of it for anything to reference). Then I added what some have called the honey pot (hidden field added by ZC 1.5.1) between the two form boundaries of the mega_menu dropdown.

With those two basic modifications in place,I have been able to receive a contact us email when sent from either the quick dropdown and if one goes straight to the contact us link. Since then I have also seen that attempts have been made by outside computers to access parts of that process. Mostly they have gone to the success page of the contact us, but there have been no emails sent, no errors logged. It is as if they are simply trying to go to the success page without submitting a query. (Unless that is the next page to arrive at when improperly submitting a request, and if that is the case, the process is working as expected/desired).

I also added some functionality by including the who to contact drop down, but that has no effect on the problem you are describing.

Sheesh, didn't realize how bad my cell phone keyboard was getting (space bar primarily but a number of other issues)...

I took a quick look through the SHOPPATH/includes/modules/pages/contact_us and see that if the anti spam action is triggered, then the next direction to go is to the success page and to not try to send an email... So, seems like it is working and that we have "visitors" (bots) attempting to send spam.

Looking at my previous post on a larger screen, I see that I forgot to mention that the contact us dropdown doesn't load when on the contact_us page... (It loads in all other cases.) I did this because it doesn't make sense to have a contact us form on screen and one available in a dropdown as well, it has the potential of confusing other program code such as if recaptcha were incorporated, which I wanted to see if the recaptcha would work with the above changes. (Not planning on implementing recaptcha again, as I've removed it seeing that the honey pot method seems to be working and would like to make things more "accessible" to customers, but there have been others that have been trying to figure out how to get it to work with the drop down contact us option.)

[mikestaps]

I ended up removing the code for the quick contact form from the header and replacing it with all of our contact info and a link to the contact us page...

I haven't had any error logs pop since I uploaded the changes.
I checked for the notifier, same here only location is the email functions file
Now to figure out why I haven't gotten any order conf. emails since wednesday.

[mc12345678]

I ended up removing the code for the quick contact form from the header and replacing it with all of our contact info and a link to the contact us page...

I haven't had any error logs pop since I uploaded the changes.
I checked for the notifier, same here only location is the email functions file
Now to figure out why I haven't gotten any order conf. emails since wednesday.

Generally speaking that seems like it will help; however, it defeats one aspect of the default contact us form... not distributing/providing the email address for spiders to pickup and send spam directly... (email address is shown/provided) if it takes the user to the contact us form, great, but I thought the presence of the email address would be something that would be picked up by those searching through for such things...

As for not receiving email for a long period of time? It may require talking with your host to see if they had flagged the account to prevent spam... :/

[mikestaps]

The actual code for the email address shown is sort of anti spam - info@sicassracing.com ;-)

[lat9]

That's not how you entered it in your admin's configuration, is it?

[mc12345678]

The actual code for the email address shown is sort of anti spam - info@sicassracing.com ;-)

That's not how you entered it in your admin's configuration, is it?

Sort of waiting for a response to that question; however, was also thinking, you were having this issue on both your production and test stores. Did the drop down version of the contact us menu have the same selection list as is available on your contact us page? Also do you have it setup with the "name" <email address>? or is it just email address? I thought one of the other setup attributes was to have both parts provided in the store's setup for the Set "Contact Us" Email Dropdown List selection. (Seeing that you do have a drop down list selection, though that doesn't address the automatic emails that are not being received.)

[mikestaps]

That's not how you entered it in your admin's configuration, is it?

Nope, that would cause all kinds of errors... That is just how I display any email using HTML rather than a STORE_OWNER_EMAIL_ADDRESS call.