postfix smtpd_sender_restrictions = reject_sender_login_mismatch

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

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?

  • 689 megtekintés

( uid_17626 | 2024. 08. 07., sze – 11:50 )

Szerkesztve: 2024. 08. 07., sze – 11:50

smtpd_sender_restricions = reject_sender_login_mismatch mit csinál?

A smtpd_sender_restrictions beá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_mismatch egy 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:

  • reject_sender_login_mismatch: Elutasítja azokat az e-maileket, ahol a feladó email cím nem egyezik meg a hitelesített felhasználó nevével. Ez azt jelenti, hogy ha egy felhasználó bejelentkezik a szerverre, és egy másik email címet próbál használni feladóként, akkor a szerver elutasítja az email küldését.

Példa konfigurációra:


 

smtpd_sender_restrictions = reject_sender_login_mismatch

Ezzel 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.

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?

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.

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...

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.

"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

reject_sender_login_mismatch
As of Postfix 2.1, this is an alias for "reject_authenticated_sender_login_mismatch, reject_unauthenticated_sender_login_mismatch".
reject_authenticated_sender_login_mismatch
Reject the request when the client is authenticated with SASL, but either the MAIL FROM address is not listed in $smtpd_sender_login_maps, or the SASL login name is not an owner for that address.
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.
reject_unauthenticated_sender_login_mismatch
Reject the request when SASL is enabled, the MAIL FROM address is listed in $smtpd_sender_login_maps, but the client is not authenticated with SASL.
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.
 
Ezt is kipróbáltam, és 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 nálam :(

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ó.

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.

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.

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:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = reject_sender_login_mismatch
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

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_maps opció 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.

root@mx:~# postconf | grep ^smtpd_sender
smtpd_sender_login_maps =
smtpd_sender_restrictions = reject_sender_login_mismatch

mindkettőn.

ha nincs valami@akarmi.hu akkor visszadob hogy nincs ilyen postafiók, ha van:

Aug 07 21:27:41 mx postfix/smtpd[3660]: connect from mx.akarmi.hu[192.168.177.138]
Aug 07 21:30:55 mx postfix/smtpd[3660]: 580704042D: client=mx.akarmi.hu[192.168.177.138]
Aug 07 21:31:17 mx postfix/cleanup[3667]: 580704042D: message-id=<>
Aug 07 21:31:17 mx postfix/qmgr[3578]: 580704042D: from=<tetszoleges@akarmi.hu>, size=208, nrcpt=1 (queue active)
Aug 07 21:31:17 mx postfix/local[3668]: 580704042D: to=<en@mx.masik.hu>, orig_to=<en@masik.hu>, relay=local, delay=28, delays=28/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Aug 07 21:31:17 mx postfix/cleanup[3667]: 37C094042E: message-id=<>
Aug 07 21:31:17 mx postfix/local[3668]: 580704042D: to=<en@masik.hu>, relay=local, delay=28, delays=28/0/0/0, dsn=2.0.0, status=sent (forwarded as 37C094042E)
Aug 07 21:31:17 mx postfix/qmgr[3578]: 37C094042E: from=<tetszoleges@akarmi.hu>, size=327, nrcpt=1 (queue active)
Aug 07 21:31:17 mx postfix/qmgr[3578]: 580704042D: removed
Aug 07 21:31:17 mx postfix/smtp[3669]: 37C094042E: to=<valaki@akarmi.hu>, orig_to=<en@masik.hu>, relay=mx.akarmi.hu[192.168.177.138]:25, delay=0.04, delays=0/0.01/0.02/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 40A936020D)
Aug 07 21:31:17 mx postfix/qmgr[3578]: 37C094042E: removed

telnet 192.168.178.140 25
Trying 192.168.178.140...
Connected to 192.168.178.140.
Escape character is '^]'.
220 mx.masik.hu ESMTP Postfix (Debian/GNU)
ehlo me
250-mx.masik.hu
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
mail from: tetszoleges@akarmi.hu
250 2.1.0 Ok
rcpt to: en@masik.hu
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Teszt
From: en@masik.hu
Teszt
.
250 2.0.0 Ok: queued as 580704042D
quit
221 2.0.0 Bye
Connection closed by foreign host.

a masik.hu-n az en postafiók:

 s-nail
s-nail version v14.9.24.  Type `?' for help
/var/mail/en: 1 message
▸O  1 en@masik.hu        Wed Aug  7 21:31   13/356   Teszt

a mail:

From tetszoleges@akarmi.hu  Wed Aug  7 21:31:17 2024
Return-Path: <tetszoleges@akarmi.hu>
X-Original-To: en@masik.hu
Delivered-To: en@masik.hu
Received: from me (mx.akarmi.hu [192.168.177.138])
        by mx.masik.hu (Postfix) with ESMTP id 580704042D
        for <en@masik.hu>; Wed,  7 Aug 2024 21:30:49 +0200 (CEST)
Subject: Teszt
From: en@masik.hu
Status: RO

Teszt

most másik hálózatban van, a másik.hu a 192.168.178.140/24

ha nincs valaki@akarmi.hu

Aug 07 21:39:07 mx postfix/cleanup[3698]: 7A71E4042D: message-id=<>
Aug 07 21:39:07 mx postfix/qmgr[3578]: 7A71E4042D: from=<tetszoleges@akarmi.hu>, size=190, nrcpt=1 (queue active)
Aug 07 21:39:07 mx postfix/local[3699]: 7A71E4042D: to=<en@mx.masik.hu>, orig_to=<en@masik.hu>, relay=local, delay=22, delays=22/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Aug 07 21:39:07 mx postfix/cleanup[3698]: 1CF914042E: message-id=<>
Aug 07 21:39:07 mx postfix/qmgr[3578]: 1CF914042E: from=<tetszoleges@akarmi.hu>, size=309, nrcpt=1 (queue active)
Aug 07 21:39:07 mx postfix/local[3699]: 7A71E4042D: to=<en@masik.hu>, relay=local, delay=22, delays=22/0/0/0, dsn=2.0.0, status=sent (forwarded as 1CF914042E)
Aug 07 21:39:07 mx postfix/qmgr[3578]: 7A71E4042D: removed
Aug 07 21:39:07 mx postfix/smtp[3700]: 1CF914042E: to=<valaki@akarmi.hu>, orig_to=<en@masik.hu>, relay=mx.akarmi.hu[192.168.177.138]:25, delay=0.08, delays=0/0.01/0.06/0.01, dsn=5.1.1, status=bounced (host mx.akarmi.hu[192.168.177.138] said: 550 5.1.1 <valaki@akarmi.hu>: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command))
Aug 07 21:39:07 mx postfix/cleanup[3698]: 304BB40431: message-id=<20240807193907.304BB40431@mx.masik.hu>
Aug 07 21:39:07 mx postfix/bounce[3701]: 1CF914042E: sender non-delivery notification: 304BB40431
Aug 07 21:39:07 mx postfix/qmgr[3578]: 304BB40431: from=<>, size=2415, nrcpt=1 (queue active)
Aug 07 21:39:07 mx postfix/qmgr[3578]: 1CF914042E: removed
Aug 07 21:39:07 mx postfix/smtp[3700]: 304BB40431: to=<tetszoleges@akarmi.hu>, relay=mx.akarmi.hu[192.168.177.138]:25, delay=0.05, delays=0/0/0.04/0, dsn=5.1.1, status=bounced (host mx.akarmi.hu[192.168.177.138] said: 550 5.1.1 <tetszoleges@akarmi.hu>: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command))
Aug 07 21:39:07 mx postfix/qmgr[3578]: 304BB40431: removed
echo "TEST" | s-nail -s "TEST" -r tetszoleges@akarmi.hu en@masik.hu

akarmi.hu

Aug 07 22:10:23 mx postfix/pickup[8173]: DE0F460212: uid=0 from=<tetszoleges@akarmi.hu>
Aug 07 22:10:23 mx postfix/cleanup[8217]: DE0F460212: message-id=<20240807201023.ko1EH%tetszoleges@akarmi.hu>
Aug 07 22:10:23 mx postfix/qmgr[8174]: DE0F460212: from=<tetszoleges@akarmi.hu>, size=303, nrcpt=1 (queue active)
Aug 07 22:10:23 mx postfix/smtp[8219]: DE0F460212: to=<en@masik.hu>, relay=mx.masik.hu[192.168.178.140]:25, delay=0.06, delays=0.01/0/0.05/0, dsn=5.7.1, status=bounced (host mx.masik.hu[192.168.178.140] said: 553 5.7.1 <tetszoleges@akarmi.hu>: Sender address rejected: not logged in (in reply to RCPT TO command))
Aug 07 22:10:23 mx postfix/cleanup[8217]: EC6CA60217: message-id=<20240807201023.EC6CA60217@mx.akarmi.hu>
Aug 07 22:10:23 mx postfix/bounce[8220]: DE0F460212: sender non-delivery notification: EC6CA60217
Aug 07 22:10:23 mx postfix/qmgr[8174]: EC6CA60217: from=<>, size=2328, nrcpt=1 (queue active)
Aug 07 22:10:23 mx postfix/qmgr[8174]: DE0F460212: removed
Aug 07 22:10:23 mx postfix/local[8221]: EC6CA60217: to=<tetszoleges@akarmi.hu>, relay=local, delay=0.01, delays=0/0/0/0, dsn=5.1.1, status=bounced (unknown user: "tetszoleges")
Aug 07 22:10:23 mx postfix/qmgr[8174]: EC6CA60217: removed

masik.hu:

Aug 07 22:10:23 mx postfix/smtpd[3820]: connect from mx.akarmi.hu[192.168.177.138]
Aug 07 22:10:23 mx postfix/smtpd[3820]: NOQUEUE: reject: RCPT from mx.akarmi.hu[192.168.177.138]: 553 5.7.1 <tetszoleges@akarmi.hu>: Sender address rejected: not logged in; from=<tetszoleges@akarmi.hu> to=<en@masik.hu> proto=ESMTP helo=<mx.akarmi.hu>
Aug 07 22:10:23 mx postfix/smtpd[3820]: disconnect from mx.akarmi.hu[192.168.177.138] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

talán hokuszpk kibogozza, nekem már késő van.

( Tom | 2024. 08. 07., sze – 11:50 )

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.

( Zsugabubus | 2024. 08. 07., sze – 21:13 )

Szerkesztve: 2024. 08. 07., sze – 21:14

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.

Ö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.

( Proci85 v | 2024. 08. 07., sze – 21:51 )

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.

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.

( uid_17626 | 2024. 08. 08., cs – 10:37 )

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):
 

user = postfix_user
password = postfix_password
hosts = 127.0.0.1
dbname = postfix
query = SELECT username FROM users INNER JOIN aliases ON users.id=aliases.user_id WHERE aliases.alias='%s' AND users.username='%s' AND users.active=1

 

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.)

( uid_17626 | 2024. 08. 08., cs – 17:38 )

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.:

 

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_helo_restrictions=
  -o milter_macro_daemon_name=ORIGINATING

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.