Postfix: Relay access denied

Web, mail, IRC, IM, hálózatok

Üdv!

Kérdésem arra vonatkozik, hogy mely "restriction" -ra ad a postfix ilyen
választ?
Az a gond, hogy a saját hálózaton belülről (mynetworks) küldenének olyan
levelet, melynél a sender (küldő) nem a saját, általunk kezelt domain -ből
való.
Azt szeretném, hogy az ügyfél levele minél több smtpd_xxxx_restriction
ellenőrzésén menjen keresztül, mielőtt a permit_mynetwork -höz ér.

Jelenleg ez a sorrend:

smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
reject_non_fqdn_helo_hostname,
# warn_if_reject
reject_unauth_pipelining,
reject_unauth_destination,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_client_hostname,
reject_unknown_sender_domain,
reject_unverified_sender,
check_client_access hash:/etc/postfix/access_client,
check_recipient_access hash:/etc/postfix/access_recipient,

smtpd_data_restrictions =
smtpd_end_of_data_restrictions =
reject_multi_recipient_bounce,
permit

Ezek a paraméterek még, ami fontos lehet:

strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes

  • 5459 megtekintés

( Mcsiv v | 2010. 08. 11., sze – 09:36 )

elvileg a "reject_unknown_sender_domain"

Üdv!

Ez igaz, csak az később van a sorban, mint a "permit_mynetwork". Így az a fajta
ellenőrzés, csak a külső (fogadott) leveleknél történik.

Az elöbb azt elfelejtettem leírni, hogy a fenti config mellett a saját belső
hálózaton lévő ügyfelek leveleit, a postfix "relay access denied" hibával
visszaküldi, amennyiben nem az általunk kezelt domain tartományból van.
(tipikus eset, hogy az otthoni/magán stb email címről küldene levelet ezzel a serverrel.)

Tilla

ok, de a szívások jelentős része abból ered, hogy magát a hibát sem jól azonosítják....

Mindenesetre a reject_unauth_destination adja ezt a hibaüzenetet, amit a kolléga említ.
A permit_mynetwork-ot álltalában a reject_unauth_destination elé szokás rakni...

szerk:
szerintem az van, hogy a saját domainban levő feladóknak a check_sender_access miatt bárhova lehet levelet küldeni,
a nem saját domainű feladók pedig csak a saját domainra tudnak levelet küldeni, mert minden mást kiszűr a reject_unauth_destination.

Próbálom értelmezni amit írtál:

ok, de a szívások jelentős része abból ered, hogy magát a hibát sem jól azonosítják....
Mit kéne azonosítani? A hibát "azonosítottam", csak nem volt érthető számomra az oka.

A permit_mynetwork-ot álltalában a reject_unauth_destination elé szokás rakni...

Doksi:
Reject the request unless one of the following is true:
- Postfix is mail forwarder: the resolved RCPT TO domain matches $relay_domains or a subdomain thereof, and contains no sender-specified routing (user@elsewhere@domain),
- Postfix is the final destination: the resolved RCPT TO domain matches $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, or $virtual_mailbox_domains, and contains no sender-specified routing (user@elsewhere@domain).

Mi köze van akkor a kettőnek egymáshoz, vagy mitől vált szokássá?

szerintem az van, hogy a saját domainban levő feladóknak a check_sender_access miatt bárhova lehet levelet küldeni...

Ebben a file-ban csak tiltások vannak. Azok, akik normál (szabályos) levélben
próbálnak agitálni tömegesen bizonyos dolgokra :)

Még egy kérdés felmerült bennem, a logok és az ügyfelek telefonjai alapján:

A levél küldés során ezek is lapátra kerülnek, de miért így töltődik ki? Mely
kliens beállítás az, ami ezt okozza:

proto=SMTP helo=userfa453cbd44

A visszautasítás pedig: Helo command rejected: Host not found;

"Mit kéne azonosítani? A hibát "azonosítottam", csak nem volt érthető számomra az oka."

"Relay acces denied" hibaüzenetet kapsz, és szerinted ez mégis sender hiba... nem lehet, hogy mégis relay hiba?

"Mi köze van akkor a kettőnek egymáshoz, vagy mitől vált szokássá?

Ha a permit_mynetworks-ot a reject_unauth_destination UTÁN rakod, akkor a saját kliensek számára explicite engedni kell valami módon a relayt... nehezen átlátható konfigod lesz.

Szerintem ez a konfig elég gáz..
Ha gondolod, próbáld ki amit írtam, de egyébként további jó "rejtvényfejtést".

"Relay acces denied" hibaüzenetet kapsz, és szerinted ez mégis sender hiba... nem lehet, hogy mégis relay hiba?

De, relay hiba, csak ugye a sender domain alapján dönt úgy, hogy relay hiba.
Erre - kellett volna - megoldás, de úgy látom a logok alapján, hogy igazán
egészséges megoldás nincs.
Ha azt teszem amit írtál, tehát hogy előbbre kerül "permit_mynetworks", akkor az
ügyfelek (belső hálózatról simán küldenek hamisított leveleket, (SPAM, vírus, outlook, sbt) mert kienged olyan levelet, aminél a sender nem az általunk kezelt
domain tartományban van, csak azért mert permit_mynetworks
pl.:
NOQUEUE: reject: RCPT from unknown[192.168.27.53]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo=<[192.168.0.200]>
Ez itt most(!) reject, csere után sima útja van!

Így marad az explicit megadás, ami valóban macerás.

Azért arra még kíváncsi vagyok, hogy ez a konfig mitől "gáz" (had tanuljak egy kicsit...) (Az idézett konfig csak egy részlet...)

Végső megoldás valószínűleg úgy is az SMTP auth lesz.

" azügyfelek (belső hálózatról simán küldenek hamisított leveleket, (SPAM, vírus, outlook, sbt) mert kienged olyan levelet, aminél a sender nem az általunk kezeltdomain tartományban van, csak azért mert permit_mynetworks"

malware-ek gyakran az áldozat email címét használják feladónak.
Ok, egyébként viszonylag reális, amit akarsz, és van is rá megoldás.

Valami hasonló lehet jó:

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/check_local_users,
permit_mynetworks

A /etc/postfix/check_local_users -t úgy rakod össze, hogy DEFER_IF_PERMIT választ ad, ha nem saját domain a feladó címe, saját feladóra pedig OK-t.

Így, visszavágja a saját hálón lógó, email cím hamisító usert.
(Az smtpd_recipient_restrictions -ből ezután kiszedhető a permit_mynetworks.)
A helo szabályok ezután nem fognak local userre lefutni, ami egyébként is teljesen felesleges.

szerk: abban nem vagyok biztos, hogy a DEFER_IF_PERMIT hatása nem "lóg át" az smtpd_recipient_restrictions szekcióba, bár nem lenne túl logikus...

A /etc/postfix/check_local_users -t úgy rakod össze, hogy DEFER_IF_PERMIT választ ad, ha nem saját domain a feladó címe, saját feladóra pedig OK-t.

Köszi, ez a megoldás jónak tűnik. Mégis egyszerűbb felügyelni/karbantartani a
bejegyzésben azokat a domain-eket, melyeket én kezelek, mint egyesével figyelni a
sok user egyéni email címeire. (Megfordult a fejemben hogy kitiltok minden egyéb
domaint, de lehet nem lenne munkám 1-2 hét alatt :)

Az egyetlen dolog ami más, hogy az "smtpd_delay_reject = yes" miatt a "rcpt to"
-ig nem él egyetlen reject sem. Emiatt van egyetlen restriction -ban az összes
feltétel.
Emiatt nem kardinális ez az általad említett dolog:
szerk: abban nem vagyok biztos, hogy a DEFER_IF_PERMIT hatása nem "lóg át" az smtpd_recipient_restrictions szekcióba, bár nem lenne túl logikus...

"Az egyetlen dolog ami más, hogy az "smtpd_delay_reject = yes" miatt a "rcpt to"-ig nem él egyetlen reject sem. "

Egyébként is "yes" a default, szóval felesleges külön beletenni.
Ettől még ugyanolyan sorrendben és ugyanolyan logikával értékeli ki az összes restriction blokkot, mintha "no" lenne.

"A levél küldés során ezek is lapátra kerülnek, de miért így töltődik ki? Mely
kliens beállítás az, ami ezt okozza:

proto=SMTP helo=userfa453cbd44"

Gondolom windows hálózatról van szó (esetleg AD-vel?)
A reject_unknown_helo_hostname vágja vissza, mert nem tudja map-ból, vagy reverse DNS-ből feloldani.
De ha sikerülne is, akkor visszavágná a következő, a reject_non_fqdn_helo_hostname.

Ha már unod, hogy folyton lábon lövöd magad, akkor rakd már az elejére azt a nyomorult permit_mynetwork-öt, vagy debugoljátok végig a teljes kliens infrastruktúrát, írjátok át a hostneveket, legyen működő reverse dns, és akkor a permit_mynetwork -öt akár ki is szedheted az egészből, mert az előtte levő szabályokkal kb. ugyanazt próbálod implementálni....

Azt hogy melyik restriction vágja ki, azt én is tudom, a kérdés arra vonatkozott,
miért jön némelyiktől rendesen, és miért jön némelyiktől fos. (bocsánat)

Való igaz, a permit_mynetworks a sor elején megoldana mindent, csak éppen
nem a problémát oldanám meg, hanem a tüneteket.

A reverse DNS pedig nem old meg semmit. Attól nem lesz tisztességes helo érték.
A klienseket végig debuggolni, meg egy hangyányit macera, kb 1600-1800 kliens. Ráadásul
nincs is ráhatásom azokra a gépekre.

( Cseresznye | 2013. 01. 23., sze – 17:41 )

Helló

Biztosan én csesztem el valamit, 554 5.7.1-t (relay access denied) kapok egy engem relay-ként használó, mynetworks-ön kívüli smtp-ről.

Restrikciók nálam:

smtpd_client_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_reverse_client_hostname,
#reject_rbl_client rhsbl.sorbs.net,
#reject_rbl_sender rhsbl.sorbs.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client blackholes.easynet.nl,
reject_rbl_client cbl.abusenet.org,
#reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
check_policy_service inet:127.0.0.1:60000

smtpd_helo_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_non_fqdn_hostname

smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,

smtpd_recipient_restricitons =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,

smtpd_data_restrictions =
reject_multi_recipient_bounce,

Ha belül van, auth-al és nélküle is tud küldeni (ez egyelőre jó így).
Az auth működik (rossz jelszónál kivág).