postfix kerdes

Linux-kezdő

Sziasztok!

Postfix-nél meglehet nézni az éppen elküldésre várakozó leveleket valahogyan?

Udv: blade

  • 3201 megtekintés

( paulo2 | 2008. 03. 04., k – 17:07 )

1. A mailq-val ki lehet iratni, mi van a mail queue-ban.
Itt kiírja a címzetteket és a levél azonosítóját.

2. Utána a postcat paranccsal megadod, hogy melyik azonosítójú levélre vagy kíváncsi:
például:

postcat 234C1234

Üdv:
Pali

Nem feltétlen a te megoldásod lesz, engem zavartak a spamekre visszapattanó levelek (nem létező címekre érkező spamre válasz), amiket nem tud a rendszer kézbesíteni, és ezeket így szoktam törölni: 

for m in `mailq | grep "MAILER-DAEMON" | cut -d" " -f1`; do find /var/spool/postfix/defer /var/spool/postfix/deferred -type f -name $m -print -exec rm -f {} \; ; done

Vagyis a MAILER-DAEMON-os feladóval a deferred állapotú leveleket kitörli.

hth:

a.

ps: értelemszerűen egy sorban van az egész.

( xray | 2008. 03. 26., sze – 11:45 )

Sziasztok!

Adott egy ceg, adott egy olyan alias amelyre erkezo leveleket megkapja igen sok ember. Namost erre a címre folyamatosan "mail delivery-s" hibaüzeneteket kapok. Viszont senki nem küldött az adott külso cimekre levelet, a logban megnéztem. Megoldható az, hogy kivulrol erre a cimre ne lehessen levelet küldeni csak adott emberek küldhetnek belülről erre a címre levelet? Ugyanis eddig is csak így használtuk.
Lehet hálózati cím megszorítás, ip, feladó ilyesmikre gondolok de ezt mindet csak erre az adott címre.

Van erre valamiféle megoldás?

üdv

interfaces-ben csak a belso halot engeded, firewallon tiltod a befele jovo 25-os portot, ilyesmi. Ez inkabb halozati kerdes, nem kimondottan postfix.

Az MTA-t alapvetoen nem erdekli, hogy az aktualis level honnet jott. Johet localhostrol, johet barhonnan, ha nincs korlat, mindent kezbesit, ami a lokalis halonak szol valamilyen modon, illetve kifele mindent kezbesit, amit a lokalis halorol kuldenek. Az, hogy ezen felul szabalyozd magat a levelfogadast, az inkabb halozati kerdes, es erossen fugg a levszerver haloban elfoglalt helyzetetol.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( hszu | 2008. 07. 23., sze – 22:55 )

http://www.postfix.org/RESTRICTION_CLASS_README.html

What follows is based on the sender SMTP envelope address, and therefore is subject to SMTP sender spoofing.

/etc/postfix/main.cf:
smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/protected_destinations
...the usual stuff...

smtpd_restriction_classes = insiders_only
insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

/etc/postfix/protected_destinations:
all@my.domain insiders_only
all@my.hostname insiders_only

/etc/postfix/insiders:
my.domain OK matches my.domain and subdomains
another.domain OK matches another.domain and subdomains

Getting past this scheme is relatively easy, because all one has to do is to spoof the SMTP sender address.

If the internal list is a low-volume one, perhaps it makes more sense to make it moderated.

( Mono v | 2008. 08. 08., p – 18:23 )

Sziasztok!

Újabb postfixes gondom támadt...

Vázolnám a helyzetet. Használok internetes, ingyenes fekete listákat levelek elfogadásához. Eddig komolyabb gond nem volt ezzel, most viszont akadt. Az történt ugyanis, hogy kollégám külföldi szállodából küldött levelet, a mi szerverünkön keresztül, authentikálva a mi szerverünkön létrehozott postafiók egyikébe és egy másik, külső domain-re, mint "cc"-zett cím. Azaz egy levelének volt egy kollégája és egy másik, nem kollégás címzettje. A kolléga nem kapta meg, a másik, külső domain-es pedig igen. Több napon keresztül, több ilyen manőver is volt, ugyanezzel az eredménnyel. Persze kiderült a dolog, logokban azt láttam, hogy jött be a külföldi kollégám levele, authentikált, saját domaines kollégája számára el lett utasítva a levél kézbesítése, a külső domain-es címzettnek szó nélkül el lett küldve. Ennek oka az volt, hogy a szálloda, ahonnan küldte, feketelistán volt (időközben már lekerült onnan). Elég ciki, nem is nagyon értesül ilyenkor a feladó, hiszen feketelista alapján nincs bounce levél. IMAP-et használunk, az elküldött elemei közé szépen bele is került a levél, mint elküldött.

Mit lehet(ne) csinálni, hogy ilyen ne forduljon elő többet Láttatok-e hasonló problémát, van-e ötletetek? Arra gondolnék, legegyszerűbb megoldás az lenne, hogy az SMTP-re authentikált felhasználót már ne vizsgálja a feketelista alapján. De nem tudom, lehet-e ilyet és ha igen, akkor hogyan?

Erre vonatkozólag némi részletet közölnék a main.cf-ből:


mynetworks = 127.0.0.0/8, 192.168.6.0/24, 192.168.5.0/24
mailbox_command = /usr/bin/maildrop
home_mailbox = Maildir/
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_destination_recipient_limit = 200

############# Fontos beallitasok ####################
smtpd_delay_reject = yes
smtpd_helo_required = yes
disable_vrfy_command = yes
strict_rfc821_envelopes = yes
smtpd_soft_error = 5
smtpd_hard_error = 5
smtpd_error_sleep_time = 2s
message_size_limit = 30720000

smtpd_client_restrictions = check_client_access hash:/etc/postfix/access_client

smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access hash:/etc/postfix/access_email

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, reject_rbl_client cbl.abuseat.org, reject_rbl_client zombie.dnsbl.sorbs.net

############## SASL Authentikacio ####################
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

Természetesen a feketelisták jóval többen vannak felsorolva, de egyszerűség kedvéért, valamint paranoiás okok miatt csak párat hagytam meg. Mindegyik működik, ezeket szoktam is ellenőrizni időközönként, vannak, hogy megszűnnek, lesznek újak, de most nem is ez a lényeg, hiszen pont, hogy egy feketelista fogta meg a bejövő levelet, melyet egy kinti, authentikált kollégám írt egy másik kollégámnak, ugyanazon domainen belül...

Várnám ötleteiteket!

Ja, ha számít valamit, rendszer szintű felhasználóim vannak, nem adatbázisban tartom őket és a domaint.

A permit_sasl_authenticated a smtpd_client_restrictions -ban is használható. Egyébként a restrictions-ok össze is vonhatók:
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit blabla;
reject blabla

így könnyebben átlátható a sorrend, mert számít a sorrend és ha egy tiltás v. engedélyezés több helyen is használható akkor mindenhova érvényes lesz...

Válaszod köszönöm!

Az smtpd_sender_restrictioms-ben benne van az SASL-en keresztül authentiklált küldő engedélyezése, ennek ellenére az egyik feketelista mégis tiltotta a levél kézbesítését.

Az smtpd_client_restrictions változóm valóban elég gyér és nem tartalmazza a "permit_sasl_authenticated" részt, de úgy gondolom, ez nem segítene ezen a problémán. Rosszul gondolom? Értelmezési gondjaim lennének ezzel? Eléggé tanácstalan vagyok, hisz' ebben a részben szinte semmit sem tiltok, így gondolom a tiltás a feketelistákat tartalmazó "smtpd_sender_restrictions" sorom miatt lépett érvénybe...

Ez egy fogós kérdés. Nem néztem végig az RBL listád, de általánosságban az RBL listák között is van olyan ami csak a feladóra (e-mail) vonatkozik és van olyan ami a kliensre (IP, domain) vonatkozik. És mivel a kliens szűréseknél nálad nincs benne a permit_sasl_authenticated ezért én azon a véleményen vagyok, hogy valamelyik RBL lista megfoghatta a levelet (pontosabban a klienst)...

Mivel nem mutattal teljes konfigot csak tippelgetni lehet, ennek meg nem sok ertelme van. Kaptal egy hasznos tanacsot is, mi lenne a teendod elso korben, amit sikerult figyelmen kivul hagynod. Miert is ??? Amugy pedig kapcsold debug modba a postfix-et, pl. a debug_peer_list opcioval, es nezd meg, hol akad el a levelkuldes. Ez segithet megerteni a postfix mukodeset is.

Szia!

Véleményem szerint nem szükséges a többi részlete a konfig fájlnak, de legyen, itt van a "teljeses" konfig fájl. Értelem szerűen a feketelisták felsorolása nem teljes, túl hosszú lenne, valamint a domain nevet, melyet a szerver kezel, lecseréltem "sajat_domain"-re.


# 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 = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_banner = $myhostname ESMTP
biff = no

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

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

myhostname = mail.sajat_domain.hu
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = jupiter.sajat_domain.hu, localhost.sajat_domain.hu, localhost, sajat_domain.hu, sajat_domain.com, mail.sajat_domain.hu, mail.sajat_domain.com, jupiter.sajat_domain.com

relayhost =
mynetworks = 127.0.0.0/8, 192.168.6.0/24, 192.168.5.0/24

mailbox_command = /usr/bin/maildrop
home_mailbox = Maildir/
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_destination_recipient_limit = 200

############# Fontos beallitasok ####################
smtpd_delay_reject = yes
smtpd_helo_required = yes
disable_vrfy_command = yes
strict_rfc821_envelopes = yes
smtpd_soft_error = 5
smtpd_hard_error = 5
smtpd_error_sleep_time = 2s
message_size_limit = 30720000

smtpd_client_restrictions = check_client_access hash:/etc/postfix/access_client

smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access hash:/etc/postfix/access_email

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, reject_rbl_client cbl.abuseat.org, reject_rbl_client zombie.dnsbl.sorbs.net

smtpd_data_restrictions = reject_unauth_pipelining
queue_run_delay = 300s
minimal_backoff_time = 300s

############## SASL Authentikacio ####################
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

############# TLS ###################################
smtpd_use_tls = yes
smtpd_tls_auth_only = no
smtpd_tls_key_file = /etc/ssl/private/key.pem
smtpd_tls_cert_file = /etc/ssl/certs/cert.pem
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Valóban, kaptam egy tanácsot, melyet nagyon meg is köszöntem. Ellenben szerettem volna ezt a javaslatot átbeszélni, mielőtt agyonkonfigurálom a postfixemet, ugyanis szeretek tisztában lenni azzal, amit csinálok.

Mik ötlete az volt ugye, hogy a jelenlegi:
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access_client
soromat egészítsem ki a "permit_sasl_authenticated" értékkel.
Nem vitatom, hogy ez a megoldás. De úgy gondolom, hogy a mostani sorom csak azokat a kliensekre "érzékeny", melyek az "access_client"-ben tiltva, limitálva vannak. Más megszorítás nincsen, emiatt nem akadhat fent ezen a soron a levél továbbítása.

Neked mi a véleményed erről? Szerintem vitassuk meg, mi is van a konfig fájlban, a szerint minek is kellene teljesülnie - amennyiben partner vagy ebben.

A debug módba való kapcsolás is nagy ötlet, a gond ott van inkább, hogy ez egy elég kényelmetlen, egyelőre egyedi eset volt. Nagyon nehezen reprodukálható (mármint az, hogy egy feketelistás IP cím mögé dugjam egyik kollégámat és a tesztelések erejéig küldözgessen leveleket), viszont a vezetőség nagyon nehezen vette ezt a dolgot, így mindenképpen megoldást akarok erre találni. Olyan megoldást, ami ténylegesen megoldás.

Reszben ertheto az allaspontod, de azert azt hadd jegyezzem meg eloljaroban, hogy postfix konfig != main.cf. Egy rakas egyeb dolog lehet beallitva a master.cf-ben is, emellett a tovabbi file-ok (pl. /etc/postfix/access_*) tartalmanak ismerete nelkul tovabbra is csak tippelni lehet. Mindenesetre ha egy authentikalt felado levelet a gep siman relay-ezte kulso cimre, lokalisra viszont nem, akkor a szabalyok kiertekelesi sorrendje miatt csakis az smtpd_[client|sender]_restrictions lehet a hunyo.

Sajna nekem pont fordítva történtek a dolgok. Én SPAM szűrőt nem használok, rengeteg a külföldi ügyfél, talán ez is nehezíti a dolgot, de nagyon sok éles levél akadt fent, SPAM levelek meg jöttek is be mellette. Feketelisták jól mentek eddig, most mind az
smtpd_client_restrictions, mind az smtpd_sender_restrictions elejére felvettem a "permit_sasl_authenticated" opciót, remélem segít majd a dolgot, de igazából tesztelni nem nagyon áll módomban...

nem kételkedem a tapasztalataidban, de van egy óriási különbség a két módszer között:
az RBL listákat nem tudom semmilyen irányban befolyásolni, tehát bizony tévedhetnek, míg egy 99,5% körüli pontosságú SPAM szűrőt pedig könnyedén lehet építeni, ahol nem számít a felhasználók anyanyelve (globális és saját token adatbázis)...

--
by Mikul@s