Puncte:0

Postfix și subdomenii

drapel ci
Chr

Am configurat Postfix pe o mașină Ubuntu 20.04. Cu toate acestea, nu sunt sigur unde trebuie să folosesc subdomeniul și unde este domeniul. Să le numim mail.example.com și exemplu.com respectiv.

Sistemul este un client nul, care trimite e-mailuri, dar nu primește niciunul (implementat prin inet_interfaces = doar loopback în /etc/postfix/main.cf). Intenționez să trimit mesaje de la [email protected] exclusiv.

  • Recordul MX este @ IN MX 0 mail.example.com.
  • Un record pentru amândoi @ și Poștă indicați către serverul Postfix.
  • Certificatele TLS menționate în /etc/postfix/main.cf a se referi la mail.example.com: smtpd_tls_cert_file=/etc/letsencrypt/live/mail.example.com/fullchain.pem și smtpd_tls_key_file=/etc/letsencrypt/live/mail.example.com/privkey.pem.
  • Cu smtp_generic_maps = hash:/etc/postfix/generic rescriu utilizator@nume gazdă la [email protected] în /etc/postfix/main.cf.
  • Am adăugat masquerade_domains = example.com în /etc/postfix/main.cf pentru a înlocui mail.example.com în [email protected] cu exemplu.com. Cumva, asta nu funcționează. E-mailurile încă ajung de la expeditor [email protected].

Întrebările sunt în consecință:

  • Trebuie să folosesc @ sau Poștă în înregistrarea MX?
  • Certificatele TLS trebuie să se refere la mail.example.com sau la exemplu.com?
  • Ar trebui să /etc/postfix/generic primul convertit utilizator@nume gazdă în [email protected] sau direct în [email protected]?
Michael Hampton avatar
drapel cz
Dacă acest sistem nu este menit să primească e-mailuri, de ce i-ați direcționat mesajele primite în înregistrarea MX?
Chr avatar
drapel ci
Chr
@MichaelHampton Vă mulțumim pentru comentariu. Am citit că serverele de e-mail refuză de obicei să comunice cu serverele care nu au o înregistrare MX. ma insel?
Michael Hampton avatar
drapel cz
A nu avea o înregistrare MX este complet legitim, așa că nu știu de ce orice server de e-mail ar face asta. Poate unii fac. Desigur, a nu avea o înregistrare MX înseamnă că e-mailurile primite ajung la aceeași gazdă; înregistrarea MX are scopul de a redirecționa e-mailurile primite în altă parte.
Chr avatar
drapel ci
Chr
E bine de stiut. Mulțumiri. Se întâmplă să ai comentarii și la celelalte întrebări?
Michael Hampton avatar
drapel cz
Majoritatea tot ceea ce ați întrebat până acum se referă la _incoming_ mail, iar puținul care rămâne probabil se va schimba în funcție de ceea ce doriți de fapt, și anume: exact ce intenționați să faceți cu e-mailul primit?
anx avatar
drapel fr
anx
Dacă sunteți îngrijorat de faptul că oamenii *„refuză să comunice”* cu dvs., atunci *„trimite e-mailuri, dar nu primesc niciunul”* este primul lucru la care trebuie să vă adresați..
Chr avatar
drapel ci
Chr
@MichaelHampton Plănuiam să resping pur și simplu e-mailurile primite, fără a le admite deloc pe server.
Puncte:2
drapel za

Cel mai corect mod de a face acest lucru în zilele noastre este să creați un cont pe serviciul de corespondență adecvat, care este complet configurat pentru a servi exemplu.com. (Desigur, acesta ar putea fi propriul tău server, asta nu contează.) Apoi, pe gazda ta nulă, configurați serverul de e-mail doar ca o gazdă inteligentă, cu autentificare SASL.

Deși este perfect posibil să configurați Postfix astfel (există o mulțime de manuale, inclusiv al lui Postfix), cred că Postfix este exagerat pentru o astfel de utilizare. Luați în considerare utilizarea nullmailer, care este potrivit exact pentru sistemele care nu fac nimic cu e-mailul, cu excepția unor notificări de sistem.

Dacă acest lucru nu este posibil, configurați DNS astfel:

  • exemplu.com Înregistrarea MX indică serviciul său de corespondență adecvat. Nu are nimic de-a face cu subdomeniile.
  • nullhost.example.com. MX 10 ., adică arată spre nicăieri. Aceasta este o indicație explicită pentru care nu intenționați să primiți niciun mesaj [email protected]. Acest lucru nu este necesar dacă protejați serviciul smtpd al gazdei nul de conexiuni externe (firewall tcp/25, ascultă localhost:25 numai etc.); cu toate acestea, explicit este întotdeauna mai bine decât implicit.
  • această gazdă nulă va trimite e-mail care setează exemplu.com ca domeniu de expeditor, deci e-mailul trebuie să respecte setările DMARC pentru acel domeniu. În caz contrar, receptorii care se comportă corect își vor renunța e-mailurile.

Acest ultim punct, DMARC, ar putea complica lucrurile considerabil. Dacă este setat în siguranță, înseamnă că înregistrarea arată ca _dmarc.example.com. TXT "v=DMARC1; p=resping; pct=100; ...", va trebui să configurați semnarea SPF și DKIM pe gazda nulă. SPF este ușor, trebuie doar să adăugați „a:nullhost.example.com” în înregistrarea SPF TXT. DKIM este o provocare, va trebui să creați o pereche de chei DKIM suplimentară, să alegeți un selector (nullhost probabil va face), instalați perechea publică în DNS ca nullhost._domainkey.example.com. TXT „... date cheie...”. Apoi configurați singning cu cheia privată corespunzătoare direct pe gazda nulă (și utilizați selectorul ales), aș folosi opendkim pentru asta. Am menționat că folosirea smart host este metoda preferată?


Și întrebările tale.

  • Nu ești serverul (ai spus că acest sistem nu ar trebui să primească niciun e-mail). Deci nu aveți nevoie de niciun certificat TLS Server. Puteți configura lucrurile folosind certificatul client TLS, astfel încât atunci când vă conectați la gazda inteligentă sau la alte servere prin TLS, îl veți putea prezenta. Dar de ce ai vrea să faci asta?
  • Recordul „apex”. @ MX, a.k.a. exemplu.com. MX, trebuie direcționat către example.com mail eXchanger (sistemul care primește e-mail pentru [email protected]). Nu are nimic de-a face cu e-mailul pentru niciun subdomeniu. Fiecare subdomeniu este un domeniu de e-mail în sine.
  • Modul în care configurați rescrierea adreselor depinde de dvs. Singurul lucru pe care lumea exterioară îl vede este rezultatul final. Deci, de ce să te deranjezi să o faci în doi pași?
Chr avatar
drapel ci
Chr
Acesta este un răspuns foarte perspicace. Mulțumesc.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.