La riscrittura di SRS è assolutamente necessaria per un mailserver di inoltro?

Sto gestendo un server di posta Postfix per il mio dominio, diciamo mydomain.com. Funziona principalmente come server di posta elettronica di inoltro: gli utenti ricevono un indirizzo di posta elettronica @ miodominio.com, ma di solito scelgono di inoltrare il proprio indirizzo a una casella di posta esterna (Gmail, Yahoo, ecc.). Ci sono alcune migliaia di indirizzi che vengono inoltrati, quindi il server gestisce un volume abbastanza significativo di traffico di posta.

In passato, il server non utilizzava la riscrittura SRS. Questo ovviamente significava che la posta inoltrata non avrebbe superato i controlli SPF, poiché il mio indirizzo IP non è tecnicamente autorizzato a inviare e-mail per conto del dominio del mittente originale. Tuttavia, da quello che posso vedere non sembra causare problemi significativi. Generalmente nessuna lamentela da parte di utenti come Gmail, Yahoo, ecc. Sembra essere abbastanza intelligente da ignorare gli errori SPF e recapitare comunque i messaggi.

Con questo in mente, è davvero necessario abilitare la riscrittura SRS? Sto pensando di abilitarlo, ma la mia principale preoccupazione è che il mio dominio verrà inserito nella lista nera per l'invio di spam quando lo spam viene inevitabilmente abbandonato. La riscrittura non lo farebbe apparire come se fossi il creatore dello spam? (Almeno, questa è la mia comprensione dalla lettura delle migliori pratiche di Gmail per l'inoltro dei server di posta ).

Certo, sto già prendendo alcune delle precauzioni raccomandate come l'uso di SpamAssassin per aggiungere "SPAM" all'oggetto dello spam sospetto prima di inoltrare, non inoltrare spam ad alta confidenza (punteggio 15+) e utilizzare l'elenco di blocco spamhaus, ma queste misure non sono è perfetto e lo spam può ancora passare senza contrassegni.

Vale la pena abilitare la riscrittura SRS, se aumenta il rischio di essere erroneamente contrassegnato come spammer? O sarebbe più sicuro lasciarlo così com'è e ignorare i fallimenti SPF?

Mi sembra che la tua domanda si riduce a " quanti server di posta là fuori controllano i record SPF sulla posta in arrivo? ". Se è la maggior parte di essi, SRS è un requisito assoluto per un server di inoltro; se non è nessuno di questi, non hai bisogno di SRS.

Sfortunatamente, non posso immediatamente mettere le mani su qualsiasi lavoro accademico su questo. Ma dal momento che controllo SPF sulla posta in arrivo, posso dire con certezza che alcuni server di posta lo controllano. Tutti i tuoi clienti che hanno il tuo server inoltrare agli account sul mio server perderanno le e-mail inviate dai mittenti che pubblicizzano un SPF che termina (come dovrebbero tutti) -all, a meno che tu non usi SRS. Quindi posso affermare con certezza che senza SRS alcune email dei tuoi clienti non verranno recapitate .

Mi scuso con Marc che non so leggere il tedesco, quindi non posso dire se il PDF che cita avanza argomenti convincenti, ma posso ribadire che senza SRS, una parte dell'email dei tuoi clienti non verrà recapitata. Non posso dire quale sia quella frazione, ma non è zero - e dato questo, non penso che tu abbia alternative se non eseguire SRS.

Sono d'accordo che il tuo server non si aiuterà da solo inoltrando SPAM, ma nella mia esperienza la maggior parte del danno reputazionale viene fatto al suo indirizzo IP, non al dominio di inviluppo; questo sarà fatto indipendentemente dall'uso di SRS.

La risposta più profonda alla tua domanda è che, tra SPF e il suo follow-up DMARC (sconsiderato e che rompe Internet), mi sembra che i servizi di inoltro della posta abbiano avuto il loro tempo. Ho già richiesto a tutti tranne uno dei miei utenti di avere la consegna finale sul mio server e che un utente dovrà cambiare o partire nel 2016. Oggi, molti sistemi di webmail consentiranno l'integrazione su più cassette postali raccogliendo posta off-server utilizzando IMAP o POP e molti client di posta consentono a più account IMAP o POP di presentarsi come un unico INBOX integrato, quindi l'inoltro non è il vantaggio della lettura centralizzata di una volta.

In breve, direi che hai bisogno di SRS a breve termine e un nuovo modello di business a lungo termine.

SRS sembra essere una buona idea sulla carta, ma non funziona molto bene in pratica secondo la gente del supporto Heinlein (stanno gestendo un servizio di posta di medie dimensioni con oltre 100000 account.)

I dettagli sono nei loro discorsi, sebbene in tedesco, perché: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Il motivo principale è che SRS è una piccola patch per gravi problemi di implementazione di SPF nella realtà, perché SPF non copre molto bene alcuni casi di uso comune di e-mail. Perché SRS abbia senso, sebbene debba essere distribuito su una grande base di server, è improbabile che accada mai. Quindi fino a quando non viene distribuito su quella grande base di server, non ha molto senso.

Il problema con i grandi fornitori di posta è che al giorno d'oggi hanno una grande base di utenti reale e stanno implementando sempre più tecniche (il successore di DMARC è già in cantiere), il che rende sempre più difficile per un normale configurazione del server di posta per inviare loro messaggi in modo affidabile.

Se vuoi che la tua posta sia consegnata meglio ai grandi fornitori di posta come Gmail, Hotmail e così via, dovresti implementare almeno DKIM e DMARC, ma anche impostarlo su soft fail nella migliore delle ipotesi e forse implementare alcuni meccanismi di limitazione della velocità nella consegna della posta farebbe miracoli per te.

Questo problema con i grandi fornitori è il motivo per cui oggi ci sono servizi come Mailchimp, Mandrill o Returnpath. Tali fornitori pagano soldi a Google & Co. per una migliore qualità di consegna.

Sono d'accordo con ogni parola di @MadHatter, MA fatto importante su Google!

Se fornisci un servizio di inoltro a Gmail, ci sono buone probabilità che tu fornisca anche l'accesso SMTP in modo che gli utenti di Gmail possano inviare e-mail da Gmail per conto dell'indirizzo da te memorizzato.

In tal caso, gmail sa che sei uno spedizioniere per questa e-mail e non contrassegna i tuoi forward come spam anche se fallisce il controllo SPF.

Puoi inviare mail ai tuoi clienti da bill@microsoft.com. Il messaggio arriverà nella loro casella di posta senza alcun preavviso! (Microsoft ha -all nel record spf)

Controllato e verificato Esempio allegato.

questo messaggio è andato alla posta in arrivo.