Namnet efter EHLO är en klientlevererad SMTP identitet, inte ett bevis på att klienten äger en domän eller är behörig att skicka det synliga meddelandet. EHLO ber också servern att annonsera tillägg. En användbar undersökning separerar det hälsningsnamnet, den anslutande IP-adressen, den kuvertsändare och meddelandet är synligt från domänen. Att förväxla dem kan ge både falska larm och ineffektiva korrigeringar.
Tolka hälsningen
RFC 5321 beskriver klienthälsningen och domän- eller adressbokstavarna som används för att identifiera klienten. EHLO begär utökat SMTP beteende; HELO är den grundläggande hälsningen. En servers EHLO svar kan annonsera tillägg som stöds, men support och behörighet är olika. Till exempel, att annonsera för en funktion betyder inte att en oautentiserad klient kan vidarebefordra e-post till varje mottagare.
Klienten bör tillhandahålla lämpligt fullt kvalificerat domännamn när det är tillgängligt, med en bokstavlig adress som används under de omständigheter som definieras av protokollet. En generisk arbetsstationsetikett eller en icke-relaterad domän kan orsaka interoperabilitet eller policyproblem. Granska den faktiska serverns krav snarare än att anta att varje distribution genomför samma kontroller. RFC 5321 avsnitt 4.1.1.1 och 4.1.4.
Skilj konsistenskontroller från autentisering
En operatör kan jämföra hälsningen med framåt eller omvänd DNS, men en sådan jämförelse är en separat signal och måste följa protokoll och lokala policybegränsningar. RFC 5321 säger att en server kan verifiera om EHLO -namnet motsvarar klientens IP, men får inte vägra ett meddelande enbart för att verifieringen misslyckas. Förvandla inte en vanlig antimissbruksheuristik till ett universellt SMTP krav.
SPF kan utvärdera en HELO identitet som beskrivs av RFC 7208. Det resultatet är inte utbytbart med utvärdering av en icke-tom MAIL FROM-identitet. För en noll omvänd sökväg använder SPF proceduren en konstruerad identitet baserad på HELO . Bevara vilken identitet som kontrollerades istället för att visa ett omärkt SPF resultat.
Läs ett hypotetiskt hälsningsutbyte
Anta att en server skickar 220, klienten skickar EHLO client.example och servern svarar med 250 fortsättningsrader följt av en sista 250 rad som annonserar sina tillgängliga tillägg. Detta illustrerar hälsning och kapacitetsupptäckt, inte bevis på DNS upplösning, klientägande eller tillstånd att vidarebefordra.
Anta nu att RCPT TO senare returnerar ett relä-nekat svar. Den lyckade hälsningen gav inte det tillståndet. Registrera avslaget vid RCPT, tillsammans med den faktiska anslutningen och kontotillståndet, istället för att dra slutsatsen att EHLO autentiseringen misslyckades. Omvänt behöver ett avslag till EHLO själv sin egen fullständiga förklaring. Dessa är uppfunna protokollfall, inte ett behållet labb eller test från kommersiella leverantörer.
Felsök det exakta avslaget
Bevara det fullständiga svaret på hälsningsstadiet och eventuella senare avslag. Ett EHLO fel kan kräva kontroll av syntax, implementeringskompatibilitet eller den förväntade tjänstens slutpunkt. Ett fel hos RCPT kan istället handla om relätillstånd eller mottagarens existens. Ett fel efter DATA kan involvera innehåll eller meddelandepolicy. Byt inte namn på klientvärden till den synliga From-domänen bara för att det slutliga meddelandet misslyckades DMARC.
Efter framgångsrikt STARTTLS, kassera pre-TLS SMTP informationen och skicka en ny EHLO som rekommenderas av RFC 3207 avsnitt 4.2; kapacitetslistan kan ändras. Om autentisering krävs för inlämning, följ leverantörens säkra metod som stöds. Testa den korrigerade konfigurationen med ofarligt innehåll och registrera det slutliga svaret i varje steg. Den användbara slutsatsen är vilken operation som misslyckades och varför, inte om ett värdnamn såg rimligt ut.
Välj nästa kontroll från svaret
- EHLO -syntax eller avvisning av hälsning: kontrollera den exakta slutpunkten, det angivna namnet och det fullständiga svaret.
- AUTH-fel efter TLS : kontrollera den leverantörsstödda säkra metoden och aktuella behörigheter utan att avslöja hemligheter.
- RCPT-avslag: särskilj mottagarens existens från reläbehörighet genom att använda hela svaret.
- Post-DATA avvisning: inspektera meddelandepolicyförklaringen och betrodda autentiseringsbevis.
- DMARC -klagomål: jämför den faktiska SPF / DKIM identiteten med From; bara att byta namn på EHLO är inte en allmän inriktning reparera.