MX -rekord - MX record
En postvekslerpost ( MX -post ) angiver den mailserver, der er ansvarlig for at acceptere e -mail -meddelelser på vegne af et domænenavn. Det er en ressourcepost i Domain Name System (DNS). Det er muligt at konfigurere flere MX -poster, der typisk peger på en række mailservere til belastningsbalancering og redundans.
Oversigt
Ressourceposter er det grundlæggende informationselement i Domain Name System (DNS). En MX -post er en af disse, og et domæne kan have en eller flere af disse opsat som nedenfor:
Domain TTL Class Type Priority Host example.com. 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com.
Den karakteristiske nyttelastinformation for en MX -post er en præferenceværdi (ovenfor mærket "Prioritet") og domænenavnet på en mailserver ("Host" ovenfor).
Prioritetsfeltet identificerer, hvilken mailserver der skal foretrækkes - i dette tilfælde er værdierne begge 10, så post forventes at flyde jævnt til både onemail.example.com og twomail.example.com - en fælles konfiguration. Værtsnavnet skal tilknyttes direkte til en eller flere adresseposter (A eller AAAA) i DNS og må ikke pege på nogen CNAME -poster .
Når der sendes en e-mail-besked via Internettet, forespørger den afsendende e-mailoverførselsagent (MTA) domænenavnsystemet om MX-registreringer for hver modtagers domænenavn . Denne forespørgsel returnerer en liste over værtsnavne på e -mailudvekslingsservere, der accepterer indgående mail for dette domæne og deres præferencer. Afsendelsesagenten forsøger derefter at etablere en SMTP -forbindelse og prøver først værten med den laveste "prioritet" -værdi. Systemet gør det muligt at bygge klynger af mail-gateways med høj tilgængelighed til et domæne, hvis det er nødvendigt.
MX-mekanismen giver ikke mulighed for at levere mailservice på alternative portnumre , og den giver heller ikke mulighed for at distribuere postlevering på tværs af et sæt ulige prioriterede mailservere ved at tildele en vægtningsværdi til hver enkelt.
MX præference, afstand og prioritet
Ifølge RFC 5321 er de lavest nummererede poster de mest foretrukne. Denne formulering kan være forvirrende, og derfor kaldes præferencetallet undertiden som afstanden : mindre afstande er mere at foretrække. En ældre RFC, RFC 974, angiver, at når præferencenumrene er ens for to servere, har de samme prioritet , derfor bruges de to udtryk i flæng.
Det grundlæggende
I det enkleste tilfælde kan et domæne kun have én mailserver. For eksempel, hvis en MTA søger efter MX -registreringerne for example.com, og DNS -serveren svarede med kun mail.example.com med et præferencetal på 50, vil MTA forsøge at levere mailen til den angivne server. I dette tilfælde kunne tallet 50 have været et hvilket som helst heltal tilladt af SMTP -specifikationen.
Når mere end én server returneres for en MX -forespørgsel, skal serveren med det mindste præference -nummer først prøves. Hvis der er mere end én MX-post med det samme præferencenummer, skal alle disse prøves, før du går videre til poster med lavere prioritet. En SMTP -klient skal være i stand til at prøve (og prøve igen) hver af de relevante adresser på listen i rækkefølge, indtil et leveringsforsøg lykkes.
Belastningsfordeling
Standardmetoden til distribution af en mængde indgående mail over en række servere er at returnere det samme præferencenummer for hver server i sættet. Når man skal bestemme hvilken server med samme præference at sende mail til, "SKAL afsender-SMTP randomisere dem til at sprede belastningen over flere mailudvekslere for en bestemt organisation", medmindre der er en klar grund til at favorisere en.
En alternativ tilgang er at bruge multihomed -servere, hvor den ene vært returnerer flere IP -adresser. Denne metode lægger byrden på DNS-systemet frem for SMTP-afsenderen for at udføre belastningsbalanceringen, som i dette tilfælde vil præsentere en liste over IP-adresser i en bestemt rækkefølge for klienterne, der spørger til posten A-posten om postveksleren. Da RFC kræver, at SMTP-afsenderen bruger den rækkefølge, der er angivet i A-postforespørgslen, er DNS-serveren fri til omhyggeligt at manipulere sin balancering baseret på enhver metode, herunder round robin DNS , mailserverbelastning eller et ikke-oplyst prioritetsskema.
"Backup" MX
Nogle domæner vil have flere MX -poster, hvoraf den ene er tænkt som en "backup" - med et højere præferencenummer, så det normalt ikke ville blive valgt som mål for levering af e -mails.
I tilfælde af fejl fra værter med lavere nummer (måske på grund af en eller anden form for afbrydelse) vil afsendelse af e -mailservere imidlertid levere til "backup" -værten - queue.example.com i eksemplet herunder:
Domain TTL Class Type Priority Host example.com. 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com. example.com. 1936 IN MX 100 queue.example.com.
Hvis backupserveren har direkte adgang til brugerens postkasser, fortsætter mail der, men ellers vil den sandsynligvis stå i kø på queue.example.com, indtil afbrydelsen er løst.
I mangel af denne form for arrangement, når et domænes mailservere alle er offline, er afsendelsesservere påkrævet at stille meddelelser i kø, der er bestemt til, at domænet skal prøve igen senere. Disse afsenderservere har imidlertid ingen måde at blive underrettet om, at et tidligere offline domænes servere nu er tilgængelige, og derfor griber de til en afstemningsplan - og vil kun opdage, at domænet er tilgængeligt, når de næste forsøg på levering. Forsinkelsen mellem, hvornår et modtagende domænes servere kommer online, og når forsinkede beskeder endelig leveres, kan derfor være alt fra minutter til dage, afhængigt af afsendelsesservers genoptagelsesplan - og det modtagende domæne har ingen synlighed eller kontrol over dette.
Spammere
Spammere kan bevidst sende mail til en af backup (højdistancen) MX-servere på et domæne først under forudsætning af, at en sådan server vil have mindre effektive anti-spamfiltre. En anti-spam-teknik kaldet nolisting er baseret på at antage denne adfærd.
Håndtering af leveringsfejl
SMTP RFC er tvetydig om præcis, hvilke former for leveringsfejl, der skal resultere i genforsøg på levering via fjernere MX-poster (dem med højere præferenceværdier).
Når servere angiver midlertidige fejl, enten ved eksplicit at sende en 4xx -fejl eller ved uventet at afslutte forbindelsen (som skal behandles som en 451 -fejl ifølge afsnit 3.8 i RFC), siger afsnit 4.5.4.1 :
Afsenderen SKAL forsinke genforsøg af en bestemt destination, efter at et forsøg mislykkedes.
Når afsenderen prøver igen, er RFC imidlertid tavs om, hvorvidt dette skal være til den samme server eller en mere "fjern" MX -post. Det står i afsnit 5.1 :
Når opslaget lykkes, kan kortlægningen resultere i en liste over alternative leveringsadresser frem for en enkelt adresse på grund af flere MX -poster, multihoming eller begge dele. For at levere pålidelig mailoverførsel SKAL SMTP -klienten kunne prøve (og prøve igen) hver af de relevante adresser på denne liste i rækkefølge, indtil et leveringsforsøg lykkes.
Nogle servere (f.eks. Sendmail og Postfix 2.1 eller nyere) forsøger den næst længste MX-server efter nogle typer midlertidige leveringsfejl, f.eks. Hilsenfejl. Andre servere (f.eks. Qmail og Postfix 2.0 eller tidligere) vil kun bruge mere fjerne MX-poster, hvis de servere, der er angivet i MX-posterne med den korteste afstand, slet ikke kunne kontaktes. På trods af forskellen er begge adfærd gyldige - da RFC ikke er specifik.
Tilbage til adresseposten
I mangel af en MX -post vil e -mail -afsendere forsøge levering til adresseposten - f.eks. Example.com.
Dette er baseret på RFC 5321 sek. 5.1, hvor der står:
- SMTP -klienter skal slå en MX -post op;
- Hvis ( og kun hvis ) der ikke er nogen MX -post for domænet, skal du behandle domænet som om det havde en MX -post med det givne domæne som målværtsnavn og en præferenceværdi på 0
- Udfør A- eller AAAA -opslag efter behov for at bestemme IP -adressen på målværtsnavnet
Historisk baggrund
RFC 821 blev udgivet i 1982. Den refererer kun til DNS, fordi overgangen fra HOSTS.TXT til DNS endnu ikke var startet. RFC 883, den første beskrivelse af DNS, blev offentliggjort over et år senere i slutningen af 1983. Den beskrev de eksperimentelle og lidt brugte MD- og MF -registreringer. Ifølge RFC 897 og RFC 921 startede overgangen til DNS i 1983, men HOSTS.TXT skulle først udfases i slutningen af 1985 og blev ikke helt udfaset i slutningen af 1990'erne.
I januar 1986 udfasede RFC 973 og RFC 974 MD- og MF -registreringerne, erstattede dem med MX og definerede MX -opslaget med tilbagesendelse til A. RFC 974 anbefaler, at klienter foretager et WKS -opslag på hver MX -vært for at se, om det rent faktisk understøtter SMTP, og kassér MX -posten, hvis ikke. RFC 1123 ændrede dette imidlertid til at sige, at WKS ikke skulle kontrolleres.
Det betyder, at SMTP havde været i brug i mindst et år ved hjælp af HOSTS.TXT, og derefter et par år mere med A, MD og MF, før MX kom med. MD og MF var svære at bruge, så de fleste brugte bare A -posten. Under omstændighederne ville MX uden tilbagekald til A ikke have fungeret på grund af den betydeligt installerede base af mailservere, der bruger A -poster. Den tidlige brug af MX var at identificere gateways til andre netværk, men det blev ikke udbredt før DNS var veletableret i begyndelsen af 1990'erne.
Standarddokumenter
- RFC 1035 (1987), domænenavne - implementering og specifikation
- RFC 1912 (1996), Almindelige DNS -drifts- og konfigurationsfejl
- RFC 5321 (2008), Simple Mail Transfer Protocol
- RFC 7505 (2015), en "Null MX" ingen serviceressourcerekord for domæner, der ikke accepterer nogen mail
Forældede:
- RFC 2821 (2001), Simple Mail Transfer Protocol (forældet af RFC-5321 )
- RFC 974 (1986), Mail Routing og Domain System (forældet af RFC-5321)