IIS / SMTP - e-postalar mailroot / Queue'da sıkışmış

IIS alma dizini içinde SMTP üzerinden e-posta göndermeye çalışıyorum. Maalesef, e-postalar sadece mailroot / queue klasörüne giriyor ve orada kalıyorlar. Asla gönderilemediler.

Bunun neden olacağını ve problem için potansiyel bir çözüm olduğunu bilen var mı?

Sıraya sıkışmış Files ile benzer bir sorun vardı. IIS yöneticisinde, SMTP Sanal Sunucusu> Özellikler> Delievery> Giden Bağlantılar. İçin seçenek Limit number of connections tokontrol edildi ve değer oldu 0. Böylece hiçbir zaman giden bağlantı yapmadan, e-postaların sunucudan asla ayrılmamasına neden olacak şekilde yapılandırıldı. Bu seçeneğin işaretini kaldırdım ve SMTP sunucusunu yeniden başlattım ve her şey yolunda gitti.

Bugün bu sorunu yaşadım.

'Basit Posta Aktarım Protokolü (SMTP)' hizmetini yeniden başlattıktan sonra yeniden çalışmaya başladı.

Sadece kayıt için: hatalı bir DNS ayarları nedeniyle sunucunun artık isimleri çözemediği bir durum vardı. Ortaya çıkan davranış tam olarak tanımladığınız davranıştı.

IISRESET bunu benim için düzeltti. SMTP servisini sıfırlama çözümüne benzer olduğuna inanıyorum, çünkü bu hizmet IIS'ye bağlı. Posta başlatıldıktan sonra C: \ inetpub \ mailroot \ Queue içindeki posta kaybolmaya başladı!

Son zamanlarda bu sorunla karşılaştım. Benim durumumda, bir ağ bağdaştırıcısındaki DNS sunucusu tanımında bir sorun olduğu ortaya çıktı (bunun nedenini bilmemek için iki nedeni var). Belirlenen DNS sunucusu, normalde bu ağda kullanılan normal "8.8.8.8" yerine "127.0.0.1" olarak ayarlandı. Bunu doğru değere değiştirdim, SMTP sunucumu yeniden başlattım ve sıradaki e-postalar hemen dağıtıldı.

DNS tanımı sorununa bakmak için bunu nasıl öğrendim:

• Test edilecek bir mx sunucusu bulmak için nslookup kullanılır (5 ya da 6 farklı test edildi)
• Sunucuya telnet yapmaya çalıştım (her seferinde güvenlik duvarı sorunları hakkında düşünmeme neden olan "bağlanamadı" mesajı ile karşılaşıldı)
• Test edilen mx sunucusunun değerini pinglemeye çalıştı (her seferinde bir "ana bilgisayara bağlanamadı" mesajı ile karşılaşıldı)

Umarım bu başkasına yardımcı olur, başlangıçta bakmayı düşündüğüm bir şey değildi.

Tecrübelerime göre, bu genellikle IIS SMTP'nin geçici (4xx yanıt kodu) bir hata göndermeye ve karşı karşıya kalmaya çalışmasından kaynaklanmaktadır. IIS SMTP hizmeti için günlüğü açtınız ve günlüğü incelediniz mi? Üzgünüm, hepsi açıksa, nedenini veya düzeltmeyi günlüğün ne gösterdiğini bilmeden bilmek zor.

Sanırım sorun sistemde IPv4 ile IPv6 arasında bir karışıklık olabilir, bu yüzden localhost belirlediğinizde, varsayılan IPv6 protokolü seçilir. Bugün aynı sorunu yaşamaya başladım ve bu bir tesadüf olabileceğine rağmen, ana bilgisayarlardaki IPv6 adresine localhost başvurusu yapıldıktan sonra düzeldi (ayrıca SVN kuruyorum). Öyleyse işte tam da kurulumum:

1. IIS7'de, seçilen sunucum olarak localhost ile etkinleştirilmiş "SMTP sunucusuna teslim et" seçeneğim var.
2. IIS6'da erişime yalnızca 127.0.0.1 olarak ayarlanmış, gelen veya giden kimlik doğrulaması yok.

Bütün gün ayarlarla uğraştım, bu yüzden dürüst olmak gerekirse, şu anda çalışmakta olduğu gerçeğini başka neler etkilediğinden emin olamadım. Umarım bu olsa da, en azından biraz yardımcı olur.

Bakılacak ilk yer sunucu günlük dosyalarıdır. Bu, sunucunuzun belirli ana bilgisayarlara göndermede sorun yaşayıp yaşamadığını size söyleyecektir. Bunun gerçekleştiği zamanların çoğu (deneyimlerime göre) genellikle DNS (sonunda ya da uzaktan) suçlu.

SMTP sunucusu, postayı göndermek için bir SMTP ana bilgisayarı / ağ geçidi arıyor.

Localhost'a göndermeye çalışıyorsanız, localhost IP'si ağ geçidi olacaktır. Gmail veya hotmail gibi harici bir e-posta adresine göndermeye çalışıyorsanız, ISS'nizin posta ağ geçidini akıllı ana bilgisayar olarak eklemeniz gerekir.

Akıllı bir ana bilgisayar kurmak için:

1. IIS Yöneticisi'nde SMTP sanal sunucusunu sağ tıklatın ve ardından Özellikler'i tıklatın.
2. Teslim sekmesini ve ardından Gelişmiş'i tıklayın.
3. Akıllı ana bilgisayar kutusuna akıllı ana bilgisayar sunucusunun adını yazın. Bir adı temsil etmek için bir dize yazabilir veya bir IP adresi girebilirsiniz.
4. SMTP hizmetinin uzak mesajları doğrudan akıllı ana sunucuya iletmeden önce doğrudan iletme girişiminde bulunmasını istiyorsanız, akıllı ana bilgisayara göndermeden önce Doğrudan teslimatı dene onay kutusunu işaretleyin. Varsayılan ayar, tüm uzak mesajları doğrudan göndermeye çalışmak yerine akıllı ana bilgisayara göndermektir.

E-posta servisini bir ana bilgisayardan diğerine değiştirdikten sonra da aynı sorunu yaşadım (yenisi Office 365). Çok sayıda deneme yanılma sonrasında nihayet bunu yaparak çalışmaya başladı:

1. E-posta etki alanımı IIS 6'ya "uzak" bir etki alanı olarak ekleyin. (Bu, O365'te barındırılan ve tüm kullanıcı hesaplarının kullandığı etki alanıdır.)
2. IIS 6'da, bu etki alanını çift tıklatın; "Alan adı" altında, "Tüm postaları akıllı ana bilgisayara yönlendir" i seçin ve sunucunuzu girin (benim durumumda, "smtp.office365.com"). Ayrıca, "Gelen postaların bu etki alanına aktarılmasına izin ver" kutusunu işaretleyin.
3. IIS 6'da SMTP sanal sunucusunu> Özellikler'i sağ tıklatın.
   • Genel sekmesi: Gelişmiş'i tıklatın ve yerel sunucunuzun IP adresini ve 587 numaralı bağlantı noktasını ekleyin.
   • Erişim sekmesi: "TLS şifrelemesi iste" seçeneğinin işaretli olduğundan emin olun. IIS 7'de e-posta etki alanımın adıyla bir etki alanı sertifikası oluşturmak zorunda kaldım.
   • Erişim sekmesi: Yerel sunucu IP'nizi "Bağlantı" ve "Röle" listelerine ekleyin.
   • Teslim sekmesi: Giden Güvenlik: temel bir kimlik doğrulaması seçin, geçerli bir lisanslı kullanıcının kimlik bilgilerini girin; "TLS şifrelemesi" kutusunu işaretleyin
   • Teslimat sekmesi: Giden Bağlantılar: TCP Bağlantı Noktası için 587 girin
   • Teslim sekmesi: Gelişmiş: E-posta etki alanınızı "Tam etki alanı adı" olarak ve e-posta sunucunuzu "Akıllı ana bilgisayar" olarak girin (yine de benim durumumda smtp.office365.com).

Güvenlik Duvarı: Giden için 587 numaralı bağlantı noktasını açmanız gerektiğini okudum. (Bu, güvenlik duvarının kapatılmasını gerektiren bir VOIP sunucusu olduğu için yapmadım.)

Office 365: Yerel statik IP'nize izin vermek için Yönetici> Exchange altına bir "bağlayıcı" ekleyin. Microsoft bu talimatları çevrimiçi olarak sağlar.

Son zamanlarda bu sorunla karşılaştım. Birileri smtp sunucusuna MalwareBytes kurmuştu ve smtp mailroot klasörleri beyaz listeye alınmadı. Yazılım, sıradaki her şeyi olası bir spam kampanyası olarak değerlendirdi ve badmail’e taşındığı zamanlarda zaman aşımına uğrattı. Tüm alanlar etkilendi. Çalışan süreçlere bakıp mbam'ın exe'sini fark edene kadar şaşırmıştım (yıllarca kusursuz operasyon ..).

Ben de aynı sorunu yaşadım. Diğerlerinin de belirttiği gibi DNS ile ilgiliydi. Dahili DNS sunucularımızda ortak alan adımız (dahili alan adımızdan farklı) için ileriye dönük bir arama bölgem var. Genel alan adı DNS kayıtlarımızdaki MX kayıtlarını eşleştirmek için bu dahili ileriye arama bölgesinde MX kayıtlarını eklemek zorunda kaldım. Bu sorunu çözdü.