Puncte:0

Pot opri un SPF SOFTFAIL în Gmail când trimit către și de la adrese care au un alias de e-mail?

drapel in

Am un domeniu vanity (mydomain.com) găzduit de Gandi și configurat cu aliasuri de e-mail pentru familia mea care indică adresele noastre Gmail respective:

și așa mai departe.

Gmail este configurat să trimită e-mail ca adresă vanitară și am, de asemenea, configurată o înregistrare SPF:

v=spf1 include:_spf.google.com include:_spf.gpaas.net include:_mailcust.gandi.net ?toate

Deși mail-tester.com raportează că SPF-ul este configurat corect, este posibil să obțineți un SOFTFAIL atunci când trimiteți un e-mail de la [oricine]@domeniul meu.com la [oricine altcineva]@domeniul meu.com:

Antetele atunci când e-mailurile SOFTFAIL sunt după cum urmează:

Livrat-către: [email protected]
ARC-Autentificare-Rezultate: i=1; mx.google.com;
       spf=softfail (google.com: domeniul de tranziție [email protected] nu desemnează 2001:4b98:dc4:8::230 ca expeditor permis) [email protected]
Cale de întoarcere: <[email protected]>
Primit: de la relay10.mail.gandi.net (relay10.mail.gandi.net. [2001:4b98:dc4:8::230])
        de mx.google.com cu ID-ul ESMTPS w4-20020a05600018c400b0020ac7a84cb7si9021160wrq.441.2022.05.01.02.22.05
        pentru <[email protected]>
        (versiunea=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 biți=256/256);
        Duminică, 01 mai 2022 02:22:06 -0700 (PDT)
SPF primit: softfail (google.com: domeniul de tranziție [email protected] nu desemnează 2001:4b98:dc4:8::230 ca expeditor permis) client-ip=2001:4b98:dc4:8::230;
Autentificare-Rezultate: mx.google.com;
       spf=softfail (google.com: domeniul de tranziție [email protected] nu desemnează 2001:4b98:dc4:8::230 ca expeditor permis) [email protected]
Primit: de la spool.mail.gandi.net (spool3.mail.gandi.net [217.70.178.212]) de relay.mail.gandi.net (Postfix) cu ID-ul ESMTPS 51151240003 pentru <[email protected]>; Soare,
  1 mai 2022 09:22:05 +0000 (UTC)
X-Envelope-To: [email protected]
Primit: de la mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) de spool.mail.gandi.net (Postfix) cu ID-ul ESMTPS 49A2CAC0C45 pentru <[email protected] >; Soare,
  1 mai 2022 09:22:04 +0000 (UTC)
Primit: prin mail-lf1-f48.google.com cu ID SMTP w19so20836346lfu.11
        pentru <[email protected]>; Duminică, 01 mai 2022 02:22:04 -0700 (PDT)
Primit: de la smtpclient.apple (cpc1-sotn14-2-0-cust79.15-1.cable.virginm.net. [81.96.148.80])
        de smtp.gmail.com cu ID-ul ESMTPSA r7-20020a2e8e27000000b0024f3d1dae9asm761964ljk.34.2022.05.01.02.22.02
        pentru <[email protected]>
        (versiunea=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 biți=128/128);
        Duminică, 01 mai 2022 02:22:02 -0700 (PDT)
De la: Eu <[email protected]>
Către: Fratele meu <[email protected]>
SPF primit: trece (spool3: domeniul gmail.com desemnează 209.85.167.48 ca expeditor permis) client-ip=209.85.167.48; [email protected]; helo=mail-lf1-f48.google.com;
Autentificare-Rezultate: spool.mail.gandi.net; dkim=niciuna; dmarc=niciuna; spf=pass (spool.mail.gandi.net: domeniul [email protected] desemnează 209.85.167.48 ca expeditor permis) [email protected]

Există vreo modalitate prin care pot opri e-mailurile trimise de la mydomain.com la o altă adresă la mydomain.com care nu au SPF?

Puncte:1
drapel ng

Puteți vedea că e-mailul a fost primit de la un server Gandi:

Primit: de la relay10.mail.gandi.net (relay10.mail.gandi.net. [2001:4b98:dc4:8::230])

Puteți vedea că serverele Gandi nu sunt autorizate în înregistrarea SPF:

SPF primit: softfail (google.com: domeniul de tranziție [email protected] nu desemnează 2001:4b98:dc4:8::230 ca expeditor permis)

SPF verifică față de calea de intoarcere antet. Nu mailfrom antet. The calea de intoarcere este [email protected]. Prin urmare, înregistrările SPF gmail.com nu permit serverelor Gandi să trimită e-mail folosind a calea de intoarcere cu adrese de e-mail gmail.com.

SPF funcționează normal. Ceea ce vedeți este o slăbiciune inerentă a protocolului SPF în ceea ce privește redirecționarea e-mailurilor. Când corespondența este redirecționată la nivel MTA (server de e-mail), mailfrom și calea de intoarcere anteturile nu sunt rescrise (și nici nu ar trebui să fie), dar atunci când e-mailul redirecționat ajunge la serverul de e-mail al destinatarului, acesta provine de la serverul de redirecționare, și nu de la serverul de e-mail original al expeditorului. Prin urmare, serverul de e-mail al destinatarului verifică SPF și vede că calea de intoarcere domeniul nu autorizează serverul de e-mail de redirecționare să trimită e-mail.

Redirecționarea întrerupe SPF. Pentru că nu controlați înregistrările SPF pentru gmail.com domeniu, nu puteți autoriza serverele Gandi să trimită e-mailuri în numele lui Gmail.Acesta este motivul pentru care SPF nu poate fi folosit, singur, pentru a determina dacă poșta este autorizată sau nu.

Aveți patru soluții (opțiunile 1 și 2 necesită un cont Google Workspace plătit, cred):

  1. Asigurați-vă că, atunci când trimiteți e-mail de la Gmail utilizând o adresă de e-mail alias, acesta folosește și aliasul de e-mail în calea de intoarcere antet. De asemenea, adăugați serverele gmail la înregistrarea SPF pentru mydomain.com. Pentru mai multe informații despre trimiterea de e-mailuri ca alias cu Gmail, consultați aici: https://support.google.com/mail/answer/22370?hl=ro
  2. Configurați-vă înregistrările MX și Gmail astfel încât e-mailurile destinate aliasului dvs. să fie trimise direct către serverele Gmail și în căsuța dvs. de e-mail, în loc să le redirecționați printr-o terță parte.
  3. Primiți e-mailuri destinate adresei dvs. de e-mail alias la terț, în loc să redirecționați mesajul. Apoi configurați Gmail pentru a colecta acel e-mail de la terț folosind Import e-mailuri din celălalt cont al meu (POP3) opțiune în gmail.
  4. Dacă aveți control asupra comportamentului serverului de e-mail de redirecționare, puteți crea o regulă care rescrie calea de intoarcere antet pentru a se potrivi cu mailfrom antet atunci când redirecționează e-mailurile primite de la și destinate unuia dintre aliasurile dvs. de e-mail.
Richard avatar
drapel in
Multumesc pentru asta. Mi-am dat seama că antetul pe care l-am inclus a fost de fapt atunci când fratele meu mi-a trimis un e-mail, sper că asta nu a provocat nicio confuzie. În ceea ce privește configurarea e-mailurilor, e-mailurile sunt trimise folosind funcția „trimitere ca altă adresă” din Gmail, dar pentru serverul smtp ofer detaliile proprii ale serverului smtp gmail cu numele de utilizator și parola Gmail. Acest lucru elimină „în numele lui” de pe toate e-mailurile, rămânând doar adresa mea personală.
Appleoddity avatar
drapel ng
@Richard, desigur, a provocat confuzie. Vă rugăm să vă actualizați postarea cu informații corecte.
Richard avatar
drapel in
Am actualizat anteturile, deși nu sunt sigur dacă este vreun ajutor suplimentar, deoarece problema este aceeași, indiferent dacă trimit e-mailul fratelui meu sau invers. Am observat că SPF-ul pentru `mydomain.com` nu pare a fi verificat deloc - făcându-mă să mă întreb dacă înregistrarea mea SPF face de fapt ceva.
Appleoddity avatar
drapel ng
@Richard ok. Mi-am actualizat răspunsul.
Richard avatar
drapel in
Multumesc pentru asta. Trimit e-mailuri prin Gmail și serverul SMTP Gmail (folosind metoda din linkul pe care l-ați furnizat) și sosesc e-mailuri cu „de la” ca me@domeniul meu.com. Nu pot schimba „calea de întoarcere”, deoarece Gmail forțează ca aceasta să fie [email protected] - o limitare a neplatei pentru GSuite.
Appleoddity avatar
drapel ng
Vad asta. @Richard Mi-am actualizat din nou postarea pentru a clarifica problema și a oferi soluții.
Richard avatar
drapel in
Mulțumesc, are sens. Cred că ar putea exista o a 5-a opțiune care ar fi utilizarea unui server SMTP alternativ la Gmail (de exemplu, Mailgun, SendGrid sau Mailjet) pentru a trimite e-mailurile. Acest lucru ar seta apoi `return-path` ca [email protected] și verificările SPF ar fi trecute.
Appleoddity avatar
drapel ng
@Richard bună întrebare. Cred că Gmail poate dicta în continuare antetul return-path chiar dacă folosește un smtp terță parte. Totuși, merită încercat.
Puncte:0
drapel cn

Problema este că numai SPF nu a fost considerat suficient pentru a opri e-mailurile care nu se autentifică. Chiar și eșecul greu nu ar face asta.

Asta a motivat dezvoltarea DMARC. Cu aceasta, puteți instrui serverele de primire (inclusiv cele trimise de la intern la intern) să respingă e-mailul care nu trece autentificarea.

Puteți citi mai multe despre hardfail vs softfail și de ce DMARC este răspunsul aici: https://knowledge.ondmarc.redsift.com/en/articles/1148885-spf-hard-fail-vs-spf-soft-fail

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.