المساعد الشخصي الرقمي

مشاهدة النسخة كاملة : حل مشكلة SMTP error from remote mail server after end of data: 550 Action not taken

Rise Company
03-02-2022, 16:32
حل مشكلة SMTP error from remote mail server after end of data: 550 Action not taken
SMTP error from remote mail server after end of data: 550 Action not taken
مشكلة Email Forwarder الى الجي ميل يصل ولكن معها Mail delivery failed: returning message to sender
X-From-Rewrite: unmodified, actual sender is mailnull


المشكلة :

رغم وضع PTR بشكل صحيح لاي بي السيرفر
الا انه عند التحقق منه فى موقع leafdns.com
تجد احيانا يظهر انه موجود بشكل صحيح
واحيانا اخري يقول لك انه خطا

وتظهر بوضوح احيانا فى ايميلات
gmail / hotmail / yahoo
تجد ان الايميل يصل لك ولكن معه mail delivery failed

حل المشكلة :

انت لديك السيرفر بـ 2 اي بي IP يجب ضبط PTR لكلاهما
اى قم ضبط ptr للاي بى الاول ns1 وكذلك الاي بي الثاني ns2
يمكنك التحقق من هنا

مع العلم انه لا يتم من خلالك اى ليس لع اعداد داخل whm
ولكن بيتم التواصل مع مقدم IP للسيرفر وطلب ذلك منه
فهو الوحيد الذى له صلاحية PTR

تاكد ايضا ان سيرفر مثل التالى


* ملحوظة لم تحل المشكلة حتى الان
جميع الحلول هنا محاولات فقط


Rise Company
29-06-2022, 16:09
هنا بعض الحلول الاضافة ولكن ليست حل للمشكلة
ولكن قد تفيد فى حالات معينة


داخل السي بانيل يوجد خاصية Email Forwarder عند تفعيلها لكى توجه الايميلات الى ايميل على gmail
يصل الايميل بدون مشاكل ولكن ياتى معها ايميل اخر Mail delivery failed: returning message to sender
وبداخل الايميل ان الخطا SMTP error from remote mail server after end of data: 550 Action not taken

على الرغم ان Email Routing مضبوط على Local Mail Exchanger وليس Remote

على الرغم ان Email Deliverability يعطى مؤشر ان الاعدادات سليمة


حل المشكلة :

قم اولا بارسال ايميل test فاضى بدون مرفقات وفى الغالب هتجد ان الايميل وصل
وهنا هتكون المشكلة ان الايميل المرسل له على جوجل فى الغالب والفلتر لديهم
يرفض وصول ايميلك بسبب ان المرفقات attachments من pdf مشبوه انه سبام
لذلك قم بعمل rename فقط للملف واعد الارسال وهيوصلك

فى حالة ظهور الخطا عند ارسال الايميل بدون مرفقات اتبع الحل التالى

Have you set up a new mail server, configured DKIM and SPF correctly, but for some reason you still have email being intermittently rejected when forwarding to Gmail and other services with messages that are unhelpful like: –

SMTP error from remote mail server after end of data: 550 Action not taken

If that’s the case, you may need to set up a DNS PTR record for your mail server’s IP address. It appears that, depending on the circumstances of the forwarded email and the domain performing the forwarding, this step is crucial to ensure smooth email forwarding delivery.
Of course, you should ensure that the PTR record IP address and hostname match what you see in the SMTP header.


Update 31st Oct 2018:
Since writing this article a few days ago, I encountered some further issues with reliable mail delivery, specifically through Exim on cPanel.
Normally, when configuring forwarding, you should also enable SRS (Sending Rewriting Scheme), which adds additional information to the mail headers to inform the receiving MTA that the email has been forwarded and “signed” by the forwarding MTA (in my case, Exim on a cPanel/centOS installation).
While this was enabled in the Exim config, I did not realise that it wasn’t actually operating correctly.
Below is what you SHOULD see when SRS is operating correctly (forwarding to a Gmail account): –

Received-SPF: pass (google.com: domain of srs0=lu0ygv=nl=senderoriginaldomain.com=senderfirs [email protected] designates <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default header.b=HnochmZG;
dkim=pass [email protected] header.s=default header.b=C8B9JAt8;
spf=pass (google.com: domain of srs0=lu0ygv=nl=senderoriginaldomain.com=senderfirs [email protected] designates <your MTA IP> as permitted sender) smtp.mailfrom=”SRS0=Lu0yGv=NL=senderoriginaldomain [email protected]”;

Here’s what it looks like WITHOUT SRS (again, forwarding to a Gmail account): –

Received-SPF: fail (google.com: domain of sender[email protected] does not designate <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of [email protected] does not designate <your MTA IP> as permitted sender) [email protected] omain.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=senderoriginaldomain.com

As you can see, in the SRS example, the sender information is modified to include information about the forwarding domain (i.e. your domain) so that it is clear that your MTA is not trying to forge or spoof the original sender’s domain.
In my case, SRS was turned on properly, however it seems that the cPanel archiving functionality was somehow breaking this on the version of cPanel that I was running. As a workaround, I will be disabling email archiving to ensure that SRS is applied to my forwarded messages and applying any cPanel updates as they are released that will hopefully resolve the issue.

Final Update 3rd November 2018:
Further to my last update, it seems that I had another factor contributing to this issue – Namecheap (my previous provider) had been intercepting my SMTP traffic through the use of a transparent SMTP proxy of some description (they were not forthcoming with information).
It seems that this was also causing mail delivery issues that were causing the likes of Gmail and Microsoft to return 550 back to my server after transmitting messages.
After unsuccessfully attempting to persuade Namecheap to allow me to bypass this technology, I have moved to a new VPS provider and my emails are again being delivered perfectly.


حلول فشلت
updating “Send mail from the account’s IP address” from “On” to “Off”

داخل فايروول csf

Perform reverse DNS lookups on IP addresses. See also CC_LOOKUPS

Email Routing Configuration

داخل whm

Home /
DNS Functions /
Email Routing Configuration

The lowest numbered MX entry currently points to: ns2.rose-eg.com
Email Routing for “ns2.rrrrr.com” (The domain is owned by “nobody”).

Local Mail Exchanger

Rise Company
03-07-2022, 00:38
Exim by default listens on 587, allowing mail clients to connect over this port. The issue you're experiencing occurs when your provider closes port 25 but exim is not listening on an alternate port. You can change this by going to WHM>>Service Configuration>>Service Manager and select Exim Mail Server (on another port) and allow port 26.

Rise Company
03-07-2022, 00:39
Same exact problems here (and I dont see a more recent thread).

It looks to me like this is a cached response as I dont even see a delivery attempt, just instafail at 'lookuphost' without a reason. I do not think this is a resolver problem, I can look stuff up no problem, and ping it (careful, host(1) ignores /etc/hosts, so could be something hidden in there, not in my case), but I do not get a proper error response

2019-05-23 12:43:50 cwd=/tmp 4 args: send-mail -i -- [email protected]
2019-05-23 12:43:50 1hTqoo-0007EE-LC <= [email protected] U=root P=local S=517 T="test" for [email protected]
2019-05-23 12:43:50 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1hTqoo-0007EE-LC
2019-05-23 12:43:50 1hTqoo-0007EE-LC ** [email protected] R=lookuphost T=remote_smtp: all hosts for 'mydomain.com' have been failing for a long time (and retry time not reached)
2019-05-23 12:43:51 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1hTqoo-0007EE-LC
2019-05-23 12:43:51 1hTqop-0007EN-0G <= <> R=1hTqoo-0007EE-LC U=mailnull P=local S=1866 T="Mail delivery failed: returning message to sender" for [email protected]

I can telnet to the mx record for the mydomain.com above port 25 no problem.

How do I force it to try again to see what the actual failing reason is? Setting log_selector to +all doesnt help with any additional detail.


Never saw this mentioned in the few threads about this problem here.


cd /var/spool/exim/db
rm wait-dkim_remote_smtp* retry* wait-remote_smtp*
service exim restart

And then new and queued mail got sent out (because whatever other underlying problem I had solved earlier with another change, but somehow exim didnt get told about it despite having restarted it a few times to increase logging or other reasons).