Need help setting up Mail on my Laravel application.
My .env file:
MAIL_DRIVER=smtp
MAIL_HOST=smtp.office365.com
MAIL_PORT=587
MAIL_USERNAME=*****#*****.com
MAIL_PASSWORD=******
MAIL_ENCRYPTION=tls
This returns the following error :
Expected response code 250 but got code "", with message ""
I had the same problem and it turns out Office 365 doesn't let you use a different from setting in your mail sending function than the one you use in your .env file.
I wanted to set the from name and email address according to whatever data was coming in via the request of a form submission as to capture them in the CRM system and it threw that same exception. Not sure if this helps you, but this was how I solved my problem.
Here's my code in the controller as an example:
$data = [
'name' => $request->get('name'),
'surname' => $request->get('surname'),
'email' => $request->get('email'),
'phone' => $request->get('phone'),
'subject' => $request->get('message-subject')
];
$from = $data['name'] . ' ' . $data['surname'];
Mail::send('mail.mymail', compact('data'), function($message) use ($request, $data, $from) {
$message->to('example#companyiworkfor.com', 'Some Company I Work For')->subject('Website Contact Form');
$message->from($data['email'], $from);
// Office 365 won't let you use a different from address here,so use same email as per your .env
});
We were getting the same error message in one of our customer's internal tool, which runs on Symfony 3 and Swiftmailer v5.4.4.
After some debugging, I found out that there was a previous exception thrown by Swiftmailer. The reason was the response from smtp.office365.com:
421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls. [AM6PR02CA0020.eurprd02.prod.outlook.com]
Microsoft dropped support for TLS 1.0 und 1.1. After some research I found this github issue:
This commit (4c4b333) introduced TLS 1.1 / 1.2 support, but didn't make it to any release yet. Unfortunately all Swiftmailer users (besides the ones using recent dev-master) are tied to TLS 1.0, which starts to give issues
In one of the comments #fabpot replied that they've backported the bugfix to Swiftmailer 5. It landed in release 5.4.10.
After upgrading Swiftmailer, the mailing worked again.
Related
I have followed the instructions for installing a password client for Laravel passport exactly as written in the Laravel docs and with default Laravel 6.0 composer versions of guzzle, etc. I have done the install on an existing project and as a clean install, both on local dev environment and live server, and every time I try to post to the example.com/oauth/token route, I am greeted with a crazy Guzzle error that seems to have no previous search history on the internet. The error is (summarized):
GuzzleHttp\Exception\ServerException
/var/task/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
"Return value of Zend\\Diactoros\\normalizeServer() must be of the type array, none returned"
I am running php 7.3 in all environments, but tried php 7.2 and 7.1 and got the same result. I'm running Laravel Valet locally, and have never seen anything like this on any other project. I am also running a staging server with Laravel Vapor, and I get the exact same error. My guzzle request is almost exactly the same as Taylor Otwell's example in the Laravel docs, and looks like this:
$http = new \GuzzleHttp\Client;
$response = $http->post(env('API_TOKEN_URL'), [
'form_params' => [
'grant_type' => 'password',
'client_id' => env('PASSPORT_CLIENT_ID'),
'client_secret' => env('PASSPORT_CLIENT_SECRET'),
'username' => $request['username'],
'password' => $request['password'],
],
]);
return json_decode((string) $response->getBody(), true);
I have data dumped all variables to verify that the username, password, client_id and client_secret are all accurate. It doesn't seem to be an authentication issue at all, but some issue with Guzzle passing proper server headers. I have no idea how to fix, as there is no previous record of this issue that I could find anywhere else on the internet. Any ideas???
if someone face this issue just update the package name: laminas/laminas-diactoros to latest version such as 2.2.2 by running
composer require laminas/laminas-diactoros
the problem comes from
normalize_server.legacy.php
its does not return anything.
I have problem,
when I send mail from localhost everything works fine,
but when send from server I don't receive mail and I don't get error.
My env. file
MAIL_DRIVER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=xxxx#gmail.com
MAIL_PASSWORD=xxxx
and function
protected function contactMe() {
Mail::send('request2e', array(
'subject' =>Input::get("subject"),
'email' => Input::get("email"),
'message1' => Input::get("message1"),
'number' => Input::get("number")
), function ($message) {
$message->from('xxxx#gmail.com', 'Contact');
$message->to('yyyy#gmail.com')->subject('Contact');
});
return redirect('/');
}
Have any idea what could be the problem?
If you're using Gmail smtp you have to use the smtp driver:
MAIL_DRIVER=smtp
MAIL_PORT=587
MAIL_ENCRYPTION=tls
Make sure to clear the config cache if you have to (required in production).
php artisan config:cache
Everything else seems to be aok.
In your Gmail settings page do the following:
Click on the Forwarding/IMAP tab and scroll down to the IMAP Access section: IMAP must be enabled in order for emails to be properly copied to your sent folder.
I think you there is a problem with google app security functionality.
From above given link, turn on this functionality and check for this issue.
Hope this helps you.!
Everything in my Magento store is working ok, except for a route I created that calls the API:
$proxy = new SoapClient('SOAPCLIENTURL');
$sessionId = $proxy->login('USERNAME', 'PASSWORD');
$proxy->customerCustomerCreate($sessionId, array(
'email' => $email,
'firstname' => '',
'lastname' => '',
'password' => $password,
'website_id' => 7,
'store_id' => 7
));
When I comment out these lines, the route works fine. Any ideas why this 503s the page and how to fix it?
The code block that's causing your problem is a request to an external API that could fail for numerous reasons. The way you'd fix this is to monitor your server and Magento error and exception logs for errors, take a look at the error, and then fix the problem (or post the specific error to a site like this and ask for help).
You could also try running the above code snippet outside of a Magento context (in a stand along script) and see what sort of error you get.
If errors aren't showing up then you need to research how to setup your system for proper error handling.
Also, if you're setting up a Magento route and making an API call into the same system, there's no reason to use the SOAP or XML-RPC layer. Each Magento API section has a corresponding PHP object that contains all the logic. The above method is equivalent to
Mage::getModel('customer/customer_api_v2')->create(array(...));
With the real PHP class being at
app/code/core/Mage/Customer/Model/Customer/Api/V2.php
and the create method defined at
app/code/core/Mage/Customer/Model/Customer/Api.php
I currently have a contact form on my website which sends off an email notification upon submission. It is working perfectly on my end and even when I send it externally to friends as a test they are receiving it.
My client however, who is in France, can't seem to receive this email at all and I have no idea why. Is there anything I need to do to ensure that they receive it? I thought it was something on their end but they're absolutely adamant that it's not and that it's a problem with my code. I have tried different email addresses for them with different domains and still no luck!
$this->load->library('parser');
$config['mailtype'] = 'html';
$config['charset'] = 'utf-8';
$this->load->library('email');
$data = array(
'first_name' => $this->input->post('first_name'),
'last_name' => $this->input->post('last_name'),
'email' => $this->input->post('email'),
'phone' => $this->input->post('phone'),
'message' => $this->input->post('message')
);
$body = $this->parser->parse('html_email', $data, true);
$this->email->from('test#test.com', 'Duparc');
$this->email->to('test#test.com');
$this->email->subject('Test Email');
$this->email->message($body);
$this->email->send();
In my opinion the problem does not originate from CodeIgniter. Assuming the mail did not went into a spam box, your customer's provider is probably dismissing your message for some other reason. One reason I can immediately think of is that you are probably trying to send a message from a domain (e.g. test.com) you're not allowed from. My advise is starting to try sending an email with another tool to your french customer (any sendmail or postfix client tool) and to see if he do receive it.
If that succeeds, then the problem probably comes from your forged email (therefore try using a valid domain name). Sometimes removing it completely will work too (it might then be replaced by the external IP).
If not, then the problem comes from your web server's config. I had this problem using postfix where I had to explicitly set the "General Options" > "What domain to use in outbound mail" configuration option to my domain name in order to be accepted by a capricious server which silently dismissed our mail.
If nothing is working, you might also use another mail server which might luckily fix the issue. Here is the code I used to force CodeIgniter using sendmail instead:
$config['protocol'] = 'sendmail';
$config['mailpath'] = '/usr/sbin/sendmail';
$this->email->initialize($config);
We send emails in plain text from PHP using CodeIgniter (v1.7) and also PHPMailer (v5.1). Current production setup uses a cheapie SMTP relay, plan is to switch to a CritSend or SendGrid. We are testing the options now from a Rackspace Cloud server.
When we use SendGrid SMTP all "\r\n" newlines in the emials end up being doubled up, so end up as "\r\n\r\n".
All works fine when using CritSend SMTP and also two other SMTP servers.
SendGrid tech support don't think it is anything to do with their system, but have heard of another client with the same issue and apparently it got solved with a config change on the client's side.
Anyone experienced this?
This isn't critical for us as CritSend works well and seems as good as SendGrid on features, so we will go with them. BUT being a curious type, I just can't let this go :-)
Usual setup: PHP script -> sendmail/Postfix -> external SMTP relay -> ....
To test the different SMTP relays I change the postfix config, only SendGrid gives the extra newlines all other SMTP options work fine. If I dump the email via CodeIgniter email class debug function it looks fine before it goes to postfix.
Alternate setup: PHP script (either CI mail class or PHPMialer) -> external SMTP relay -> ....
To test the different SMTP relays I change the SMTP settings in the CI email config or PHPMialer config. Only SendGrid gives the extra newlines all other SMTP options work fine.
There aren't all that many options to play with as far as I can see. I tried "utf-8" and "ISO-something or other", all newlines on our side are "\r\n"...... seesm like some very obscure bug somewhere.
Any ideas?
OK, a bit more experimenting and these settings make plain text emails go trough SendGrid nicely from PHPMailer:
$mailer->CharSet = "utf-8";
$mailer->LE = "\r\n";
$mailer->Encoding = "quoted-printable";
$mailer->WordWrap = 80;
The "quoted-printable" part is the key.
What worked for me was using actual line-breaks in the PHP text as follows:
// Prepare email
$email = array(
'api_user' => App::emailAPIUser(),
'api_key' => App::emailAPIPwd(),
'to' => $email,
'subject' => 'Thank you for entering ' . App::name(),
'html' => $email_body,
'text' => '
Thank you for entering Competition.
You are now in the running to WIN your prices valued at $6000.
Winners will be notified of their status by the 14th February 2012.
Good luck!',
'from' => 'competitions#company.com'
);