Van egy mail szerver (legyen a neve akarmi.hu), amelyen postfix van, és az alábbi opció így van beállítva:
smtpd_sender_restricions = reject_sender_login_mismatch
Egy másik mail szerveren (legyen a neve masik.hu) az aliasba felveszek egy ilyet:
en: en,valaki@akarmi.hu
Ha levelet küldök barmi@barmi.hu feladóval az en@masik.hu címre, akkor az kézbesül a masik.hu szerveren, valamint továbbküldődik az akarmi.hu szerverre. De ha tetszoleges@akarmi.hu feladóval küldök levelet az en@masik.hu címre, akkor az alias miatt továbbküldött levelet az akarmi.hu visszautasítja az alábbi üzenettel:
said: 553 5.7.1 <tetszoleges@akarmi.hu: Sender address rejected: not logged in (in reply to RCPT TO command))
Szóval az akarmi.hu szerveren lévő userek nem tudnak úgy levelet küldeni az en@masik.hu címre, hogy az alias rendben továbbküldje a levelüket. Hogyan lehet megoldani ezt a helyzetet?
Hozzászólások
smtpd_sender_restricions = reject_sender_login_mismatch mit csinál?
A
smtpd_sender_restrictionsbeállítás az Postfix levelezőszerver konfigurációjában meghatározza, hogy milyen feltételek mellett fogadjon vagy utasítson el beérkező e-maileket a szerver.A
reject_sender_login_mismatchegy olyan opció, amely biztosítja, hogy a bejelentkezett felhasználó által használt email cím megegyezzen a hitelesített felhasználó azonosítójával. Ez különösen hasznos a levélszemét elleni védelemben és a felhasználói fiókok biztonságának növelésében.Konkrétan:
Példa konfigurációra:
smtpd_sender_restrictions = reject_sender_login_mismatchEzzel a beállítással a Postfix szerver biztosítja, hogy a feladó email cím hitelesítve legyen, és csak a bejelentkezett felhasználó használhatja saját email címét a küldéshez.
Köszi, én is megkérdeztem a chatgpt-t :) De nem igazán lettem okosabb, ezért bátorkodtam kérdezni. Sajnos az általad írt dolgoktól sem világosodtam meg.
Ha elmondod a megoldást, akkor megköszönöm.
Ne használd ezt a megszorítást, mert az alias miatt nem működik.
Ha kiveszem ezt a megszorítást a main.cf fájlból, majd telnettel bemegyek a szerverre (az smtp portra), akkor tudok az ottani felhasználó nevében levelet küldeni authentikálás nélkül (a relay nem működik, csak az adott szerveren belüli usereknek tudok levelet küldeni). De nekem ez nem annyira tetszik.
Mit kellene tennem, hogy ez (amit fent felvázoltam) ne működjön, az "alias-ból" érkező levelek azonban továbbítódjanak?
pl.:
smtpd_sender_restrictions = permit_mynetworks
(ha jól értem.)
Ezzel nem csak a postfix-nek megadott hálózatokból engedélyezné a levélküldést?
De.
Hogyan küldesz levelet? Webmail? Kliens?
Webmail, kliens + sasl auth.
alattam: hokuszpk
permit_sasl_authenticated
HUP te Zsiga !
Kipróbáltam, ez nem akadályozza meg azt, hogy authentikálás nélkül, feladóként egy - a szerveren - létező e-mail címet használva a szerveren más felhasználóknak levelet küldjek (például telnet-tel, ahogy korábban írtam). Vagy valami más beállítás engedélyezi ezt :(
Egyik élő szerveremen (k.rég csináltam, de teszi a dolgát, nem minden helyes benne):
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/access/helo,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_invalid_helo_hostname,
permit
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/access/sender_access,
check_sender_access pcre:/etc/postfix/access/reject_domains,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client bl.spameatingmonkey.net,
reject_rhsbl_sender fresh.spameatingmonkey.net,
reject_rhsbl_client fresh.spameatingmonkey.net,
reject_rhsbl_sender fresh30.spameatingmonkey.net,
reject_rhsbl_client fresh30.spameatingmonkey.net,
permit
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/access/sender_access,
check_client_access hash:/etc/postfix/access/rbl_override,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client bl.spameatingmonkey.net,
reject_rhsbl_sender fresh.spameatingmonkey.net,
reject_rhsbl_client fresh.spameatingmonkey.net,
reject_rhsbl_sender fresh30.spameatingmonkey.net,
reject_rhsbl_client fresh30.spameatingmonkey.net,
permit
Köszi! Meg tudnál csinálni egy tesztet?
Egy olyan hálózatból, amely nincs benne a "mynetworks"-ben, belépsz telnettel (vagy openssl-lel), és authentikálás nélkül küldesz egy levelet úgy, hogy a MAIL FROM-nak egy létező címet adsz meg, a RCPT TO-nak pedig akár ugyanazt, akár egy másik, a szerveren szintén létező címet? Tehát csak az ehlo, és utána MAIL FROM, RCPT TO, DATA.
küldj egyet nekem: oregon at linux user pont hu
Küldtem. "telnet level teszt" a subject-je.
megjött
gondolom ezt szeretnéd tiltani. ugye?
Jó ötlet lenne engedélyezni, hogy bárki egy főnök nevében olyan levelet küldhessen egy beosztottnak, amelyben utasítja valamire, amire egyébként nem akarja? :) Vagy a beosztott nevében elküldeni egy levelet a főnöknek, amelyben megmondja róla az igazi véleményét? :) És ezekhez csak a főnök és a beosztott e-mail címét kellene tudni...
Belső kommunikációhoz mi nem használunk emailt.
Akkor mondjuk úgy, ahogy fogalmaztál, hogy ezt szeretném tiltani :)
Ez a védelem a biztonság egy hamis illúziója, mert a hasonló domain reg vagy a munkavállaló saját emailre címére küldött hamis email még létezhet. Vannak akik a subjectet írják át és elhelyeznek benne infót, hogy külső vagy belső helyről jött. Minden ilyen szerintem részben nőveli a kockázatot, mert bealtatja a usert. Egyszerűbb annál maradni, hogy az email nem biztonságos, mindig gyanakodj. Vállalaton belül, meg mást használni.
Elfogadom, hogy ez a véleményed. De itt most egy technikai problémáról van szó, nem arról, amit kifejtettél.
Mellékesen: a usereknek alighanem fogalmuk sincs a dologról, ezért nem gondolom, hogy a biztonság hamis illúzióját keltené bennük :)
"Kipróbáltam, ez nem akadályozza meg azt, hogy authentikálás nélkül, feladóként egy - a szerveren - létező e-mail címet használva a szerveren más felhasználóknak levelet küldjek (például telnet-tel, ahogy korábban írtam). Vagy valami más beállítás engedélyezi ezt :("
azt valoban nem, mert a cimzett is helyi. tehat kb. azt akarod megakadalyozni, hogy a local userek tudjanak egymassal levelezni. de ha nagyon, akkor a master.cf -ben az smtphez ird :
-o smtpd_sasl_auth_enable=yes
mobilrol vagyok, esetleg a main.cf -et meg a master.cf smtpre vonatkozo sorait told be, aztan ha ejfel elott erek haza, es addig senki nem fejti meg, akkor ravetem magam.
HUP te Zsiga !
Nem azt akarom megakadályozni, hogy a local userek tudjanak egymással levelezni. Hanem azt, hogy ne tudjon bárki levelet küldeni egy lokális user nevében egy másik lokális usernek.
Tehát simán tudok küldeni úgy levelet egy címre az adott szerveren, hogy úgy látsszon, mintha legális levél lenne, rendes, szabályos feladóval, szabályos címzettel, szabályos tartalommal. Na, ez nekem nem annyira tetszik :)
na. sikerult megneznem a konfigunkat, en is reg csinaltam, fejbol már nemmegy :D es mar nememlexem pontosan mit is csinal, de majd a chatgpt :D szoval nalunk van egy ilyen :
smtpd_recipient_restrictions = reject_authenticated_sender_login_mismatch
HUP te Zsiga !
https://www.postfix.org/postconf.5.html
This prevents an authenticated client from using a MAIL FROM address that they do not explicitly own.
This feature is available in Postfix version 2.1 and later.
With SASL enabled, this prevents an unauthenticated client from using any MAIL FROM address that is listed in $smtpd_sender_login_maps.
This feature is available in Postfix version 2.1 and later.
A postconf manual-ja alapján úgy lehetne talán megfogalmazni a dolgot (az alap felvetést, miszerint az alias miatt továbbküldött levelet nem engedi be a címzett szervere), hogy a SASL engedélyezve van (a címzett szerverén), a levelet küldő kliens nem authentikál (mivel egy külső mail szerverről van szó), de a mail from-ban szereplő cím szerepel az $smtpd_sender_login_maps listában (így küldi tovább az alias miatt a külső mail szerver).
A megfelelő debug level-en ez látszik, ha az smtpd_sender_restrictions = reject_sender_login_mismatch:
generic_checks: name=reject_authenticated_sender_login_mismatch status=0
generic_checks: name=reject_unauthenticated_sender_login_mismatch status=2
generic_checks: name=reject_sender_login_mismatch status=2
Ha az smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, akkor nem fogja meg az "alias-ból érkező" levelet. Azonban ekkor a telnet-tel levelet küldő "trükk" is működik (amit korábban felvázoltam).
Én azt a problémádat nem értem, hogy ha nincs authentikáció, akkor mihez szeretnéd hasonlítani a feladó címét, hogy az mehet-e vagy sem...
Természetesen ha él a pertmit_mynetworks, és a mynetworks-ben fel van sorolva a belső hálózatod tartománya, akkor bárki tud hitelesítés nélkül levelet küldeni (bárkinek), és olyan feladót ír, amilyent csak akar, mivel nincs mihez hasonlítani, hogy azt szabad-e.
Normális esetben egy mail szerver levelet továbbításra kizárólag authentikáció után, titkosított csakornán vesz át (pl. SMTPS/465 vagy Submission/587), és sima SMTP/25-ön nem is fogad el levelet továbbításra sehogyan sem, az a bejövő leveleknek van fenntartva. Befelé érkező levél jöhet igény szerint titkosítatlanul, és ott ugye nem kell auth sem, nem értelmezhető.
Szóval, szerintem a problémát úgy tudod szakszerűen megoldani, hogy minden küldőtől (bármilyen hálózatban is van) kérsz authentikációt (a mynetworks lehet mindössze localhost és szinonímái), anélkül nem küldhet levelet, és onnantól a reject _authenticated_sender_login_mismatch megakadályozza, hogy a hitelesítőtől eltérő címmel küldjön.
Nincs a mynetworks-ben semmilyen külső cím, minden user sasl auth után küldhet levelet. Az smtpd_sender_login_maps-ban ellenőrzi a postfix, hogy a mail from-ban szereplő cím szerepel-e a címek között, akik küldhetnek levelet. A probléma az, hogy az "alias"-ból is azzal a mail from-mal továbbítódik a levél, amely szerepel az smtpd_sender_login_maps-ban. A reject_authenticated_send_login_mismatch kapcsán pedig már leírtam, hogy miért nem jó.
A kollega arra utalt, ha a szerver a világgal kíván levelezni, akkor auth nélkül is fogadnia kell levelet a saját domainre.
Természetesen fogad is, mint ahogy korábban már leírtam egy hasonló felvetésre reagálva.
azt vedd figyelembe hogy a reject_sender_login_mismatch a MAIL FROM: után megadott címre fut le, nem pedig a DATA után megadott "From:" fejlécre.
Ha belogolok alma@doma.in-el és a MAIL FROM: alma@doma.in, attól még simám megadhatom a DATA után From: korte@doma.in-t és ezt fogod látni a fogadó oldalon.
Köszi a figyelmeztetést, de ezt kivételesen tudom :) Egyébként itt pont arról van szó, hogy _authentikálás nélkül_ tud valaki egy létező cím nevében egy másik létező címnek levelet küldeni (az adott gépen létező címekről van szó, a relay nem működik).
ok, de a reject_sender_login_mismatch nem akasztja meg a levelet (Login és Mail From egyezik), a fogadó korte@doma.in azt látja, hogy ö küldte a levelet.
Ott tévedsz, hogy nincs auth login (se auth plain). Az ehlo után rögtön mail from, rctp to és data jön. És ekkor bizony megfogja a reject_sender_login_mismatch opció. Egész pontosan az rcpt to megadása után azonnal jön a "Sender address rejected: not logged in" üzenet, a data-t már nem várja meg.
igen de az megfog mindenkit aki nincs belogolva, tehát ezek szerint nem akarsz levelet fogadni sehonnan, csak olyanoktól akik belogolnak vagy belogoltak.
Azt kell, hogy mondjam, tévedsz. Korábban beidéztem a postconf manual-ját, ott elolvashatod, mit csinál ez az opció. Például, ha nem authentikált a küldő és a mail from-ban szereplő cím nem szerepel az $smtpd_sender_login_maps listában, akkor tud levelet küldeni a szerveren lévő usereknek.
Igazad van, összeraktam azokból az információkból amiket összehalásztam innen.
de nekem ment:
posfix config:
lehet ki kellene próbálnom úgy is hogy másik hálózatban vannak a szerverek
Ez mit ad vissza neked az mx.akarmi.hu gépen?
# postconf | grep ^smtpd_sender_login_maps
Ha nem üres az smtpd_sender_login_maps, akkor benne van a tetszoleges@akarmi.hu cím? Nem biztos, hogy az alábbi parancs jó, attól függ, hogy mi van a te változódban.
# postmap -q "tetszoleges@akarmi.hu" `postconf | grep ^smtpd_sender_login_maps | awk '{print $3}'`
Nekem benne van az adott user.
A chatgpt szerint:
Az
smtpd_sender_login_mapsopció tehát egy térképet definiál, amely összekapcsolja a feladó e-mail címeket a hitelesített felhasználói fiókokkal. Ez az opció különösen hasznos olyan környezetekben, ahol szigorúan ellenőrizni kell, hogy a felhasználók csak a saját, engedélyezett címükről küldhessenek e-maileket, ezáltal növelve a rendszer biztonságát és integritását.mindkettőn.
ha nincs valami@akarmi.hu akkor visszadob hogy nincs ilyen postafiók, ha van:
a masik.hu-n az en postafiók:
a mail:
most másik hálózatban van, a másik.hu a 192.168.178.140/24
ha nincs valaki@akarmi.hu
Azért működik, mert az smtpd_sender_login_maps nálad üres, nem adja vissza a user címét, aki a levelet küldi.
ha bekonfolom, akkor se az en@akarmi.hu-val se a tetszoleges@akarmi.hu-val sem tudok küldeni: Sender address rejected: not logged in
a map tartalma:
A "tetszoleges@akarmi.hu"-t kell visszaadnia jelen esetben. És az "en@masik.hu" címről simán el kell fogadnia a levelet.
atirtam a maps-ot, igy sem enged: Sender address rejected: not logged in
akarmi.hu
masik.hu:
talán hokuszpk kibogozza, nekem már késő van.
Nekem csak a "tetszoleges@akarmi.hu" nevet adja vissza a maps-t lekérdezve.
és emlékeim szerint az smtpd_sender_login_maps -al még az aliasokat is meg lehet engedni használni az egyébként autolt feladónak...
De itt nem authentikált felhasználóról van szó, hanem egy "alias-ból érkező" levélről, amely egy olyan mail from-mal jön, amely szerepel az smtpd_sender_login_maps-ban.
Valami olyasmi sejlik fel, hogy az smtpd a fogdáshoz van, ott lehet nem fog mindenki belogolni, megoldható az is, de pl a hamadik.hu-t nem fogod rávenni hogy authentikáljon nálad.
Ezt valahogy úgy szokás megoldani, hogy csak azokat a leveleket fogadod, ahol a címzett lokális és létezik, és a relay-nél követeled meg a logint és az azonosságot.
Az, hogy a tetszoleges@akarmi.hu címmel küldesz levelt a masik.hu-n keresztül, azzal nem csak a reject_sender_login_mismatch nem fog működni, de az SPF-et is elbassza.
De kicseréréheted a reject_sender_login_mismatch-t reject_authenticated_sender_login_mismatch-ra, akkor SASL nélküli küldőket nem fog meg.
Nem küldök, hanem az "alias-ból" így megy tovább. Már nézegettem, hogy továbbküldés esetén lehetne-e valamit csinálni, de egyelőre nem győzött meg, amit találtam :)
A javaslatod már szerepelt egyszer a thread-ben, akkor ki is próbáltam, le is írtam, hogy nem jó, mert a telnet-es dolgot nem fogja meg.
De köszi, hogy gondolkodsz a problémán.
Most akkor én nem értem. Az alias továbbítja a valaki@akarmi.hu-ra. De te az @akarmi.hu-s feladóval nem az @akarmi.hu-s szerveren át küldesz, az nem zavar, hogy így is bárki hamisíthatja a feladót, nem csak ha az akarmi.hu-t használja?
De a saját szervereden tudod némileg csökkenteni a kockázatot, ha felveszed az smtpd_relay_restrictions=permit_sasl_authenticated, így nem bejelentkezett user csak helyi usereknek tud küldeni. Ha meg azt akarod, hogy @akarmi.hu-s mailt csak bejelentkezett user küldhessen bárhova, akkor miért akarod, hogy bármilyen idegen szerverről jöhessen @akarmi.hu-s feladóval mail?
Kb. mintha fegyveres őrt állítanál a szerver elé, miközben interneten keresztül hekker pistikének is átjáróház.
Mindkét szervert én adminisztrálom, ahol az alias van beállítva, meg ahová érkezne a levél, azt is. Ha bármilyen más szerverről olyan mail from-mal érkezne levél, amely user létezik a szerveren, akkor pont a kezdésként említett smtp_sender_restrictions = reject_sender_login_mismatch fogja megakadályozni.
A már részletezett okból nem tartom jó ötletnek, hogy lokális usereknek lehessen levelet küldeni másik lokális user nevében, authentikáció nélkül.
Nem biztos, hogy megoldható az, amit felvetettem, ez is lehet elfogadható válasz.
Szóval neked olyan smtpd_sender_restrictions kell, ami kivételt tesz IP alapon a masik.hu-val. Mivel a sender_restrictions akkor él, ha a SASL engedélyezve van, esetleg megpróbálhatod a smtpd_sasl_exceptions_networks opciót, azaz a masik.hu-t engedheted bejelentkezés nélkül.
Köszi! Holnap megvizsgálom ezt a lehetőséget, hogy megoldást jelent-e, illetve milyen kockázatai vannak.
Sajnos nem jött be, ugyanúgy nem fogadta el a levelet.
"Mindkét szervert én adminisztrálom, ahol az alias van beállítva, meg ahová érkezne a levél, azt is."
ezesetben a legegyszerűbb megoldás az lehet, hogy az aliast hordozó szerver ipcimét beirod a mynetworksbe.
HUP te Zsiga !
Sajnos ez sem jött be.
Önmagában nem oldotta meg a problémámat, ha a mynetworks-be felvettem az alias-t "tartalmazó" gép IP címét.
De ha emellett az smtpd_sender_restrictions-be felvettem a permit_mynetworks opciót a reject_sender_login_mismatch elé, akkor már működött az "alias"-ból érkező levél elfogadása.
Köszi, még meg kell vizsgálnom, hogy ezek a beállítások mit jelentenek a rendszer egészére nézve.
jahogy ennyire szigoru vagy, hogy még a mynetworksban sem bizol :D
HUP te Zsiga !
Esetleg megoldás lehet különválasztani az imap és smtp szervert. Ez az opció neked csak az smtp szervernél kell. Imapnál nem lesz beállítva, így fogadásnál tuti nem okoz gondot.
Az IMAP szerver nem fogad levelet. A levél küldés és fogadás egyaránt az MTA ("SMTP szerver") dolga minden esetben. Az IMAP szerver csak a postafiók kezelést végzi.
Igen, kicsit pontyolán fogalmaztam.
Szóval nálam úgy van, hogy MTA (Postfix) + MDA (Dovecot, IMAP) egy szerveren,ez az MX.
Másik szerveren Postfix + Dovecot, mint smtp. Userek ide küldik a levelet. Itt lehet csinálni mismatch szabály, senkit nem zavar.
Ha alias van, az az MX szerveren kerül kifejtésre. Nem vesznek össze a fenti szabállyal.
Nem igazán értem, úgy az egészet.
Az MX-nek titulált szerver egy SMTP szerver. Nem kell hozzá Dovecot, hogy SMTP szerver legyen, csak mondjuk abban az esetben, ha LMTP-nek azt akarod használni, hogy ne a Postfix írjon közvetlenül a Maildir-be (pl. quota kezelés miatt), vagy esetleg azért futtatod mellette a Doveco-ot, hogy a SASL AUTH-ot adja az SMTP-hez.
A "másik" szerver, amit írsz, hogy SMTP szerver, oda sem kell a Dovecot ahhoz, hogy SMTP szerver legyen. A Postfix maga az SMTP szerver. A Dovecot extra szolgáltatást tud igény szerint nyújtani neki, meg persze IMAP/POP3 szerverként tud kiszolgálni igény szerint.
Plusz, nem derül ki, miért van két szerver egymás után, mi a célja ennek a felállásnak.
"Az MX-nek titulált szerver egy SMTP szerver."
Nézőpont kérdése. A nagyvilág felől ez egy smtp, mert fogadja az ide érkező leveleket a 25-ös porton, hiszen itt van a domain MX rekordja.
Userek ide nem küldenek levelet, postfixban ez van: smtpd_sasl_auth_enable = no. Nem ezt használják a lev.kliensből smtp szervernek. Nem is lehet rá autholni.
A dovecot azért kell, mert ezen a szerveren van az IMAP kiszolgálás. Erre Postfix mellett a Courier és a Dovecot ad jó megoldást. Én egy ideje a Dovecotot használom, többek között a Sieve plugin miatt.
A másik szerver pedig (userek felől nézve) dedikált smtp szerver.
Postfixban:
/etc/postfix/main.cf:smtpd_sasl_type = dovecot
/etc/postfix/main.cf:smtpd_sasl_auth_enable = yes
Postfix önállónan _tudtommal_ nem képes virtual user táblából SASL auth-ot adni. Erre pl. a Cyrus SASL, vagy a Dovecot lehet egy jó irány. Én itt is a Dovecotot használom. Dovecotban a protocol = változó üres. Csak smtp szolgáltatás miatt fut.
"Plusz, nem derül ki, miért van két szerver egymás után, mi a célja ennek a felállásnak."
Nincs egymás után. Egymás mellett van. Ha a nagyvilág küld levelet, az az MX-en landol. A botnetek ezt buzerálják, mert ezt látják az MX feltüntetése miatt.
Az smtp pedig csak az userek számára ismert.
Ha állítottál már lev.kliensen imap fiókot, biztos láttad, hogy külön szekció van a levelek fogadására (IMAP/POP3) és küldésére (SMTP). Ezen 2 címnek nem szükségszerű egynek lenni. Szerintem jobb is külön.
Most, hogy beszélünk róla, még az MX-et külön lehetne szedni az MDA-ról (IMAP), így a kliensek IMAP szervere is egy rejtettebb címen lehetne, külön az MX-től.
Neked a userek és az aliasok miben vannak? (sql? nativ?)
Chatgpt szerint sql esetén:
smtpd_sender_login_maps = mysql:/etc/postfix/mysql_sender_login_maps.cf
Ahol a /etc/postfix/mysql_sender_login_maps.cf tartalma (természetesen customizálni kell):
Ez ugye a bejelentkezett levélküldést korlátozza (smtpd_sender_restrictions -ben lévő szűkítések miatt). A bejelentkezés nélküli domained használatára (levél fogadás) nem megoldás (ott a smtpd_client_restrictions szabályok dominálnak) . Arra ott az SPF és a felhasználóidnál a webmail kikényszerítése. Ahogy kliens alkalmazást is engedélyezel, már dől minden. (Képességeim és ismereteim szerint.)
Mivel a userek és az alias-ok nem ugyanazon a gépen vannak, ez nem tűnik járható útnak.
Bocs, ha nem mondok újat:
A main.cf a default és ezekkel az értékekkel dolgozik a master.cf is, de ez utóbbiban felül lehet írni a -o kapcsolóval, pl.:
A "-o smtpd_helo_restrictions=" kinullázza a main.cf-ben beállított szigorítást.
Ez neked azért fontos, mert a 25-ös port a világnak van és mondjuk az 587-es felhasználóknak, akkor különböző szabályokat tudsz létrehozni a két port mögé. Azt gondolom, hogy ezen elindulva össze tudsz rakni olyan szabályt ami kedvedre való lenne.
Köszi az ötletet, megvizsgálom a dolgot, hogy össze tudok-e rakni olyat, amivel elégedett lennék :)
Közben játszottam vele és talán az üres az nem biztos, hogy nulláz, lehet kel egy "premit" oda.
(ChatGPT szerint kinullázza)