[Red]

hello!

kerestem, de nem talaltam temat ami csak a postfixel foglakozna. szerintem megerdemel ennyit. hasznaljak par helyen, s nekem meg szimpatikus is.
szal, lenne is 1 kerdesem:

- default_destination_recipient_limit, def=50
(The parameter specifies a default limit on the number of recipients per message delivery. This is the default limit for delivery via SMTP, via the local delivery agent and via the pipe mailer.)

- smtpd_recipient_limit, def=1000
(restricts the number of recipients that the SMTP server accepts per message delivery)

nem igazan ertem mi a kulonbseg a ketto kozott?! :confused:

[ 2003. október 23.: Red szerkesztette a hozzászólást ]

[Xanco]

Egy levelet nem feltétlenül csak egyszer kézbesít az SMTP szerver, hiszen több címzett esetén mindegyik címzett felé külön kell kézbesíteni. Azonban ha több címzettnek is egyetlen SMTP szerver felé kell kézbesíteni a levelet, akkor ezeket egyszerre teszi meg. Na ezzel jön be a különbség is.

Ha jól sejtem az elõbbi arra vonatkozik, hogy amikor megpróbál egy szerver felé kézbesíteni egy levelet, akkor max. ennyi címzettet ad meg a másik SMTP szervernek. Ha még így is marad címzett, akkor azokat egy újabb kézbesítéssel intézi el az adott szerver felé. Ez pedig még ki van terjesztve a lokális kézbesítésre is: egyszerrre max. 50 lokális postafiókba kézbesíti a levelet, a maradékot egy újabb futás alkalmával.

A második pedig egy levélhez tartozó összes címzett maximálás számát jelenti. Ennél több címzett nem fordulhat elõ egy levélben. Ha mégis, úgy azt a levelet vissza fogja utasítani a szerver.

[Red]

idézet:

---

Ezt írta Xanco:


Ha jól sejtem az elõbbi arra vonatkozik, hogy amikor megpróbál egy szerver felé kézbesíteni egy levelet, akkor max. ennyi címzettet ad meg a másik SMTP szervernek. Ha még így is marad címzett, akkor azokat egy újabb kézbesítéssel intézi el az adott szerver felé.
[/quote]

hm, ez jol hangzik. meg logikus is.mert ugye en megengedhetem a sajat felhasznaloimnak, hogy legyen akar 200cimzetje is a levelnek, viszont a masik MTA mar nem biztos, hogy orulne ennek a nagy szamu cimzettnek.
koszi szepen.

[Red]

a levelezesel kapcsolatban:

ha kap egy user levelet, akkor az megy a mailboxaba. ami alltalaban /var/spool/username.

na most az nem vilagos, hogy hogy kerul at ez a level tartalma a /home/username/mail konyvtarba.
mikor elinditom pl. a pine-t akkor az kiolvassa a filebol es a sajat folderebe tarolja? majd az eredeti file tartalmat torli?

[AndrewBoy]

sajna igen, én sem tom mi a megoldás.

[Friczy]

idézet:

---

Ezt írta Red:
a levelezesel kapcsolatban:

ha kap egy user levelet, akkor az megy a mailboxaba. ami alltalaban /var/spool/username.

na most az nem vilagos, hogy hogy kerul at ez a level tartalma a /home/username/mail konyvtarba.
mikor elinditom pl. a pine-t akkor az kiolvassa a filebol es a sajat folderebe tarolja? majd az eredeti file tartalmat torli?[/quote]

Igen, nagyjából így. Alapvetõen háromféle mailbox-rendszer létezik Linuxon, az egyik a /var/spool/username (mbox), a másik a /home/username/Maildir (maildir), valamint az MH (amirõl nem tudok részleteket ). Az MTA (a postfix is) annyit tud, hogy ide hogyan kell letenni a leveleket, vagy estleg hogy kell átadni az MDA-nak (pl. procmail), a többi nem az õ dolga, hanem vagy az MDA-é, vagy az MUA-é (pl. pine, mutt).

OFF:
Nem akarok flame-et, de általában a Maildir formátumot szokták javasolni, mivel ott a levelek levelenként külön file-ban vannak, így kevésbé sérülékeny a mailbox esetleges lockolási problémák esetén (valamint jól beilleszthetõ a quota-rendszerbe, ha valakinek ilyen vágyai vannak). Hátránya persze a sok kis filekezelés, de ez tûnik a kisebb hátránynak.

Hogy mégis ON legyek: a postfix természetesen Maildirt is tud

[Red]

koszi az infot.

igazabol az a bajom, hogy amig nem inditjak el a pine-t vagy nem pop3-mazzak le a levelet az ott gyulik a /var alatt.

a /home meg a /var az kulon particio, s pityukanak mas limitje van a particiokon. minden user-nek meg nem tudok egyforma tarhelyet biztositani minket particion (/var fontosabb kicsit, pl. az adatbazis, logok miatt).
na majd tolok bele meg vinyot!

[Friczy]

idézet:

---

Ezt írta Red:
koszi az infot.

igazabol az a bajom, hogy amig nem inditjak el a pine-t vagy nem pop3-mazzak le a levelet az ott gyulik a /var alatt.

a /home meg a /var az kulon particio, s pityukanak mas limitje van a particiokon. minden user-nek meg nem tudok egyforma tarhelyet biztositani minket particion (/var fontosabb kicsit, pl. az adatbazis, logok miatt).
na majd tolok bele meg vinyot! [/quote]

Amennyiben ez a gondod, akkor neked a Maildir vagy MH formátum kell, az a user home-ja alá teszi helybõl a leveleket. Tudtommal a pine is tud Maildirt.

[Mono]

Szervusztok!

Lenne egy kis problémám Postfixben. Van egy szerintem eléggé jól összelõtt levelezõ szerverem vele, élek az address verification-nal is, azaz a hozzám érkezõ levelek feladójától csak akkor fogadok el levelet, ha a feladó címe létezõ e-mail cím. Ez viszont néha-néha nem (jól?) mûködik. Történetesen van egy külsõ, freemail-es címem, ami be van állítva, hogy a rá érkezõ levelek automatikusan továbbítódjanak a Postfix által kezelt címemre (emellett pedig maradjon is egy-egy példány a freemailen). Valid, teljesen rendben levõ levelek viszont nem mindig érkeznek meg így. Ilyen pl. a HWSW témakövetés értesítõje, szerintem mint levél, nincs vele semmi gond. Ellenben freemail-re megérkezik, Postfixes címre nem. Kicsit turkáltam a log fájlban, sajna nincs már meg az a log, amiben látszódott volna konkrétan az a levél, ami nem jött meg, de találtam - szerintem - hasonlót:

Mar  1 09:25:58 localhost postfix/smtp[22992]: connect to p2pmail01.paper2print.com[65.115.231.196]: Connection timed out (port 25)
Mar  1 09:25:58 localhost postfix/smtp[22992]: 82C2A5B76A: to=<ZYEGGBPELTNF@paper2print.com>, relay=none, delay=30, status=undeliverable (connect to p2pmail01.paper2print.com[65.115.231.196]: Connection timed out)
Mar  1 09:25:58 localhost postfix/qmgr[22716]: 82C2A5B76A: removed

Nekem az a gyanúm ez alapján, hogy a következõ történik: jönne egy levél, melyet nem kézbesítek azonnal, megpróbálom visszaellenõrizni a feladó címét. Az õ szervere eléggé leterhelt, nem sikerült bejutnom, levelet eldobom. A címzett nem kapja meg, mert eldobtam. Hibakód nem generálódik, egyértelmûen elutasítva nem lett (5xx hibakód), így értesítést sem kap a feladó arról, hogy nem kapta meg a címzett, levél gyakorlatilag elvész.

Nem tudom, jó-e az eszmefuttatásom, de tény, hogy több ilyen freemailre megérkezett, de nem továbbított levelem közül a legutolsó is már túl van a hatodik napon, így nem valószínû, hogy idõvel megérkezik majd, vagy visszapattan.
Néhány kolléga is panaszkodott, hogy nekik sem érkezett meg egy-egy levél, melyet nekik küldtek. Nekem úgy tûnik, nagy levelezõ rendszerekrõl való küldés a közös nevezõ ezekben a nem megérkezett levelekben (freemail, hotmail, yahoo,....).

A Postfix main.cf fájlnak az ilyen jellegû része így néz ki:

smtpd_delay_reject = yes 
smtpd_helo_required = yes 
disable_vrfy_command = yes 
strict_rfc821_envelopes = yes 
smtpd_soft_error = 3 
smtpd_hard_error = 3 
smtpd_error_sleep_time = 2s 
message_size_limit = 10240000 
smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unverified_sender 
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unverified_recipient, reject_multi_recipient_bounce 
smtpd_data_restrictions = reject_unauth_pipelining 
queue_run_delay = 300s 
minimal_backoff_time = 300s 

Szintén szerintem leginkább az smtpd_sender_restrictions = reject_unverified_sender beállítás az, ami problémás ebben a dologban. Ezt kikapcsolva nincsenek olyan levelek, melyek nem érkeznének meg, ellenben elég sok SPAM érkezik így meg. Ez a beállítás nagyon jó SPAM filter volt, de sajna nem használhatom, mert valid levelek is fennakadnak rajta

Kérdésem tehát az lenne, tudtok-e ebben segíteni, jó lehet-e a gondolkodásom ezzel kapcsolatban Megoldható-e az valahogy, hogy ami cím nem utasítódik vissza egybõl az ellenõrzéskor, hogy nincs ilyen cím, de nem is létezik, akkor ezt próbálja vagy tovább, vagy többször ellenõrizni, vagy pattintsa vissza legalább egy olyan hibakóddal, mely alapján a feladó értesülhet arról, hogy nem kapta meg a címzett a levelet :confused:

Nagyon sokat segítenétek vele, elõre is köszönök mindent!

[Mono]

Kicsit még nyomozgattam ezen a téren, ha a fentebbi logikáb alapján próbálok tovább menni, miszerint ha túlságosan elfoglalt szerveren levõ cím verifikálása nem igazán sikerül, a levél elvész, így talán valamely idõt kellene picit nyújtani. Így kiadtam egy postconf utasítást, majd ebbõl minden idõre utaló beállítást összegyûjtöttem. Hátha ez valaki hozzáértõbbnek segítség lehet, mely idõ növelésével lehetne jobban elkerülni a timeout-ot. Bár, ha ez a másik oldalon továbbra is kicsi idõ, így a dologgal talán nem érek sokat, hiszen akkor nem én, hanem a távoli szerver fog majd timeoutolni.... de hátha.
Íme az adatok (legjava default érték):

address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
application_event_drain_time = 100s
bounce_queue_lifetime = 5d
command_time_limit = 1000s
daemon_timeout = 18000s
delay_warning_time = 0h
fast_flush_purge_time = 7d
fast_flush_refresh_time = 12h
ipc_timeout = 3600s
lmtp_connect_timeout = 0s
lmtp_data_done_timeout = 600s
lmtp_data_init_timeout = 120s
lmtp_data_xfer_timeout = 180s
lmtp_lhlo_timeout = 300s
lmtp_mail_timeout = 300s
lmtp_quit_timeout = 300s
lmtp_rcpt_timeout = 300s
lmtp_rset_timeout = 120s
lmtp_xforward_timeout = 300s
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d
minimal_backoff_time = 1000s
qmgr_clog_warn_time = 300s
qmqpd_error_delay = 1s
qmqpd_timeout = 300s
service_throttle_time = 60s
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_helo_timeout = 300s
smtp_mail_timeout = 300s
smtp_pix_workaround_delay_time = 10s
smtp_pix_workaround_threshold_time = 500s
smtp_quit_timeout = 300s
smtp_rcpt_timeout = 300s
smtp_rset_timeout = 120s
smtp_starttls_timeout = 300s
smtp_tls_session_cache_timeout = 3600s
smtp_xforward_timeout = 300s
smtpd_error_sleep_time = 1s
smtpd_policy_service_timeout = 100s
smtpd_proxy_timeout = 100s
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_session_cache_timeout = 3600s
stale_lock_time = 500s
transport_retry_time = 60s
trigger_timeout = 10s

[Friczy]

Idézet

Nekem az a gyanúm ez alapján, hogy a következõ történik: jönne egy levél, melyet nem kézbesítek azonnal, megpróbálom visszaellenõrizni a feladó címét. Az õ szervere eléggé leterhelt, nem sikerült bejutnom, levelet eldobom. A címzett nem kapja meg, mert eldobtam. Hibakód nem generálódik, egyértelmûen elutasítva nem lett (5xx hibakód), így értesítést sem kap a feladó arról, hogy nem kapta meg a címzett, levél gyakorlatilag elvész.

Ha így van, akkor baj van, a postfix a reject_unverified_sender esetén alapértelmezésben 450-es kódot küld.

Idézet

The unverified_sender_reject_code parameter (default 450) specifies how Postfix replies when a sender address is known to bounce. Change this setting into 550 when you trust Postfix's judgments.

Mellesleg a feladó az 5xx hibakód esetén is kap értesítést, csak akkor nem te küldöd, hanem az az MTA, amelyiktõl nem veszed át a levelet. Más kérdés, hogy mivel a HWSW-nél automatika küld, az nem fog sokat foglalkozni azzal, hogy te nem kaptad meg.

Ugyanakkor nem javasolt a reject_unverified_sender kiterjesztése teljes egészében.

Idézet

Unfortunately, sender address verification cannot simply be turned on for all email - you are likely to lose legitimate mail from mis-configured systems. You almost certainly will have to set up white lists for specific addresses, or even for entire domains.

Segíthet egy címjegyzék létrehozása is, amelyben a már visszaellenõrzött címek vannak, így kevesebb hálózati munkával jár a címek ellenõrzése, részleteket a man verify tud adni.

A hangoláshoz sok segítséget tud nyújtani, ha elsõ körben nem vezeted be a szabályt, csak úgy állítod be a postfixet, hogy figyelmeztessen a visszautasítás esetén (warn_if_reject). Mindenképpen javasolt elolvasni a postfix doksiból a postfix address verification részt, sok hasznos információ van benne.

(szerk: hülyén idéztem, javítva)

Szerkesztette: Friczy 2005. 03. 01. 16:21 -kor

[Mono]

Szokás szerinti gyors válaszod köszönöm!

Idézet

Ha így van, akkor baj van, a postfix a reject_unverified_sender esetén alapértelmezésben 450-es kódot küld.

Hm. Hát a logban ez nem látszik, de nem tartom kizártnak, hogy visszaküldi a hibakódot. Viszont - úgy vettem észre - hogy az eléggé elterjedt, leterhelt levelezõ rendszerek esetében fordul elõ ez a probléma (freemail, hotmail, yahoo, stb...). Lehet, hogy ez esetben másként kerül elbírálásra a 450-es hibakódú levél. Nem tudom..

Idézet

Mellesleg a feladó az 5xx hibakód esetén is kap értesítést, csak akkor nem te küldöd, hanem az az MTA, amelyiktõl nem veszed át a levelet. Más kérdés, hogy mivel a HWSW-nél automatika küld, az nem fog sokat foglalkozni azzal, hogy te nem kaptad meg.

Igen, ez reális. Ellenben volt már példa arra is, hogy direktbe írtak freemailrõl, vissza semmi hibával nem pattant, megérkezni sem érkezett meg, több nap után sem.

Idézet

Ugyanakkor nem javasolt a reject_unverified_sender kiterjesztése teljes egészében.

Pedig önmagában nagyon jól hangzó valaminek tûnt

Idézet

Segíthet egy címjegyzék létrehozása is, amelyben a már visszaellenõrzött címek vannak, így kevesebb hálózati munkával jár a címek ellenõrzése, részleteket a man verify tud adni.

Igen, erre gondoltam én is, bár a mai céges DSL sebességek esetén is szerintem felesleges ezt használni, "belefér" ez a hálózati mûvelet. A másik, szintén ilyen problémával küszködõ rendszer, pedig 100 MBit-en van (internet), ott szerintem meg méginkább felesleges.

Idézet

A hangoláshoz sok segítséget tud nyújtani, ha elsõ körben nem vezeted be a szabályt, csak úgy állítod be a postfixet, hogy figyelmeztessen a visszautasítás esetén (warn_if_reject). Mindenképpen javasolt elolvasni a postfix doksiból a postfix address verification részt, sok hasznos információ van benne.

Köszönöm, kétségtelenül igazad van, gondoltam ennél egyszerûbb lesz a helyzetem. Szerinted valamely idõ növelésével nem tudnám elkerülni a timeoutolásokat Vagy felesleges is ezen gondolkodnom, mivel ezt a túloldalon is meg kellene tennem ahhoz, hogy érjen valamit :confused:

Azt javallod tehát, állítsam be úgy a Postfixet, hogy ne alkalmazzam a "reject_unverified_sender" szabályt, de állítsam be azt, hogy egyéb visszautasítás esetén küldjön nekem is levelet. Majd ebbõl hozzak létre egy feketelistát, amibe esetleg kézzel pakolgatom hozzá azokat a címeket, melyrõl kéretlen levelek érkeznek Ennek függvényében viszont sosem használnám a "reject_unverified_sender" szabályt, nem

Az meg gyakorlatilag kizárt, hogy létrehozzak egy olyan fehérlistát, amin minden levelezõ partner rajta van, az összes többit pedig blokkolom. Napról-napra bõvül a levelezõpartnereink listája, ez nem túl szerencsés út

Igazán nem tudom, mit is tegyek ezzel...

[Friczy]

Idézet: Mono - Dátum: 2005. márc. 1., kedd - 17:14

Azt javallod tehát, állítsam be úgy a Postfixet, hogy ne alkalmazzam a "reject_unverified_sender" szabályt, de állítsam be azt, hogy egyéb visszautasítás esetén küldjön nekem is levelet. Majd ebbõl hozzak létre egy feketelistát, amibe esetleg kézzel pakolgatom hozzá azokat a címeket, melyrõl kéretlen levelek érkeznek Ennek függvényében viszont sosem használnám a "reject_unverified_sender" szabályt, nem

Azt javaslom, hogy tedd be a warn_if_reject opciót a reject_unverified_sender elé, és nézd meg, hogy miket akar visszautasítani. Valamint csináld meg a hivatkozott oldalon, hogy az ellenõrzött címeket tegye file-ba, és dolgozzon onnan. Ennek a megõrzési ideje is állítható.

Aztán a postfix logokból nézegesd a reject_warning részeket, és akkor tudod elemezni, hogy mely sender domainek azok, amelyekbõl ezzel a módszerrel sok spamet dobnál el, és kevés hasznos információt. Ezeket tedd egy táblázatba, amelyben megadod, hogy ezekból a domainekbõl mindig ellenõrizze a feladót, amelyek pedig jellemzõen nem spamek, de mégis elõfordul, hogy nem tudja visszaellenõrizni, azt meg egy whitelistbe.

persze ez nem kis munka, de talán megéri.

[1soproni]

Honnan szedi a postfix a hibaüzenetek szövegét?
Hol tudom átírni azokat magyarra?
(Debian Sarge)

[Friczy]

Idézet: 1soproni - Dátum: 2005. jún. 27., hétfõ - 11:29

Honnan szedi a postfix a hibaüzenetek szövegét?
Hol tudom átírni azokat magyarra?
(Debian Sarge)

Csak próbaképp belenéztem egy file-ba az /usr/lib/postfix alatt, az a gyanúm, hogy fixen bele van fordítva.

[1soproni]

Idézet: Friczy - Dátum: 2005. jún. 27., hétfõ - 13:22

Csak próbaképp belenéztem egy file-ba az /usr/lib/postfix alatt, az a gyanúm, hogy fixen bele van fordítva.

Akkor pechem van?

[Friczy]

Idézet: 1soproni - Dátum: 2005. jún. 27., hétfõ - 14:58

Akkor pechem van?

Egy opensource rendszerben ez csak a te elszántságodtól függ Nekiállhatsz magyarítani a forrásban, ha ragaszkodsz a magyar hibaüzenetekhez, kérdés, hogy minek az...

[1soproni]

Idézet: Friczy - Dátum: 2005. jún. 28., kedd - 11:09

Egy opensource rendszerben ez csak a te elszántságodtól függ Nekiállhatsz magyarítani a forrásban, ha ragaszkodsz a magyar hibaüzenetekhez, kérdés, hogy minek az...

Hogy a juzer ne tõlem kérdezze meg, hogy "lehet -e az, hogy valaki amerikából ír levelet magyarul, de a rendszer lefordítja angolra? Mer valami mailer daemon izé..." Mondjuk rossz a címzett, vagy megtelt a mailbox, stb

[1soproni]

Nem akar mûködni a quota postfix alatt. Van valami tipikus hiba, amit el szoktak követni az emberek ezzel kapcsolatban?

virtual_mailbox_limit_inbox = yes
virtual_mailbox_limit_maps = mysql:/etc/postfix/database/quota.cf
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.
virtual_overquota_bounce = yes
virtual_maildir_extended = yes
virtual_maildir_suffix =
virtual_create_maildirsize = yes

Debian Sarge, Postfix 2.1.5

[1soproni]

Nem mintha a quota megoldódott volna, de most próbálkozok a spamszûréssel.
A WIKI alapján próbálom megcsinálni, de nem akar mûködni.
Mintha teljesen figyelmenkívül hagyná a procmail-t.

Ami ide tartozik:

/etc/postfix/main.cf
mailbox_command = /usr/bin/procmail

/etc/procmailrc
DROPPRIVS=yes
:0fw
* < 256000
| spamc

# Ha valami gond van (pl. lefagy a spamassassin vagy
# elkonfiguráltuk), akkor se ragadjon be a levél
:0e
{
EXITCODE=$?
}

/var/mail/csaba@domain.hu/.procmailrc
MAILDIR=/var/mail/csaba@domain.hu/
DEFAULT=/var/spool/mail/csaba@domain.hu/
LOGFILE=/var/mail/csaba@domain.hu/procmail_log

# 15 ponttól már biztosan spam
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
spam-biztos

# 5-15 pont között talán spam
:0:
* ^X-Spam-Status: Yes
spam-talan

Mi nem stimmel?
A levél forrásában látnom kellene, hogy átment a spamteszten, nem?
A levél forrás 1 része:

Received: from localhost (localhost.localdomain [127.0.0.1])
by joey.domain.hu (Postfix) with ESMTP id 80650FF405E
for <csaba@domain.hu>; Fri, 22 Jul 2005 22:14:10 +0200 (CEST)
Received: from joey.domain.hu ([127.0.0.1])
by localhost (joey [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 19181-02 for <csaba@domain.hu>;
Fri, 22 Jul 2005 22:14:10 +0200 (CEST)

Szerkesztette: 1soproni 2005. 07. 22. 21:16 -kor