[SOLVED] Postfix kerdesek / problemak

 ( FBK | 2012. július 20., péntek - 8:37 )

Hello!

Adott egy postfix mail gateway, aminek a 25-os laba kint log az interneten es minden xy.hu es zy.hu domainre erkezo levelet tovabbit a mogotte levo exchange-nek.

A kovetkezo problemaim vannak:

Ez a hiba egyelore csak 1 szervernel jelentkezik:
Jul 20 08:16:53 server postfix/smtpd[12466]: timeout after DATA (119724 bytes) from dslxxxxxxxxxxxx.fixip.t-online.hu[X.X.X.X]
Jul 20 08:16:53 server postfix/smtpd[12466]: disconnect from dslxxxxxxxxx.fixip.t-online.hu[X.X.X.X]

A masik problema par hirlevellel van:
Jul 20 08:03:19 server postfix/qmgr[12302]: 66467840D9: from=hirlevel+felhnev=xy.hu@zanza.origo.hu, size=54245, nrcpt=1 (queue active)
Jul 20 08:04:19 server postfix/smtp[12420]: C54D3840DE: to=hirlevel+felhnev=xy.hu@zanza.origo.hu, relay=zanza.mail.t-online.hu[X.X.X.X]:25, delay=0.19, delays=0.06/0.01/0.06/0.06, dsn=5.7.1, status=bounced (host zanza.mail.t-online.hu[X.X.X.X] said: 554 5.7.1 hirlevel+felhnev=xy.hu@valamihirlevel.hu: Relay access denied (in reply to RCPT TO command))

Szeretnem ha az ilyen nagyon jol megcimezett hirleveleket is megkapnak, hatha nem ok nelkul iratkoztak fel rajuk...

Jelenlegi main.cf :

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = Cegnev Mail Gateway
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = valami.sajatdomain.hu
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = valami.sajatdomain.hu, server.external.belsodomain.local, localhost.external.belsodomain.local, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_non_fqdn_recipient
reject_rbl_client zen.spamhaus.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client dnsbl.njabl.org
permit_mx_backup
relay_domains = $mydestination zy.hu xy.hu
transport_maps = hash:/etc/postfix/transport
maximal_queue_lifetime = 7d
bounce_queue_lifetime = 7d

Koszi
FBK

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egyszer volt ilyen timeout after data probléma, akkor mtu gebasz volt.

Jelenleg 1500 az MTU, ez a gep NAT mogott van, max le tudom venni 1492-re, hatha akkor megjon DSL-es FIXIP-s szerverrol is a level, kerdes, hogy ez jo otlet?

--
FBK

tracepath -n

itt is az lesz, csak meg nem fejtettem meg.

ha csak a szerver MTU-jat veszem lejjebb, akkor az nem segit...

az eredeti beallitasok igy neznek ki:

DSL: 1492
Berelt Vonal: 1500

Szerver: 1500

A DSL es Berelt Vonal is ugyanannak a szervernek ugyanarra a labara dobalja a leveleket, mx1 mx2...

Melyik MTU-val erdemes jaccani?

--
FBK

Mindegyikre és egyikre se :)
A szerver gateway-jének a LAN lábára állíts tcp-mss-t vagy fixen 1452 byte-ra, vagy a path mtu-ra.
(iptablesben valami "-j TCPMSS --clamp-mss-to-pmtu" lesz, google a barátod)

tehat a tuzfal egyik belso labara allitsak be 1452-es mtu-t? (ez a szerver gw-je.)

minden mas marad 1500 -on? (szerver)

--
FBK

"tehat a tuzfal egyik belso labara allitsak be 1452-es mtu-t?"
Nem MTU-ról, hanem MSS-ről volt szó.

Kicsit bővebben:
Az ADSL-es kapcsolatot indító eszköz meg fogja kapni az interfész MTU-t IPCP-n. Ha ez az eszköz a maga a szerver, akkor nem kell tenni semmit. Ha pedig a szerver az ADSL-t fogadó router mögött van, akkor megteheted, hogy a routered ADSL-es interfészén állítsz MSS-t, ha már a PMTUD valamilyen ok miatt nem működik. Vagy állíthatsz MSS-t MTU helyett a szervereden is. De az SMTP kliensen vagy szerveren való MTU állítás is megoldás lehet a problémára, bár én is inkább az előbb említett MSS állítást javasolnám.

elvileg akkor igy jonak kene lennie?

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.132.0 0.0.0.0 255.255.252.0 U 1452 0 0 eth0
0.0.0.0 192.168.132.1 0.0.0.0 UG 0 0 0 eth0

--
FBK

Ha ez egy netstat -nr vagy route -ne kimenet, akkor valószínűleg nem az MSS-t, hanem az MTU-t látod az MSS oszlopban, ezt ellenőrizheted, ha összeveted a /proc/net/route-tal, vagy megtekinted tcpdumppal. Ez utóbbi amúgy is sokat segíthet már annak eldöntésében is, hogy valóban MTU-MSS ügyben kell-e kutakodni. Továbbá fentebb javasolták a tracepath-t

Továbbá nem feltétlen akarod csökkenteni a LAN felé a csomagméretet, elég a routeren keresztülhaladó csomagoknál, szóval célszerűbb lenne a default route-ra rátenni, mint a connectedre, tekintve, hogy a problémás host felé a default fog vinni.

Fussunk neki újra. A lehetőségek:
a) A 192.168.132.1 a router, 192.168.132.2 a szerver. A router ADSL-es PPP interfészén alakítasz kicsit az MSS-en, azaz levágod 1452 byte-ra. Ez azért jó, mert csak az ADSL-es forgalomra fog hatni, persze szinte elhanyagolható az a fél százalék, de mégis így szép.
b) A szerveren állítasz MSS-t (esetleg MTU-t; netán a kliensen ugyenezeket). Ez az előbb leírt okok miatt nem szép, mivel a bérelt vonal felé menő forgalom esetén is nő kis mértékben az overhead feleslegesen. Nem azt mondtam, hogy rossz, hanem azt, hogy nem annyira szép, mint az a) változat.

Az a) változatra athila írt iptables parancsot, vagy használhatod az ip route-ot is, de ugye ha ezt a routeren akarod megtenni, akkor a routernek megfelelő módon kell beírni (pl. Cisco routernél ip tcp adjust-mss).

szerintem nem teljesen ertjuk egymast.

kikapcsoltam a natot az adsl-es labon, tehat levelek most mar kizarolag a berelt vonalon erkeznek a szerver fele, ahol jelenleg az MTU 1500, az MSS sincs bantva most. A hiba ugyanugy fenn all, amennyiben egy dsl-en csucsulo szerver kuldene levelet felenk.

A berelt vonal MTU-ja a tuzfalon is mindenhol 1500.

--
FBK

Hogy értsük is egymást, mond el, hogy hogy is néz ki a hálózatod.

Milyen routerek, milyen szerver, milyen switchen milyen route táblával milyen nattal hova kapcsolódik?

"tehat levelek most mar kizarolag a berelt vonalon erkeznek a szerver fele, ahol jelenleg az MTU 1500, az MSS sincs bantva most. A hiba ugyanugy fenn all, amennyiben egy dsl-en csucsulo szerver kuldene levelet felenk."

Egyik lehetséges magyarázat a jelenségre, hogy az ADSL végén tűzfal mögött van a PMTUD-t használó küldő szerver, és a nagy tűzfalazásban nem engedik vissza a szerverhez az ICMP Type 3-at. Ezt nem tartom életszerűnek, mivel ekkor biztos feltűnt volna nekik, hogy minden néhány sornál nagyobb levél fennakad, nem beszélve az egyéb célú TCP-ről.

A másik lehetőség, hogy a te szervered küldene nagy csomagot, - aminek szintén kicsi a valószínűsége, mivel az SMTP válaszok is jellemzően kicsik, kivéve pipelining esetén -, de az ADSL internetszolgáltatója nem küld vissza ICMP-t, vagy te szűröd ki a tűzfaladon. Ez meg azért lenne érdekes, mert azt írtad, hogy "Ez a hiba egyelore csak 1 szervernel jelentkezik". Gondolom, több ADSL-es PMTUD-t használó helyről érkezik felétek levél.

Fentebb említettünk eszközöket, jó lenne látni, hogy pontosan mi történik. Vélhetőleg retransmission, csak kérdés, melyik irányba.

No a kovetkezoket vettem eszre, bar sok idom nem volt azota foglalkozni vele:

a UPC-s levelek sem erkeznek be, ha hosszabbak par sornal...probaltam az MTU-t tologatni, eredmenytelenul...probaltam megmondani a szerver elott levo tuzfalnak, hogy ICMP Type 3 a szerver fele ill onnan ki - be mehet...eredmenytelenul...

tehat a hiba mar nem csak 1 szervernel jelentkezik, hanem tobb is van...a UPC pedig gondolom nem egy DSL-en logo szerverrol uzemeltet mail szervert...

hirtelen ennyi most, ja a tuzfal egy Zywall USG-100...ha van valakinek valami otlete plz help.

--
FBK

megoldodott, miutan mar teljesen tanacstalan voltam, kikapcsoltam a Zywall-ban az AntiSpam modult es lass csodat megszuntek a timeout-ok...nokomment.

udv.

--
FBK

A valamihirlevel.hu -ra az a megoldas, hogy felveszed a domaint azok koze, amiert felelosnek erzi magat a postfix, utana meg be kell loni, hogy megjojjenek ezek a levelek. De ezt nem javaslom. Aki nem tud normalisan cimezni, az ne akarjon levelezni sem. Tudom, hogy ez VERP kuldes, de ez ebben a kontextusban igy ertelmetlen. Szerintem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal