www.wysiwygwebbuilder.com

I've just set up a form in a flexgrid exactly the way I've done it dozens of times in WB. However, this time around, all emails generated by the form are coming back with the following error: The "from" field should only include contact@3-2-1-inflationbusterlisting.com...why the "boundary" field is being inserted I have no idea.

Also, I notice the body of the generated message has extra information that (I think) shouldn't be there. Example:
I never noticed the extra encoding previously.

I'm using the built-in PHP script and the only "Advanced" options checked are "Include IP address" and "Do not allow URLs". No CC's or BCC's, but the fields "From email:" and "From name:" are populated. The "Reply to:" field is $mailfrom.

There are no external/user added scripts of any kind.

Any clue as to what I'm doing wrong?

There have been no changes to the way forms are implemented, it works the same as before.
Maybe you have used different settings?
For example, maybe you have previously used PHP Mailer? In that case, completely different code will be generated.

No, sir, I'm using the default settings and not using PHP Mailer.

On subsequent tests, I am consistently getting an error in the "From:" field in the actual email, to wit:

From <contact@3-2-1-inflationbusterlisting.com>, boundary="6e4517e434ba67263359d674772c42aa" X-Mailer: PHP v8.1.22

Obviously, the "boundary=" section should not be included with the From email address. This "boundary" section appears to be added on the default setup, and also when I attempt to specify a different "From" address in the "More" dialog for the email processor.

I agree, this has not happened in the past -- previous versions of WB worked flawlessly.

Yet, something -- somewhere -- has changed -- perhaps in PHP? Have you verified that the code still works as expected?

I have recreated the form and used all the default settings. No modifications of any variables.

Here is the result:

Action: failed
Final-Recipient: rfc822;xxxx@gmail.com
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [162.241.210.78] Messages with multiple addresses in From: header are
550 5.7.1 not accepted. s10-20020a92cc0a000000b00346355c0b5bsi4703155ilp.19 - gsmtp
Subject 3-2-1-InflationBusterListing Communication
From xxxxx@yahoo.com, boundary="d3b61aaa9358821aa0a627e1be97ce8e" X-Mailer: PHP v8.1.22
To xxxx@gmail.com
Date Today 15:21

The code in red should not be there.

I can send a demo of the project if that will help.

This code has always been there. It has not changed.
I am sure that if you try this in any previous version of WWB, then you will get the same code.

Are sure your web host has not changed something?
For example, many web hosts now require you to use SMTP (PHP Mailer) instead.

I am my own host and my server hasn't changed anything.

I shall investigate further. Something is causing the additional "boundary" code to appear as part of the email address.

Pablo, the problem in the PHP form processor script is due to $eol being incorrect.

Instead of
it should be...
With that change in place, the email formats correctly, the "boundary" code is removed from the "From:" address, and GMail no longer rejects the message because of what it thinks are "multiple addresses" per line.

Can this be fixed? It is a pain to upload the site, then download the page with the form code, make this correction, and re-upload.

Thanks!

Again , I would like to note that this has always been this way since version 5!
It's a huge risk to change something that has worked for many years, I could affect other users.
But I may add an additional option for this later.

In the meantime, you can try to add a Site variable to replace the code:
Name: Value

Thanks for the suggestion, Pablo. Adding the site variable unfortunately breaks the code and I get a 500 error when trying to access the site.

According to the Php Manual for PHP Mail:

Each line should be separated with a CRLF (\r\n). Lines should not be larger than 70 characters.

Actually, the code as it is now is broken. Have you tried sending a test message to yourself to see the result? You might be surprised.

I have used this code for more then 15 years almost daily. It never gave me any issues.
Also, it seems to have worked for everyone else.
I think the risk it too high to suddenly make a change like this in the code.

Are you sure nothing has changed on the server side that this suddenly stopped working?

All I can tell you is that with the default value of $eol = "\n", when I send a test email to my account, the message contains the following information I've emphasized in red that should NOT be there:

This is a multi-part message in MIME format.

--140460040590f2b34c94ea7f11cfea37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The following information has been submitted:
IP Address : 72.239.9.23
Name : George
Email : gg@gmail.com
Phone : (407) 665-xxxx
Comment : Testing.

--140460040590f2b34c94ea7f11cfea37--

If I modify the value of $eol to = "\r\n" as specified in the PHP manual, all the text in red disappears (as it should).

Again, I recommend you send yourself an email from within a WB project and examine the content of the message you receive. You'll see what I mean.

I should add, my server is using PHP Version 8.1. Don't know if that makes a difference.

As mentioned, it works for me. I use this feature every day. Even on my own websites (PHP 8.1 and PHP 8.2)
This functionality has been working like this for more the 15 years, so I want to be careful changing it if it only affects one user.
But, I will investigate if this can be made configurable.

Thanks.

I revisited the User Defined Variables option and I apparently entered the values incorrectly the first time around. If I specify the "Name" as:

$eol = "\n"

and the "Value" as:

$eol = "\r\n"

the substitution works. This solution is fine for me. I still believe the correct formatting is "\r\n" based on the PHP Manual, but if all is working for you and others, I'm good.

Thanks for your interaction on this issue. It is another example of the quality that goes into WYSIWYG Web Builder.