I've tried to move my domain from GoDaddy to Yandex Connect
And in the admin setting about my domain, I see:
MX records for this domain have not been set up
But MX record added automatically
Host: #
Record type: MX
Record value: mx.yandex.net.
Priority: 10
And it's look like in docs
I wrote a mail to support, but wait for an answer too long
3 months have passed and I've got a letter from Yandex about this. Maybe it can help to somebody :)
Hello, Igor!
We apologize for such a long wait for a response! For technical
reasons, your message came to us just now.
Your domain is currently not configured with the MX record required
for mail operation: https://yandex.ru/support/connect/dns/mx.html. It
must be configured on the servers to which your domain is delegated:
Name Server: NS77.DOMAINCONTROL.COM
Name Server: NS78.DOMAINCONTROL.COM
Please add a MX record with priority 10 and value mx.yandex.net. (the
dot at the end of the server name is required if your control panel
does not add it by default).
After the necessary settings have been made, and the information has
time to update (this can take up to 72 hours), you can check the
operation of the mail.
I don't have already this problem because I've return my domain back to GoDaddy and don't have needs in domain for mail. If this helps to You let me know. I'll sign this answer as correct
I got the same error message, while a difference for me is that I added the MX records to my current GoDaddy domain according to their guide.
With third party tools, I can find my MX record has been propagated correctly, but I still get the error saying "MX records for this domain have not been set up".
Not sure how long Yandex takes to refresh my MX records status. Let me wait for couple hours, will post an update if it goes through.
Related
in my organization we have a mailbox that receives email from different sources (about 5) everyday, set to track all incoming emails in the CRM.
All the mails are correctly tracked on the CRM every day, except for one that always fails (same source, similar content every day).
If I send the exact same email from another address, the mail is correctly synchronized with the CRM, so I think it could be something related with Exchange.
This is the message I get if I open the mailbox record:
An unknown error occurred while receiving email through the mailbox "xxxxxx".
The owner of the associated email server profile xxxxx has been notified. The system will try to receive email again later.
Email Server Error Code: Exchange server returned UnknownIncomingEmailIntegrationError -2147220970 exception
Looking for this specific message didn't get me any result, while just searching the error code I found out it could be something related to plugins.
Unfortunately there is no plugin that fires on email creation, same for workflows and so on. By the way, sending the email from another address just works fine.
Has anyone ever had such a problem? Is there some place where I can find other logs and dig deeper in the problem?
Thanks in advance.
For anyone else experiencing this issue: I received the error code -2147218683, which is different, but it turns out this was due to the user in question not having the right security role. Gave the account sys admin and the error went away.
All I have a fully working magento store but i'm having issues, when a customer purchases something they're not getting an email confirmation and I dont know why, everything is set up correctly, we receive emails when a customer submits items they want samples of they come through fine, even when you goto the backend and view the invoice and select send email invoice they don't get an email, I have no idea why this isn't working, any help would be greatly appreciated.
I'm using paypal payments pro as a payment method.
First of all, Magento 1.9+ send transactional emails as "background process" using the Magento crontab system. If you haven't already setup cron for your Magento store then you need to setup now for sending emails.
You can checkout this guide on how to setup the Magento cronjob -
http://www.magentocommerce.com/knowledge-base/entry/ce18-and-ee113-installing#install-cron
OR
Follow the steps below to setup cron job -
First of all make sure you have set up cron tasks in the `
Magento admin under System > Configuration > Advanced > System > Cron
The default settings are:
Generate Schedules Every 15
Schedule Ahead for 20
Missed if Not Run Within 15
History Cleanup Every 10
Success History Lifetime 60
Failure History Lifetime 600
You then need to go into your hosting control panel and set up cron jobs. In cPanel it’s under Advanced > Cron Jobs. Set them up to run every five minutes and use this command:
php -f /home/username/public_html/cron.php
Check that the above path is correct and that the file cron.php is actually there in the root of your Magento installation.
If this is not the case, you can check the database table: core_email_queue
The emails that should have been send should be in this queue, if not you should check your system configuration again, and maybe check on the store view your orders are from, to make sure the setting is not different under specific store view.
If the emails are there and have a date in the column processed at. You should check your Servers email log, since the receiver might be rejecting your emails, If its on a linux machine, its usually found in /var/log/mail.log
We have written a blog post here explaining how to setup CRON in Magento, i think this might explain in great detail.
There are various things this could be, but if the other emails are working it sounds like a config issue, so check this.
In admin, take a look in
System > Configuration (TOP MENU)
Then;
Sales Emails (LEFT MENU),
Check which contact is sending the email - eg Sales Rep. While you're here, add your personal email to the 'Send Order Copy To' field for testing - make sure it's not the same domain as the website, so like a gmail.com address or similar. Also check what email template is set and make sure it exists. If 'default from locale', check;
app/locale/[DEFAULT COUNTRY CODE]/template/email/sales/order_new_guest.html
app/locale/[DEFAULT COUNTRY CODE]/template/email/sales/order_new.html
Now go and check the email address set for the sender (New Order Confirmation Email Sender) - eg Sales Rep, these are in;
Store Email Address (LEFT MENU)
Ensure there is a value for email address and name, and it is correct. If it is, go and place an order using another personal email address at a different domain like gmail etc (not the same email address you set for the copy).
Hopefully the emails you do or dont recieve now will help you corectly trace the issue.
EXTRA
If you still receive no emails, couple of things to look at;
Check System > Config > Advanced and make sure smtp isnt disabled (seems unlikely as your other emails are sending)
Make sure paypal pro is setting the status to processed
Try changing the email address being used to send them, eg Sales
rep. Try changing this to an email address with a different domain,
such as gmail.com etc. If this works, then you need to look at how
your domain and email has been setup on the server.
Check your error logs /var/logs/
I would like to configure Heroku and Mailgun to send email from and allow me to receive webhooks (which are POSTs Mailgun sends notifying me of email sending statuses) at a [myapp.]herokuapp.com domain while buying as few additional things as possible. I don't want to buy another domain name, but it doesn't appear that I can avoid that. I'd like to avoid buying another SSL endpoint; it doesn't appear to be necessary and I don't need privacy. What do I need to buy?
The cheapest way to do what you want is to use a custom domain name, add it to Heroku, then verify your domain with mailgun.
You can add custom domains to your Heroku app by running: heroku domains:add www.mydomain.com
Once you've done this (and updated your DNS provider to point to yourapp.herokuapp.com, you can then modify your DNS records for Mailgun to verify your domain.
Once you have that working, you should be good!
Since you can't modify Heroku's DNS servers, you need to do it this way.
This is more a subquestion as the answer.
Just to send emails, I think you can
have Free plan and send to allowed (max 5) recipients,
have Concept plan and send to all recipients; you must enter credit card but you can limit count of messages to 10000/month which is free. For this you will need your domain, however, when you will use a subdomain like myheroku.example.com in TXT DNS-entries, then you can use such domain for any other goals (ie send from more servers, point to other IP or so).
Could somebody confirm this? or make it more clear...
As a team we're currently investigating a strange occurrence. It doesn't seem to apply to all orders by any means, but it is affecting a large number of customers based on the logging we've added to the noItems.phtml page.
Please note: I'm not really expecting an answer as I assume this is a problem we have to solve ourselves based on addons, and our server configuration (three servers for loading balancing). However, I am looking for possible ideas and/or whether this is something somebody has come across previously.
What we've done so far, and what we know:
User enters their card details in the SagePay iFrame;
User purchases an item via SagePay -- order is successful;
Some users are sent back to the success page;
Some users don't see the success page (phoned to confirm a handful) but instead return back to the empty basket;
We're still investigating, but we find it ever so strange how a user would return to the empty basket page. We've added logging to the noItems.phtml and we can see that some users are getting assigned another session ID after a successful transaction. This seems to be the problem, but why the user is being assigned another session ID after a SagePay payment isn't easy to comprehend.
Has anybody else experienced a similar issue with SagePay/Magento? And if so, what steps did you take to solve?
Our Sage Pay Support team would be happy to look at the transaction logs (within 72 hours of the transation being submitted) and help you determine the reason for the failed transactions on 0845 111 4455 24/7.
You reply to the Notification URL when you acknowledge receipt of our response. You have 20 seconds to response. You need to send the Status (OK, Error or Invalid), Status Detail and Redirect URL. We then send the shopper back to your Redirect URL.
A few suggestions would be:
If we can't reach your Notification URL, check you have ports 443 and 80 open. Check you don't have a DNS issue.
If you are receiving the notification from Sage Pay to confirm the status of the transaction via the Notification URL. Check the information you are sending is in the correct casing, that it is not empty data and that your website is not spooling and check whether the success/failure URL is a valid landing page.
All our system needs is the Status Deatil, 'Status = ' and 'RedirectURL =' fields with the appropriate values assigned, separated with Carriage-Return and Line-Feeds (as specified in the protocol) . Nothing else is required. The response you send should also be text/plain message, not text/html or any other MIME type.
If the customer is being sent back to an empty basket, check whether your website is doing a job in the background such as writing to a databse, preparing confirmation emails to the back office before sending the customer to the payment page. Test whether your server can handle the amount of transactions coming through from Sage Pay. Or are you truncating the NEXT URL?
Regarding a session ID, each transaction is assigned a unique Sage Pay ID called a VPSTxID which is used to identify the transaction. We can take a look at the transactions you are referring to if you are getting several session IDs to discuss further if you would like.
Sage Pay Support.
Check the action that pushes the user to the success page on successful purchase. Maybe its something like target _parent. Maybe its something where its trying to load the success page in the iframe. Or maybe its timing out on sagepay when trying to redirect.
From what I've been reading the SPF can be used to validate email addresses by sending commands (rather than an actual email) such as HELO. I've managed to pick up a basic grasp of the policy but I can't get my head around how I'd go about solving the following problem:
I've got a number of email addresses attached to contacts in a CRM system and I'd like to find out if the email addresses are valid and still in use.
Currently we're using a REST Web Service (http://emailinspector.co.uk/) which returns "Ok" (if its ok... duh), "Bad" (if its not valid or not in use) or "Unknown". For Unknown, you are also provided some notes on why it came back with that, i.e. you are told if the Mailbox is full or if its a well known DEA.
I'd like to be able to program a script that can replicate this functionality and from what I've worked out it should use the Sender Policy Framework to do this? The problem is I don't know how I'd go about returning such precise information for "Unknown" email addresses.
Ideas and thoughts?
Actually SPF is just a text record, with some "hints" to let you know if an IP address or mail server is "allowed/Authorized" to send email for that domain. It doesn't tell you anything about an individual email address in that domain..
for example
[doon#qix:~] host -t txt labratsoftware.com
labratsoftware.com descriptive text "v=spf1 a -all"
The SPF record for one of my domains says that only the a record for the domain is authorized to send email for labratsoftware.com, and that if it doesn't come from that IP then it should be rejected (-all).
So the best you can do with SPF is tell that a received email came from an authorized host, and then use that information to help decide if you want to reject it or not.
The best way To test the validity of an email address you have, is to email it, and see if it bounces. You can use options like VERP (http://en.wikipedia.org/wiki/Variable_envelope_return_path) to automate the bounce handling. You can also try and connect to the MX records listed for the domain and try to deliver a message that way. Some Mail servers support verify (But most admins disable this to prevent information leakage). You can use RCPT TO to see if the server accepts it, but even if it does , you have no way of knowing if it will actually make it to their INBOX. My guess is that is what the API you are currently using is doing. And unknown are just ones that either don't answer, greylist, etc.