Szerző: szotsaki » 2013. aug. 24., szomb. 23:55
Visszaértem, és kicsit beleástam magam a problémába, amibe a Citromaillel ütköztünk. A következő levélváltás leginkább technikai lesz, így sokatoknak túl sok részletet nem fog elárulni, így két mondatban összefoglalom a kevésbé hozzáértőknek is a lényeget, amit eddig sikerült kiderítenem.
Két hiba áll fent, az egyik a mi oldalunkon a másik a Citromail oldalán. Az első, nálunk lévő hiba miatt a Citromail nem fogadta a leveleket a MorroHuntól, és a második őnáluk lévő hiba pedig eltakarta az elsőt (gyakorlatilag egy teljesen másik problémának állítva azt be).
Erről tájékoztattam őket pár perce, valószínű, hogy hétfőn fognak válaszolni a részletekkel. Ahogy ígértem, alább a részletes levelek.
Ezt a levelet még a hosszú szünet előtt kaptam, ebben van benne egy nagy segítség az első hiba lehetőségéről:
Citromail.hu írta:
Tisztelt Szőts Ákos!
Köszönöm a levél headert, sokat segített. A smtp kapcsolat kiépülése után, a helo utasításnál áll meg a folyamat. "501 - requires FQDN address" hibaüzenettel zárjuk a folyamatot. Nem 4xx-el, tehát a leveleknek nem szabadna queue-ben várniuk, azonnal vissza kellene pattanniuk. Ez valamilyen postfix beállítás lesz.
A helot azért utasítjuk el, mert a következő stringet küldi: morrohun.morrohun.local
A .local legfelsőbb domain név belső hálózaton használatos, nem külsőn. Ezt kellene módosítani, mondjuk .hu-ra. Postfixnél, ha jól emlékszem, smtp_helo_name a main.cf-ben.
A válaszom erre rögtön az volt, hogy a szünet után tudom megnézni, amit meg is tettem ma.
Küldtem a levelező szoftvert (Postfix) készítőknek egy levelet, amiben megkérdezem, hogy miért „maszkolta” el a második hiba az elsőt (vagyis miért tette a Postfix a várakozási sorba a levelet, ha azonnal vissza kellett volna utasítania):
Dear list members,
I have the following problem:
A 3rd party e-mail provider refuses the HELO/EHLO command if it doesn't
contain a valid FQDN address (which is acceptable from their point of view).
They refuse it with a 501 (permanent) error, which means according to [1]:
"[...] In this case, the sending MTA server should not queue the message, but
delete it from its queue and send back an NDR (Non-Delivery-Response) to the
sender, informing of such error."
The problem is, in spite of the above mentioned, Postfix (and BSD sendmail
also) puts the letter into the mail queue as it was deferred and tries to re-
send it continuously.
I tested it with the following:
Kód: Egész kijelölése
$ /> telnet server29.citromail.hu smtp
Trying 91.83.45.29...
Connected to server29.citromail.hu.
Escape character is '^]'.
220 server29 mfiltro ESMTP server ready
HELO google.local
501 HELO requires FQDN address
Connection closed by foreign host.
So far this is ok. But after I sent a message with "sendmail
xxxxcitromail.hu", the following shows up in the mail queue:
Kód: Egész kijelölése
D82A21807CB 300 Sat Aug 24 15:52:28 rootxxxxxx.local
(lost connection with server27.citromail.hu[91.83.45.27] while performing the
HELO handshake)
In Postfix the "soft_bounce" parameter is set to "no".
I know that the problem can be easily circumvented by setting a proper FQDN,
but I want to know the root cause why Postfix (and the plain sendmail) puts the
letter into the queue as a deferred one.
Thank you for your reply,
Ákos Szőts
[1]:
http://en.redinskala.com/extended-status-codes-smtp/
Erre a
válaszuk az volt, hogy a Citromail helytelenül implementálja a tőlünk kimenő levelek fogadását, ha az első hiba fennáll:
Jeroen Geilman írta:
[...]
The server then disconnects, thus not allowing postfix to finish the session.
As RFC5321 says, the server MUST wait for the client to send QUIT.
[...]
Because it incorrectly implements ESMTP, and disconnects during a session. This causes postfix to (correctly) treat the disconnect as a transient network error. Such an aborted session will be deferred.
[...]
Ezt megírtam a Citromailnek összefoglalva:
Tisztelt Citromail!
Mélyebben beleástam magam mindkét problémába, és a következőket sikerült
kiderítenem:
- Valóban nem FQDN HELO parancsot küldök az Önök irányába, így az szerverük
elutasítja a kapcsolatot. Ezt a Postfixben helyesen beállítva (mydomain és
myhostname paraméterekkel) már működik a levelek elfogadása.
- A HELO parancs elutasítást szabálytalanul hajtják végre, a TCP kapcsolat
azonnali lezárásával és az SMTP kapcsolat függőben hagyásával. Ezt a Postfix
átmeneti hálózati hibaként értelmezi, és újra próbálja küldeni a leveleket,
hiába az 500-as típusú hiba. Ez utóbbiról ebben a levelemben és a rá érkezett
válaszban olvashatnak többet:
http://archives.neohapsis.com/archives/ ... /0402.html
Üdvözlettel,
Szőts Ákos
Összefoglalva a fentieket:
A fő hiba, az első, a mi oldalunkon állt fent, amit sikerült ma javítani. Azért nem lehetett korábban, mert egy második, Citromail oldalán lévő megtévesztően másnak állította be azt (és egy másik betegséget máshogy kezel az orvos, ha szabad ezzel a képpel élnem).
A lényeg, hogy mivel a küldési gond elhárításra került, holnap ki tudom küldeni minden Citro/Indamailesnek a levelét.
Visszaértem, és kicsit beleástam magam a problémába, amibe a Citromaillel ütköztünk. A következő levélváltás leginkább technikai lesz, így sokatoknak túl sok részletet nem fog elárulni, így két mondatban összefoglalom a kevésbé hozzáértőknek is a lényeget, amit eddig sikerült kiderítenem.
Két hiba áll fent, az egyik a mi oldalunkon a másik a Citromail oldalán. Az első, nálunk lévő hiba miatt a Citromail nem fogadta a leveleket a MorroHuntól, és a második őnáluk lévő hiba pedig eltakarta az elsőt (gyakorlatilag egy teljesen másik problémának állítva azt be).
Erről tájékoztattam őket pár perce, valószínű, hogy hétfőn fognak válaszolni a részletekkel. Ahogy ígértem, alább a részletes levelek.
Ezt a levelet még a hosszú szünet előtt kaptam, ebben van benne egy nagy segítség az első hiba lehetőségéről:
[quote="Citromail.hu"]
Tisztelt Szőts Ákos!
Köszönöm a levél headert, sokat segített. A smtp kapcsolat kiépülése után, a helo utasításnál áll meg a folyamat. "501 - requires FQDN address" hibaüzenettel zárjuk a folyamatot. Nem 4xx-el, tehát a leveleknek nem szabadna queue-ben várniuk, azonnal vissza kellene pattanniuk. Ez valamilyen postfix beállítás lesz.
A helot azért utasítjuk el, mert a következő stringet küldi: morrohun.morrohun.local
A .local legfelsőbb domain név belső hálózaton használatos, nem külsőn. Ezt kellene módosítani, mondjuk .hu-ra. Postfixnél, ha jól emlékszem, smtp_helo_name a main.cf-ben.
[/quote]
A válaszom erre rögtön az volt, hogy a szünet után tudom megnézni, amit meg is tettem ma. [url=http://archives.neohapsis.com/archives/postfix/2013-08/0402.html]Küldtem[/url] a levelező szoftvert (Postfix) készítőknek egy levelet, amiben megkérdezem, hogy miért „maszkolta” el a második hiba az elsőt (vagyis miért tette a Postfix a várakozási sorba a levelet, ha azonnal vissza kellett volna utasítania):
[quote]
Dear list members,
I have the following problem:
A 3rd party e-mail provider refuses the HELO/EHLO command if it doesn't
contain a valid FQDN address (which is acceptable from their point of view).
They refuse it with a 501 (permanent) error, which means according to [1]:
"[...] In this case, the sending MTA server should not queue the message, but
delete it from its queue and send back an NDR (Non-Delivery-Response) to the
sender, informing of such error."
The problem is, in spite of the above mentioned, Postfix (and BSD sendmail
also) puts the letter into the mail queue as it was deferred and tries to re-
send it continuously.
I tested it with the following:
[code]
$ /> telnet server29.citromail.hu smtp
Trying 91.83.45.29...
Connected to server29.citromail.hu.
Escape character is '^]'.
220 server29 mfiltro ESMTP server ready
HELO google.local
501 HELO requires FQDN address
Connection closed by foreign host.
[/code]
So far this is ok. But after I sent a message with "sendmail
xxxxcitromail.hu", the following shows up in the mail queue:
[code]
D82A21807CB 300 Sat Aug 24 15:52:28 rootxxxxxx.local
(lost connection with server27.citromail.hu[91.83.45.27] while performing the
HELO handshake)
[/code]
In Postfix the "soft_bounce" parameter is set to "no".
I know that the problem can be easily circumvented by setting a proper FQDN,
but I want to know the root cause why Postfix (and the plain sendmail) puts the
letter into the queue as a deferred one.
Thank you for your reply,
Ákos Szőts
[1]: http://en.redinskala.com/extended-status-codes-smtp/
[/quote]
Erre a [url=http://archives.neohapsis.com/archives/postfix/2013-08/0404.html]válaszuk[/url] az volt, hogy a Citromail helytelenül implementálja a tőlünk kimenő levelek fogadását, ha az első hiba fennáll:
[quote="Jeroen Geilman"]
[...]
The server then disconnects, thus not allowing postfix to finish the session.
As RFC5321 says, the server MUST wait for the client to send QUIT.
[...]
Because it incorrectly implements ESMTP, and disconnects during a session. This causes postfix to (correctly) treat the disconnect as a transient network error. Such an aborted session will be deferred.
[...]
[/quote]
Ezt megírtam a Citromailnek összefoglalva:
[quote]
Tisztelt Citromail!
Mélyebben beleástam magam mindkét problémába, és a következőket sikerült
kiderítenem:
- Valóban nem FQDN HELO parancsot küldök az Önök irányába, így az szerverük
elutasítja a kapcsolatot. Ezt a Postfixben helyesen beállítva (mydomain és
myhostname paraméterekkel) már működik a levelek elfogadása.
- A HELO parancs elutasítást szabálytalanul hajtják végre, a TCP kapcsolat
azonnali lezárásával és az SMTP kapcsolat függőben hagyásával. Ezt a Postfix
átmeneti hálózati hibaként értelmezi, és újra próbálja küldeni a leveleket,
hiába az 500-as típusú hiba. Ez utóbbiról ebben a levelemben és a rá érkezett
válaszban olvashatnak többet:
http://archives.neohapsis.com/archives/postfix/2013-08/0402.html
Üdvözlettel,
Szőts Ákos
[/quote]
Összefoglalva a fentieket:
A fő hiba, az első, a mi oldalunkon állt fent, amit sikerült ma javítani. Azért nem lehetett korábban, mert egy második, Citromail oldalán lévő megtévesztően másnak állította be azt (és egy másik betegséget máshogy kezel az orvos, ha szabad ezzel a képpel élnem).
A lényeg, hogy mivel a küldési gond elhárításra került, holnap ki tudom küldeni minden Citro/Indamailesnek a levelét.
