What Should Mail Custom DNS Records Be With Vercel - hosting

I'm struggling to understand how to set up my mail server to work on my NextJS blog hosted with Vercel - I am not receiving any e-mail (I can send successfully).
My set-up:
NextJS front-end hosted on Vercel.
WordPress blog hosted on examplehosting.
Domain name purchased from exampledomainco.
At the moment I have my DNS records (for mail) set up as custom DNS on exampledomainco as:
mail.example.co.uk A 3600 76.76.21.21
mail.example.co.uk MX 86400 example.co.uk.
Can anyone spot what I'm doing wrong?

Realised that I had the name and content of the MX record the wrong way around, and it should have been:
example.co.uk MX 86400 mail.example.co.uk.
And the A record should have been pointing to my host IP - not Vercels, which is 76.76.21.21
Thanks to ChatGPT for the assistance!

Related

Laravel response differs when using Amazon ELB - use case: AirBnB ical Importer

Background: We are using Laravel v8.83.5 running on nginx and PHP 7.4 Amazon Linux EC2 instance which is powered by an Elastic Load Balancer. We provide an iCalendar feed as a URL to customers which they can import into AirBNB, VRBO and other OTA.
Issue:
When our iCal Feed URL is added to VRBO, it's accepted and parsed by it.
When we use our iCal Feed URL on AirBNB, it throws an error 'We're having trouble syncing this calendar. Try importing it again.'. The same URL downloads an .ics file when visited from the browser and also works when importing into another iCal compatible calendar. The syntax is valid as has been checked on https://icalendar.org/validator.html as well.
To identify the issue,
we tried a different URL on another Digital Ocean server which returns the same response but does not have an ELB behind it and also uses nginx and php 7.4. That URL is accepted by the AirBnB importer. A screenshot of the response headers for this second server's request is attached here
A screenshot of the response headers for which the request fails on AirBNB is attached here.
When trying via postman, both requests return the same response content. The general headers are same as well.
On checking nginx access logs, the response code return to AirBNB by the servers is 200 in both cases.
If we pass a static file into the AirBNB importer from the server that's behind the ELB, the URL works on AirBNB.
We have tried
disabling gzip and cache control in nginx on the response being returned.
switching between apache and nginx on the server that sits behind the Amazon ELB.
Removed all global middleware added by Laravel on that route

Expected response code "250" but got code "550", with message "550-Requested action not taken: mailbox unavailable 550 Sender address has null MX"

I have a Laravel 9.x site that I'm hosting on IONOS (shared-hosting).
In my site, I utilize mail a lot. So I'm sending mails to my customer frequently. While developing the system - I was using MailTrap.io - but for deployment, I need all the mails to go to my IONOS Mail Account i.e info#domain.com - for that, I need to use IONOS' Mail Configuration.
Following is my mail config (censoring out private info):
MAIL_MAILER=smtp
MAIL_HOST=smtp.ionos.com
MAIL_PORT=587
MAIL_USERNAME=############.com
MAIL_PASSWORD=################
MAIL_ENCRYPTION=tls
MAIL_FROM_NAME="${APP_NAME}"
MAIL_FROM_ADDRESS=#############.com
This is the error I'm getting:
This is the piece of manual documentation I got from IONOS' Dashboard:
How do I fix this? What is causing this issue? Like I mentioned before, all of it was working fine with MailTrap.io - so I'm really curious what am I doing wrong.
Thank you :)
As per ionos.com documentation
550 Sender address has null MX
The domain from which you send email has a configured No Service MX record (zero MX). The IONOS SMTP recipient rejects such emails
Delete the No Service MX entry in the DNS settings of your domain. For more information about a No Service MX entry, see RFC 7505.

Laravel Vapor deploys and then fails to respond to requests

I just deployed a Laravel App using Vapor, and received the following message. I don't believe that I changed anything (a few html blade lines).
Caching Laravel configuration{"message":"Argument 1 passed to
Symfony\Component\HttpKernel\Exception\HttpException::__construct()
must be of the type int, string given, called in
/var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php
on line
1014","context":{"exception":{"class":"Symfony\Component\Debug\Exception\FatalThrowableError","message":"Argument
1 passed to
Symfony\Component\HttpKernel\Exception\HttpException::__construct()
must be of the type int, string given, called in
/var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php
on line
1014","code":0,"file":"/var/task/vendor/symfony/http-kernel/Exception/HttpException.php:24"},"aws_request_id":null},"level":400,"level_name":"ERROR","channel":"production","datetime":"2019-09-27T13:18:45.338555+00:00","extra":{}}
The website now just shows {"message": "Internal server error"}
Did I do this, or is this a Laravel/Vapor bug?
This happens when you use gateway_version 2. As per vapors documentation, you need to use an external DNS like Cloudflare for HTTPS redirection. https://docs.vapor.build/1.0/projects/environments.html#gateway-versions
If you choose to use API Gateway 2.0 and would like to support HTTP to
HTTPS redirection, we currently suggest using Cloudflare as an
external DNS provider for your Vapor application. Cloudflare not only
provides DNS, but serves as a reverse proxy to your application and
features an option for automatic HTTP to HTTPS redirection.
After a Vapor deployment is completed, Vapor will provide you with
CNAME records for the domain(s) associated with your environment.
These records will point the domain to your Lambda application. You
should manually add these values as CNAME records within the
Cloudflare DNS dashboard.
In addition, when using Cloudflare, you should set your Cloudflare SSL
/ TLS mode to "Full". The "Always Use HTTPS" configuration option may
be found under the SSL / TLS menu's "Edge Certificates" tab.
A simple solution would be to use Gateway Version 1.

Magento's API not working properly on Nginx server

I have three Magento website with multisite setups and hosted on Nginx server. there is only one admin panel and a front domain is different for all the three sites.
So, My issues are below:
Using Magento's API I am calling SOAP request to my website and try to update the product information, but the Nginx server returns the 302. Below I provide more details:
Using POSTMAN software, I am calling the API call on the server, at that time product's information's are updated successfully but server gives response 302 Moved Temporarily.
Below, I have provided screenshots:
Also, when I am calling the same API to my local server (local machine), it will give me 200 ok statuses. This issues occurring on my Nginx server only.
if you have any suggestion or ideas for resolving my problem so please provide us.
Thank You,

1and1 domain name redirect HTTP or Frame with Heroku host?

So I purchased a domain from 1and1, say it's www.mysite.com, and am hosting my app on Heroku myapp.herokuapp.com. I have two options for forwarding the domain - HTTP and Frame. HTTP forwarding seems to just redirect my URL from www.mysite.com to myapp.herokuapp.com, which isn't what I want. But I am having a problem with Frame redirecting - if I navigate on my site to various pages (e.g. myapp.herokuapp.com/users), it will still say www.mysite.com on the top, but not www.mysite.com/users. How can I get the URL path to display correctly?
You don't want to use the (i)frame method - it's bad practice and you'll get the issues you're having now.
What you probably want to do is:
Attach www.yourdomain.com to your Heroku app (via the web interface or the CLI[1])
Set up a CNAME record to point www to yourapp.herokuapp.com with your DNS provider, or use the Zerigo DNS[2] add-on if you don't have DNS hosting already (sounds like you do)
(Optional) Set up a re-direct to direct http://yourdomain.com to http://www.yourdomain.com, via your DNS provider/domain registrar - this is optional, but useful as Heroku does not recommend pointing your root domain (yourdomain.com) to their A records in case they change.
(Optional) Re-direct http://myapp.herokuapp.com/ to http://www.yourdomain.com/ from within your application code or similar (e.g. config.ru if you're using Rack to serve your content)
[1] https://devcenter.heroku.com/articles/custom-domains
[2] https://addons.heroku.com/zerigo_dns

Resources