A Postfix 3.6.0 befogadó feltételekkel, fejlesztésekkel és egyebekkel rendelkezik

Egy év fejlesztés után megjelent a Postfix 3.6.0 levelezőszerver új stabil ága és egyúttal bejelentették a 3.2 elején megjelent Postfix 2017 fiók támogatását.

A Postfix az azon kevés projektek egyike, amelyek ötvözik a nagy biztonságot, megbízhatóságot és teljesítményt ugyanakkor ezt egy jól átgondolt architektúrának és a meglehetősen szigorú kódolási és javítási audit politikának köszönhettük.

Főbb újdonságok a Postfix 3.6.0

Ebben az új verzióban a „fehér” és a „fekete” szavakra történő hivatkozások tisztítását elvégezték, a közösség néhány tagja faji megkülönböztetésként érzékeli. A „fehér lista” és a „fekete lista” helyett most a következő kifejezéseket kell használniuk: „lista engedélyezése” és „lista elutasítása” (például a paraméterek postscreen_allowlist_interfaces, postscreen_denylist_action y postscreen_dnsbl_allowlist_threshold). A változtatások érintik a dokumentációt, a képernyő utáni konfigurációt (beépített tűzfal) és az információk tükröződését a naplókban.

A régi kifejezések megőrzése érdekében az iratokban, a «paraméterrespectful_logging=no', Amit meg kell adni a main.cf fájlban  és visszafelé kompatibilitás a régebbi beállításokkal szintén megmaradt visszafelé kompatibilitási okokból. A "master.cf" konfigurációs fájl egyelőre nem változott.

Sőt, egy másik kiemelkedő változás ennek az új verziónak a c módompatibility_level=3.6, az alapértelmezett átmenet az SHA256 hash függvény MD5 helyett történt.

Egy régebbi verzió konfigurálásakor az MD5 továbbra is alkalmazandó a kompatibilitási szint paraméterére, de a kivonattal kapcsolatos beállítások esetében, ahol az algoritmus nincs kifejezetten meghatározva, egy figyelmeztetés jelenik meg a naplóban.

A Diffie-Hellman kulcscsereprotokoll exportálási verziójának támogatása megszűnt (most a paraméter értékét figyelmen kívül hagyják tlsproxy_tls_dh512_param_file) egyszerűsítve a helytelen illesztőprogram megadásával kapcsolatos problémáktól a master.cf fájlban.

Az ilyen hibák felderítése érdekében minden belső szolgáltatás, beleértve a postdrop-ot is, az adatcsere megkezdése előtt közli a protokoll nevét, és minden ügyfélfolyamat, beleértve a sendmail-t is, ellenőrzi, hogy a meghirdetett protokollnév megegyezik-e a támogatott változattal.

is meg kell jegyezni, hogy új típusú feladatok kerültek hozzá «local_login_sender_maps« a küldő borítékcímének az SMTP-munkamenet során a "MAIL FROM" paranccsal átadott kiosztás rugalmas ellenőrzéséhez a sendmail és postdrop folyamatokhoz. Például annak engedélyezése, hogy a helyi felhasználók - a root és a postfix kivételével - csak a bejelentkezési nevüket adhassák meg a sendmail használatával az UID és a név közötti összerendeléssel.

A DNS alapértelmezett beállításai új API-t használnak amely alapértelmezés szerint támogatja a többszálas (szálbiztos) menetet. A fenti API-val történő fordításhoz meg kell adnia a fordításkor «make makefiles CCARGS="-DNO_RES_NCALLS... ”.

Hozzáadott mód «enable_threaded_bounces=yes»A kézbesítési problémákra vonatkozó értesítések cseréje, késleltetett kézbesítés vagy kézbesítési visszaigazolás ugyanazzal a vitaazonosítóval (az e-mail kliens ugyanabban a szálban jeleníti meg az értesítést a többi levelezési üzenet mellett).

Alapértelmezés szerint az / etc / services rendszeradatbázist már nem használják az SMTP és LMTP TCP portszámainak meghatározására. Ehelyett a portszámokat az ismert_tcp_ports paraméteren keresztül állítják be (alapértelmezett lmtp=24, smtp=25, smtps=submissions=465, submit=587). Abban az esetben, ha hiányzik egy szolgáltatás az ismert_tcp_portokból, az / etc / szolgáltatások továbbra is felhasználásra kerülnek.

A kompatibilitási szintet ("ompatibilitás_szint ") a" 3.6 "értékre emelték (a paramétert korábban kétszer változtatták meg, a 3.6 kivételével a 0 (alapértelmezett), az 1 és a 2 kompatibilis).

Mostantól a "ompatibilitás_szint "arra a verziószámra változik, ahol a kompatibilitást megsértő változtatások történtek. A kompatibilitási szintek ellenőrzéséhez külön összehasonlító operátorokat adtak a main.cf és a master.cf fájlokhoz, például "<= level" és "

Végül megemlítik azt a belső protokollok változásai miatt kommunikációra használják a Postfix összetevők között le kell állítani a levelező szervert a «postfix stop» paranccsal frissítés előtt.

Ennek elmulasztása összeomlást eredményezhet a pickup, a qmgr, az ellenõrzés, a tlsproxy és a postscreen folyamatokkal, amelyek késleltethetik az e-mailek küldését a Postfix újraindításáig.

Ha többet szeretne tudni róla, megteheti ellenőrizze a következő linket.


Legyen Ön az első hozzászóló

Hagyja megjegyzését

E-mail címed nem kerül nyilvánosságra. Kötelező mezők vannak jelölve *

*

*

  1. Az adatokért felelős: Miguel Ángel Gatón
  2. Az adatok célja: A SPAM ellenőrzése, a megjegyzések kezelése.
  3. Legitimáció: Az Ön beleegyezése
  4. Az adatok közlése: Az adatokat csak jogi kötelezettség alapján továbbítjuk harmadik felekkel.
  5. Adattárolás: Az Occentus Networks (EU) által üzemeltetett adatbázis
  6. Jogok: Bármikor korlátozhatja, helyreállíthatja és törölheti adatait.