554 5.7.1 : Relay access denied email hatası ve çözüm

Geçiş Erişimi Reddedildi, yaygın bir e-posta hatasıdır. Bu, sunucunun bir e-postanın başka bir posta sunucusuna gönderilmesine izin vermediği anlamına gelir. Bu hatanın en yaygın nedenleri şunlardır:

• Gönderen, giden posta sunucusunda kimlik doğrulaması yapmadı
• Alıcı sunucusu, gönderen sunucunun bir spam kaynağı olduğunu veya güvenlik kontrollerinde başarısız olduğunu belirledi.

Aktarma erişimi reddedildi hatası tam olarak nedir?

Bir e-posta gönderdiğinizde, e-posta istemciniz e-postayı kendi posta sunucunuza gönderir. Posta sunucunuz daha sonra bunu alıcıların e-posta sunucusuna (relays) üzerinden gönderir. E-posta sunucuları daha sonra bunu alıcıya teslim eder. E-postayı göndermeden önce kendi giden posta sunucunuzda başarıyla kimlik doğrulaması yapamazsanız, sunucunuz e-postanın alıcılar sunucusuna aktarılmasını reddeder. Bu, bir spam göndericinin uygun kimlik bilgileri olmadan sunucunuzu kullanarak posta göndermesini önlemek için yapılır. Doğru şekilde kimlik doğrulaması yaparsanız, yine de bu hatayla karşılaşabilirsiniz. Alıcı sunucusu, spam filtreleri e-postayı istenmeyen posta olarak veya bir istenmeyen posta kaynağından geliyorsa (IE: sunucunuz bir kara listede) geçişi reddedebilir. Bu olursa, sunucuları e-postayı reddeder ve yeniden geçiş erişimi reddedildi hatası alırsınız.

Kullanıcı olarak bu hatayı aldığınızda ne yapmalısınız?

Yapmanız gereken ilk şey, e-posta sağlayıcınızla e-posta ayarlarınızı doğrulamaktır. Doğru Posta sunucusuna, Kullanıcı Adına ve Parola’ya sahip olduğunuzdan emin olun. Ayrıca, SMTP Kimlik Doğrulaması kullanmanız gerekip gerekmediğini veya SMTP’den önce POP kullanmanız gerekip gerekmediğini kontrol edin. SMTP’den önce POP kullanıyorsanız, mobil cihazlarda ara sıra sorun yaşayabilirsiniz. Bunun nedeni, veri ağınızın zayıf kapsama alanı nedeniyle değişmesi veya bir WiFi erişim noktasından diğerine geçmenizdir. IP adresiniz değişiyor olabilir, bu nedenle artık başlangıçta kimlik doğrulaması yaptığınız IP adresi yerine yeni bir IP adresinden e-posta gönderiyorsunuz. Bunu önlemek için, e-posta sağlayıcınızın da bunu etkinleştirip etkinleştirmediğini test etmek için SMTP Kimlik Doğrulamasına geçmeyi deneyebilirsiniz. Bu başarısız olursa, e-posta sağlayıcınıza başvurmanız ve posta sunucusunda SMTP Kimlik Doğrulamasını etkinleştirmelerini istemeniz gerekebilir. Son olarak, alıcıların sunucusunda devreye giren spam filtreleri olabilir. Durum böyleyse, bunu nasıl önleyeceğiniz konusunda daha fazla bilgi almak için e-posta sağlayıcınızın posta sunucularının günlük dosyalarına bakmasını sağlamalısınız.

Posta sunucusunun sahibi olduğunuzda ne yapmalısınız?

Bir sunucu sahibinin bununla karşılaşmasının 2 nedeni vardır.

• Bir son kullanıcı bir e-posta göndermeyi denedi ve bu hatayı geri dönerek kendilerine gönderdiler
• Sunucunuzdaki bir kullanıcıya e-posta göndermeye çalışan bir kişi hatayı alıyor ve size bildirdi

Günlük dosyalarınızda buna benzer bir şey görmelisiniz.

2016-10-10 14:05:23 1btaGg-0004ei-Mf ** [email protected]  R=dkim_lookuphost T=dkim_remote_smtp H=someserver.com [192.168.0.1] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes: SMTP error from remote mail server after RCPT TO:<[email protected]>: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied

Kullanıcı kimlik doğrulama sistemi başarısız olabilir

TÜM son kullanıcılarınız bu hatayı alıyorsa, bu büyük olasılıkla budur. Sunucu kimlik doğrulama yapılandırmalarını kontrol etmeniz gerekir. Örneğin, bir Postfix sunucusu çalıştırıyorsanız, SMTP kimlik doğrulamasının etkinleştirildiğinden emin olmalısınız. Bunu yapmak için, yapılandırma dosyasını kontrol edin ve “smtpd_recipient_restrictions” ayarının şu şekilde yapıldığından emin olun

• smtpd_recipient_restrictions = permit_sasl_authenticated

Bazen, sunucu yazılımı güncellendiğinde, konfigürasyonları değiştirebilir. Dolayısıyla, sunucunuz başından beri iyi çalışıyorsa, aniden durur, muhtemelen yazılım yakın zamanda güncellenmiştir. Örneğin, cPanel her gece otomatik olarak güncellemeleri kontrol eder. Bazı şeyleri bozan bir güncelleme yayınladıkları zamanlar olmuştur ve ya yeni bir güncelleme çıkarılmıştır ya da bazı ayarları manuel olarak değiştirmeniz gerekir. Manuel olarak güncelleme yapıyorsanız, önce güncellemelerinizi test edebileceğiniz bir test sunucusu kurulumuna bakmalısınız. Ardından, test sunucunuzda her şey yolunda gidiyor gibi görünüyorsa, bunu canlı ortamınıza sunabilirsiniz.  

Kimlik doğrulama veritabanı bozulmuş olabilir

Odin Plesk gibi sunucularda kullanıcı adı, şifre ve doğrulanmış IP adresini bir veritabanında saklarlar. Herhangi bir veritabanı gibi bu veritabanı da birçok nedenden ötürü bozulabilir. Tabloyu basit bir komut satırı ile onarabilirsiniz.

• mysqlcheck -r psa smtp_poplocks -uadmin -p

Bu smtp_poplocks adlı tabloyu kontrol edecek ve bozuksa onu onaracaktır.  

Sunucunuza gelen üçüncü taraf postası, sunucunuzdaki anti-spam kontrollerinde başarısız oluyor

Birinin son kullanıcılarınızdan birine e-posta göndermeye çalıştığına dair raporlar alıyorsanız, ancak e-postayı gönderen kişi sunucularınızdaki spam filtreleri tarafından reddediliyorsa, posta günlüğünüzde buna benzer girişler görebilirsiniz.

2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] sender verify fail for <[email protected]>: response to "RCPT TO:<[email protected]>" from senderserver.com [yy.yy.yy.yy] was: 554 <[email protected]>: Relay access denied
2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed

Bu hata, myserver.com’un, Gönderen Doğrulaması (Gönderen Doğrulama Belirteci) adlı bir spam kuralı nedeniyle gönderen sunucu.com’dan gelen bir e-postayı reddettiğini gösterir. Bunu düzeltmek için işte 3 olası çözüm

1. Bu genellikle meşru e-postada meydana geliyorsa ve aynı anti-spam kuralından kaynaklanıyorsa, o belirli kuralı devre dışı bırakmayı düşünebilirsiniz.
2. E-postayı gönderen sunucu güvenilirse, sunucularını beyaz listenize ekleyebilirsiniz. Bununla birlikte, bu, sunucularından gelen tüm postaların herhangi bir spam kontrolü olmadan geçmesine izin vereceğinden, buna dikkat edin. Dolayısıyla, sunucuları saldırıya uğrarsa ve sunucunuza spam göndermek için kullanılırsa, tüm bu spam iletilir.
3. Gönderen sunucuyla iletişime geçin ve sunucuyu istenmeyen posta önleme kontrollerinize uygun hale getirmek için sunucularını yeniden yapılandırmalarını isteyin.

Anti-spam kontrolleri, her sunucunun etkinleştirmiş olması gereken bir şeydir, ancak çok agresif olmak istemcilerinizin önemli e-postaları kaçırmasına neden olabilir. Bu nedenle, servis sağlayıcıların çoğunun yapılandırıldığı gibi, RFC uyumlu spam kontrollerine bağlı kalmak en iyisidir.  

Alıcıların sunucusundaki anti-spam kuralları nedeniyle kullanıcılarınız geri dönüyor

Son kullanıcılarınız aşağıdaki gibi bir hata mesajıyla geri dönen e-posta alıyorsa:

• 454 4.7.1: Geçiş erişimi reddedildi

Bu durumda sunucunuz, alıcıların sunucu anti-spam kurallarında veya güvenlik duvarı kara listelerinde büyük olasılıkla başarısız oluyor. Bu durumda, geri dönen e-postanın başlıklarını görüntüleyin. Neden reddedildiğine dair ayrıntılarınızı vermelidir. Tipik olarak, sunucunuzun RBL’lerde (Gerçek Zamanlı Kara Delik Listesi) yer almasından kaynaklanır. Http://mxtoolbox.com ve http://multirbl.valli.org gibi sunucunuzu birçok kara listeye göre kontrol edebileceğiniz birkaç site vardır . Bu listeler size herhangi bir kara liste olabileceğinizi söyleyecek ve genellikle bu RBLS’ye bağlantılar verecek, böylece listeden kaldırma talebinde bulunabilirsiniz. Ancak bir sunucuyu listeden çıkarmayı denemeden önce, kara listenin nedeninin çözüldüğünden emin olmalısınız. IE: Sunucunuzda bir spam gönderen varsa, kaldırılmıştır.

Son kullanıcının posta istemcisi yanlış yapılandırılmıştır.

Genel olarak e-posta sorunlarıyla ilgili aramalarımızın ve destek biletlerimizin yalnızca% 80’i, müşterinin yanlış ayarlara sahip olmasından kaynaklanmaktadır. Sunucunuzun düzgün çalıştığından eminseniz, sunucunuzla çalışmak üzere her şeyin doğru şekilde yapılandırıldığından emin olmak için istemcinizle ayarları gözden geçirmelisiniz.