Re: MTA HELO filtering
On Wed, Jun 27, 2007 at 11:41:44AM +0200, Gábor Lénárt wrote: Miert is nem? Attol, hogy a HELO nem tetszik az MTA-nak nem kotelezo OTT reklamalnia a HELO utan, teheti kesobb is. Ott a pont. :) A HELO utani eldobas eroforraskimelobb, de valo igaz, hogy sokkal nehezebb debugolni, mert IP-n es a bedobott HELO neven kivul semmit sem lehet meg akkor tudni a kuldo felrol. Koszi! -- LiRulhttp://www.hixsplit.hu/ Un*x + HIX = hixsplit Lehet, de nem erdemes nelkule... _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MTA HELO filtering
On Tue, Jun 26, 2007 at 11:04:07PM +0200, LiRul wrote: Amugy az se mindegy, hogy azert kulon kell valasztani az MX szerver (tehat ugye az az MTA ami kivulrol fogad mail-eket) a mail submit jellegu MTA-ktol (ami ugyfelektol, userektol stb fogad), mert ez utobbi esetben teljesen mas jellegu problemak lepnek fel. Igen, igazad van, ezeket nem lehet keverni. Ha mindezt egy szerver MTA-ra biznank, az csakis IP alapon tudna donteni, mert a HELO elott meg mas fogalma nincs arrol, hogy majdan egy authentikalt user lesz-e a sessionbol vagy sem. (Ha most a 25/tcp-t nezzuk, s nem a mail submit feature-t.) Miert is nem? Attol, hogy a HELO nem tetszik az MTA-nak nem kotelezo OTT reklamalnia a HELO utan, teheti kesobb is. Sot, nalunk is igy van. Konkretan pl postfix-ben ez az smtpd_delay_reject = yes, kb arra jo hogy megvarja az elso RCPT TO-t es UTANA mondja hogy meg a magaet, addig csak megjegyzi az smtpd process hogy baj volt. http://www.postfix.org/postconf.5.html#smtpd_delay_reject Ez azert is jo, mert ahogy irod is: nem feltetlen derulne ki maskepp, mar a HELO-nal hogy vki auth-olni fog-e _MAJD_. Illetve masik elony: ha barkit elutasitasz HELO check-nel, akkor normal esetben ugye logban max annyi lenne hogy XYZ IP cimrol jott valaki, es elutasitva. Viszont delay reject-tel loggolni lehet a specifikalt feladot es cimzettet is (amire aztan pl konyebb keresni ha reklamacio van, vagy akarmi), mivel ugye magat a reject-et csak az RCPT TO _utan_ kapja meg a kuldo MTA toled, tehat mar megvan tobb info, amit lehet loggolni. -- - Gábor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MTA HELO filtering
Hello! On Mon, Jun 25, 2007 at 10:34:29PM +0200, Gábor Lénárt wrote: Ha jol remlik IP nem is lehet, ha mar itt tartunk. Tehat ez pl invalid: HELO 1.2.3.4 Na ez viszont elvileg jo: HELO [1.2.3.4] Ugyanugy ahogy elvileg [EMAIL PROTECTED] email cim lehetseges, de [EMAIL PROTECTED] az nem. Igy igaz. Viszont nezegetve a logokat, sajnos van jopar benan beallitott exchange, ami siman HELO 1.2.3.4 formaban koszon be. Es ezzel a kitetellel, hogy csak a domain literalnak megfelelo formaban fogadok el koszonest, tuti tenyleg kizarok egy rakas (amugy) legitim MTA-t is. Nem ujdonsag, gondolom sokan csinaljatok, en csak azt szeretnem megtudni, hogy van-e barmilyen karos hatasa, amiert megsem kellene beallitani. Hat a fo gond ugye az, hogy egy dolog, hogy megteheted, sot meg az is, hogy esetleg ilyen-olyan RFC szerint igazad van-e, de mindig akadni fog olyan MTA, akinek az uzemeltetoje vagy nem tul kepzett, vagy nem figyel ra, stb, es olyasmiket allit be, amit aztan kiszursz. Nyilvan ezek szama nem nulla lesz, tehat merlegelni kell, olyan nincs, hogy csak nyersz es nem vesztel nagy szamok eseten mar. Ezen filoztam en is, de arra jutottam, hogy ki es miert allitana be a sajat MTA-jaban, hogy az en local domain-emmel helozzon be?! Vagy mindig a kuldendo cim kukac utani allo reszevel helozna? Van ilyen? A benabb linux adminoknal inkabb a localhost(\.localdomain)? szokott elojonni. Amugy nalunk van ilyesmi, nem emlekszem hogy egyetlen reklamacio is jott volna arra, hogy HELO/EHLO-t IP-cimmel dolgot _egyaltalan_ nem engedek be. Arra viszont volt nem is egy pelda, hogy HELO szerver es hasonlokat kuld valaki, ami ugye nem igazan FQDN/FQHN. Ilyen szurest eszem agaban sincs beallitani. :-) Mert bar a gep hostingban van, SMTP auth utan kuldhetnek rajta joparan, s sajnos az okos win32-es MUA-k igen erdekes helo stringet tudnak kuldeni (tavolrol sem FQDN)... -- LiRulhttp://www.hixsplit.hu/ Un*x + HIX = hixsplit Lehet, de nem erdemes nelkule... _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MTA HELO filtering
On Tue, Jun 26, 2007 at 09:36:34AM +0200, LiRul wrote: Igy igaz. Viszont nezegetve a logokat, sajnos van jopar benan beallitott exchange, ami siman HELO 1.2.3.4 formaban koszon be. Es ezzel a kitetellel, Na igen errol beszeltem ... Mindig van olyan akinek keresztbe teszel, ha valamire szurni akarsz, akkor is, ha elvileg jogosan teszed ... hogy csak a domain literalnak megfelelo formaban fogadok el koszonest, tuti tenyleg kizarok egy rakas (amugy) legitim MTA-t is. Ez igy van. Erre mondtam, hogy megfontolas kerdese, amiben benne van az adott kornyezet is, ahol neked meg kell ezt oldalni. Amugy az se mindegy, hogy azert kulon kell valasztani az MX szerver (tehat ugye az az MTA ami kivulrol fogad mail-eket) a mail submit jellegu MTA-ktol (ami ugyfelektol, userektol stb fogad), mert ez utobbi esetben teljesen mas jellegu problemak lepnek fel. Ha egy kalap ala veszed, nehez dolgod lesz tenyleg, hiszen egy atlag MUA az ugye erosen nem MTA, es nem is fog mindig ugy viselkedni (lasd pl egy MUA miket mond HELO utan). Ha jol remlik ez a mail submit dolog RFC 2476-ben van definialva, es tcp/587-es portot preferalja (de persze van ahol ugyanugy a 25-oson van). Mindenestre nalunk ezek mellett meg szinten kulon van az ugyfelek MTA-ja fele a dolog, mert ugyan az mar nem MUA, de megis mas kategoria erzesem szerint mint egy sima MX szerver. Igy van legalabb maris harom kulonbozo policy. Ezek lehetnek kulon gepen, de lehet egy MTA is persze ami attol fuggoen hogy ki jon (IP cim es/vagy SMTP auth stb alapjan nezve) hasznal kulonbozo policy-ket. Ezen filoztam en is, de arra jutottam, hogy ki es miert allitana be a sajat MTA-jaban, hogy az en local domain-emmel helozzon be?! Vagy mindig a Kevesen :) Hacsak nem MUA-rol van szo, es mail submit-rol ... kuldendo cim kukac utani allo reszevel helozna? Van ilyen? A benabb linux adminoknal inkabb a localhost(\.localdomain)? szokott elojonni. :) Igen ilyennel mar talalkoztam. Amugy nalunk van ilyesmi, nem emlekszem hogy egyetlen reklamacio is jott volna arra, hogy HELO/EHLO-t IP-cimmel dolgot _egyaltalan_ nem engedek be. Arra viszont volt nem is egy pelda, hogy HELO szerver es hasonlokat kuld valaki, ami ugye nem igazan FQDN/FQHN. Ilyen szurest eszem agaban sincs beallitani. :-) Mert bar a gep hostingban van, SMTP auth utan kuldhetnek rajta joparan, s sajnos az okos win32-es MUA-k igen erdekes helo stringet tudnak kuldeni (tavolrol sem FQDN)... Azert mondom hogy mail submission-t illik teljesen kulon kezelni! Ne akarj egy policy-t az osszes MTA funkcionalitashoz mert az nem fog menni, legalabbis nem jol. Pl nalunk is persze csak MX szervereknel van ilyenre ellenorzes amit itt irtam. -- - Gábor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MTA HELO filtering
On Tue, Jun 26, 2007 at 10:13:10AM +0200, Gábor Lénárt wrote: Amugy az se mindegy, hogy azert kulon kell valasztani az MX szerver (tehat ugye az az MTA ami kivulrol fogad mail-eket) a mail submit jellegu MTA-ktol (ami ugyfelektol, userektol stb fogad), mert ez utobbi esetben teljesen mas jellegu problemak lepnek fel. Igen, igazad van, ezeket nem lehet keverni. Ha mindezt egy szerver MTA-ra biznank, az csakis IP alapon tudna donteni, mert a HELO elott meg mas fogalma nincs arrol, hogy majdan egy authentikalt user lesz-e a sessionbol vagy sem. (Ha most a 25/tcp-t nezzuk, s nem a mail submit feature-t.) Azert mondom hogy mail submission-t illik teljesen kulon kezelni! Ne akarj egy policy-t az osszes MTA funkcionalitashoz mert az nem fog menni, legalabbis nem jol. Pl nalunk is persze csak MX szervereknel van ilyenre ellenorzes amit itt irtam. Jogos, ott a pont, koszonom az infokat es a tanacsokat! -- LiRulhttp://www.hixsplit.hu/ Un*x + HIX = hixsplit Lehet, de nem erdemes nelkule... _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MTA HELO filtering
Hi, On Mon, Jun 25, 2007 at 07:10:12PM +0200, [EMAIL PROTECTED] wrote: Arra gondoltam beallitom egy felig-meddig teszt szerveren a kapcsolodo fel HELO szureset. Ha az alabbi lista valamely elemevel egyezik a request, akkor a kuldo kap egy 550-et az arcaba. - sajat local_domain-ek - localhost(\.localdomain)?, ha nem lo-n jon a request - publikusan nem route-olhato IP (a gep hostingban van, nincs LAN mogotte) - sajat publikus ip Ha jol remlik IP nem is lehet, ha mar itt tartunk. Tehat ez pl invalid: HELO 1.2.3.4 Na ez viszont elvileg jo: HELO [1.2.3.4] Ugyanugy ahogy elvileg [EMAIL PROTECTED] email cim lehetseges, de [EMAIL PROTECTED] az nem. Nem ujdonsag, gondolom sokan csinaljatok, en csak azt szeretnem megtudni, hogy van-e barmilyen karos hatasa, amiert megsem kellene beallitani. Hat a fo gond ugye az, hogy egy dolog, hogy megteheted, sot meg az is, hogy esetleg ilyen-olyan RFC szerint igazad van-e, de mindig akadni fog olyan MTA, akinek az uzemeltetoje vagy nem tul kepzett, vagy nem figyel ra, stb, es olyasmiket allit be, amit aztan kiszursz. Nyilvan ezek szama nem nulla lesz, tehat merlegelni kell, olyan nincs, hogy csak nyersz es nem vesztel nagy szamok eseten mar. Amugy nalunk van ilyesmi, nem emlekszem hogy egyetlen reklamacio is jott volna arra, hogy HELO/EHLO-t IP-cimmel dolgot _egyaltalan_ nem engedek be. Arra viszont volt nem is egy pelda, hogy HELO szerver es hasonlokat kuld valaki, ami ugye nem igazan FQDN/FQHN. -- - Gábor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
