Próbuję wysyłać wiadomości e-mail za pośrednictwem SMTP w katalogu odbioru IIS. Niestety e-maile trafiają do folderu mailroot / queue i pozostają tam. W rzeczywistości nigdy nie są wysyłani.
Czy ktoś wie, dlaczego tak się stanie i potencjalna naprawa problemu?
Odpowiedzi:
Miał podobny problem z plikami utknął w kolejce. W menedżerze IIS, SMTP Virtual Server> Właściwości> Dostarczanie> Połączenia wychodzące. Opcja dla
Limit number of connections to
została zaznaczona, a wartość to0
. Został więc skonfigurowany tak, aby nigdy nie nawiązywał żadnych połączeń wychodzących, przez co wiadomości e-mail nigdy nie opuszczały serwera. Odznałem opcję i zrestartowałem serwer SMTP i wszystko poszło dobrze.źródło
Miałem dzisiaj ten problem.
Po zrestartowaniu usługi „Simple Mail Transfer Protocol (SMTP)” zaczął działać ponownie.
źródło
Dla przypomnienia: mieliśmy przypadek, w którym serwer nie mógł już rozpoznawać nazw z powodu błędnych ustawień DNS. Wynikowe zachowanie było dokładnie takie, jakie opisałeś.
źródło
IISRESET naprawił to dla mnie. Uważam, że jest to podobne do rozwiązania polegającego na zresetowaniu usługi SMTP, ponieważ usługa ta zależy od IIS. Po ponownym uruchomieniu poczta wewnątrz C: \ inetpub \ mailroot \ Queue zaczęła znikać!
źródło
Ostatnio natknąłem się na ten problem. W moim przypadku okazało się, że jest to problem z definicją serwera DNS w karcie sieciowej (to z dwóch powodów jest mi nieznane). Wyznaczony serwer DNS został ustawiony na „127.0.0.1” zamiast zwykłego „8.8.8.8”, który jest zwykle używany w tej sieci. Zmieniłem to na prawidłową wartość, zrestartowałem mój serwer SMTP, a kolejkowane wiadomości e-mail zostały natychmiast rozpowszechnione.
Jak do tego doszedłem, aby spojrzeć na problem definicji DNS:
Mam nadzieję, że to pomoże komuś innemu, na co początkowo nie myślałem.
źródło
Z mojego doświadczenia wynika, że jest to zazwyczaj spowodowane próbą wysłania przez IIS SMTP i napotkaniem tymczasowego błędu (kod odpowiedzi 4xx). Czy włączyłeś rejestrowanie usługi SMTP IIS i przejrzałeś dziennik? Przepraszam, jeśli to wszystko oczywiste, ale trudno jest poznać przyczynę lub poprawkę, nie wiedząc, co pokazuje dziennik.
źródło
Wydaje mi się, że problemem może być zamieszanie między IPv4 a IPv6 w systemie, więc kiedy podasz localhost, wybierany jest domyślny protokół IPv6. Miałem dzisiaj ten sam problem i został on naprawiony po tym, jak zmieniono odwołanie localhost do adresu IPv6 w hostach, chociaż mógł to być zbieg okoliczności (konfiguruję również SVN). Oto moja konfiguracja na wszelki wypadek:
Przez cały dzień bawiłem się ustawieniami, więc, szczerze mówiąc, nie jestem pewien, co jeszcze mogłoby wpłynąć na fakt, że teraz działa. Mam nadzieję, że to pomoże choć trochę.
źródło
Pierwszym miejscem do obejrzenia są pliki dziennika serwera. Dzięki temu dowiesz się, czy Twój serwer ma problemy z wysyłaniem danych do określonych hostów. W większości przypadków tak się dzieje (z mojego doświadczenia), że winowajcą jest zazwyczaj DNS (po twojej stronie lub zdalnie).
źródło
Serwer SMTP szuka hosta / bramy SMTP, na którą będzie wysyłana poczta.
Jeśli próbujesz wysłać do localhost, wtedy localhost IP będzie bramą. Jeśli próbujesz wysłać wiadomość na zewnętrzny adres e-mail, taki jak Gmail lub Hotmail, musisz dodać bramę poczty swojego usługodawcy internetowego jako hosta inteligentnego.
Aby skonfigurować inteligentnego hosta:
źródło
Miałem ten sam problem po zmianie usługi e-mail z jednego hosta na inny (nowy to Office 365). Po wielu próbach i błędach w końcu zaczął działać, wykonując następujące czynności:
Zapora ogniowa: Przeczytałem, że musisz otworzyć port 587 dla połączeń wychodzących. (Nie zrobiłem tego, ponieważ jest to serwer VOIP, który wymaga wyłączonej zapory).
Office 365: Dodaj „łącznik” w obszarze Administrator> Exchange, aby zezwolić na lokalny statyczny adres IP. Microsoft udostępnia te instrukcje online.
źródło
Ostatnio natknąłem się na ten problem. Ktoś zainstalował MalwareBytes na serwerze smtp, a foldery mailroot smtp nie zostały umieszczone na białej liście. Oprogramowanie potraktowało wszystko w kolejce jako potencjalną kampanię spamową i pozwoliło jej upłynąć wystarczająco dużo czasu, aby przeniósł się do złej poczty. Dotyczy to wszystkich domen. Zastanawiałem się (bezbłędna operacja od lat ...), dopóki nie spojrzałem na uruchomione procesy i nie zauważyłem exe mbam.
źródło
Miałem ten sam problem. Jak powiedzieli inni, było to związane z DNS. Mam strefę wyszukiwania do przodu na naszych wewnętrznych serwerach DNS dla naszej publicznej nazwy domeny (która jest inna niż nasza wewnętrzna nazwa domeny). Musiałem dodać rekordy MX w tej wewnętrznej strefie wyszukiwania do przodu, aby pasowały do rekordów MX w naszych rekordach DNS domeny publicznej. To rozwiązało problem.
źródło