We don't do option B since some senders' domains have their SPF configured to send from designated servers. I don't recall if the email will be marked as spam or won't send.

what is the problem you are trying to solve with this change?

@brianteeman do you mean the main reason why I think this feature is useful for Joomla?

The last commit/change just implemented the things you mentioned before and a new space before the if condition to pass the code checks.

@brianteeman do you mean the main reason why I think this feature is useful for Joomla?

yes exactly

@brianteeman

The reasons for the change is that on the website owners end can be used different systems to handle the email requests from the form.
In some of this systems the mail will be assigned to new customers automatically by the given name and email address. If the email is sent with the data of the Joomla! website itself, then the email will initially be assigned to this 'account'. This results in some different kind of problems and inefficiency.

1. The agent need to:
   a) create a new account/contact every time manually
   b) move the request to that specific account/contact

Only then, after that, finally he can do his actual job.

2. No efficient filtering
   There is no way to easily route the emails to specific departments without having different sender emails in some systems at all.
   In some others it is only possible by queuing different rules what have to be done in each system again and again.

3. Not intuitive

a) It's just totally confusing to always see the Joomla! system data name/email in the email queue if the message is actually send by someone else.
b) You can not filter for senders email address because it's sent by the system email. You always have to combine different filters or have to live with that you'll find all other system mails as well. Even in your privat inbox.

So, the problem what will be solved is inefficiency and lack of flexibility to make things easier for the endusers.

We have this situation quite often on customer websites and on our own.
Cause we want to avoid to use a 3pd extension whenever it is possible, I think that it is a good idea to have this option in the core itself.

I hope that answers your question. If you need any further informations, just let me know.

Can you filter by the Reply-To header?

My main concern is that the email will not be delivered because the sender email address may not be authorised to send emails from that server and/or that spamassasin (and similar) will block the email because the domains dont match

@brianteeman

I agree on that. An in deed I thought about it before I started to create this pull. I ended up to see more benefits in it and started.

It can be a problem if you don't control your mailserver or you do not know what you.
But on the other hand this is a option and you still have the same result like before if you do not change the parameters.

If the contact form use your own SMTP server to send the email with your own credentials but another email address there also should not be a problem, tho?
And if you use PHPMailer, I would say you have totally other problems to solve. :-)

And by the wat SMTP. Let's compare it with the PHPMailer and SMTP settings in the global config.
If you don't know what you do, you just use PHPMail and the risk is high that your emails not will arrive on the receivers end. This is why you should know what you do.

Maybe to add this information to the description tooltip is a good way to make people aware of it?

As I said, in general I see more benefits then concerns.
Why should we not give the people control over or the possibility to control such a important thing by themselves? At the end, people who definitely need this feature will end up in hacking the code (what actually nobody wants) like we did it on our own projects for years.
This, again, results in inefficiency because you have to merge/check your SVN after each update.

@Quy
Thanks for that. Of course some systems can do that for sure and I am aware of it. But:
a) this will solve only one of the problems I mentioned above. Still with extra work.
b) I do not writing here to solve my own problem on my end. Where is the efficiency if anyone need to find a solution for a thing what can be solved with a little change at the root of the problem. See it globally, how many hours of hustle you can save for hundreds if you solve the problem itself instead of create a workaround for it over and over again? :) I had this random problems of that mentioned above a lot of times in the last years and of course I always found a workaround for it.
But still: it's inefficient and unsustainable to do so over and over again.

the last thing we want to happen is for someone to set an option which results in their email not being delivered

the last thing we want to happen is for someone to set an option which results in their email not being delivered

Why PHPMailer is still an option in the global config? Kidding.

But just to make clear. In my opinion this will not be the case.
If your own mail server validates incoming mails with SPF or any other mechanism, then your own IP and/or domain should be whitelisted. If this is not the case, I would say it is a bad configured mail server, tho? Correct me if I am wrong, I am not an expert on this specific topic.

Any suggestions? Any other thoughts?

it will be the mail server not the web server doing the validation. many users are not in control of it to be able to whitelist anything

Was a typo. Of course the mail server.

Apart from that: you are right. I totally forgot while writing about the users who use 3pd services like Gmail as incoming mail server.

not just 3pd services like gmail but the typical shared hosting environment.

So, first contribution failed. Shit happens.
I'll keep going. The next one will be better. ;-)

Thanks for trying - I hope the next one is more successful

If at first you don't succeed....