Devo utilizzare lo spoofing di Legittime Email?

Fintanto che è su richiesta dell'utente, non c'è nulla di discutibile nel farlo. È proprio come il tuo sistema è il client di posta elettronica. L'invio di e-mail da un indirizzo senza l'approvazione del proprietario dell'indirizzo è una storia diversa, ovviamente.

Da un punto di vista di etica , propongo che la domanda possa essere ridotta a un semplice test:

If the recipient of the email presented a copy of the email to your user, would the user be surprised at either the contents of the email or that an email had been sent on their behalf?

Anche se potresti non fare nulla di sbagliato di per sé, se la risposta a qualsiasi parte della domanda è "sì, l'utente sarebbe sorpreso," potresti non essere all'altezza del comportamento etico.

Dal punto di vista della consegna delle email , utilizzando un dall'indirizzo con un dominio che non controlli, ha implicazioni su una serie di standard potenzialmente in grado di impedire la consegna della tua email: DKIM, Sender ID e SPF. Mi rivolgerò a ciascuno separatamente.

SPF

L'indirizzo Da non ha in effetti alcun rapporto diretto con il passaggio del controllo SPF. La maggior parte degli MTA e delle API framework, tuttavia, utilizza l'indirizzo Da per determinare il Sender busta SMTP o " MAIL FROM "indirizzo. L'Envelope Sender è ciò che viene effettivamente utilizzato per il controllo SPF. Di conseguenza, per far passare SPF, tu è necessario sostituire l'Envelope Sender per contenere il tuo indirizzo email (in un dominio che controlli e pubblicare il record SPF corretto per).

Ad esempio, sendmail (1) offre l'opzione "-f" per sovrascrivere l'Envelope Sender. Le istruzioni specifiche per realizzare questo con tecnologie diverse sono (credo) oltre lo scopo di questo sito; potresti provare a chiedere su Stack Overflow o Server Fault (a seconda dell'approccio utilizzato).

Inoltre, l'indirizzo del mittente busta viene utilizzato dal MTA ricevente per determinare l'indirizzo Return-Path . L'indirizzo Return-Path è dove vengono inviati tutti i messaggi di rimbalzo, che è un'altra ragione per cui è importante sovrascrivere l'Envelope Sender in modo che i messaggi di rimbalzo vengano indirizzati a te e non al tuo utente.

ID mittente

Ci sono due meccanismi separati offerti dall'ID mittente: spf2.0 / mfrom e spf2.0 / pra. Il primo ha le stesse funzioni del controllo SPF e condivide le stesse implicazioni.

Quest'ultimo non guarda l'Envelope Sender, ma guarda l' Indirizzo responsabile presunto (PRA). Perché ciò avvenga, tutto ciò che devi fare è specificare un indirizzo mittente nell'intestazione che contiene il tuo indirizzo email (in un dominio che controlli e pubblica il record dell'ID mittente corretto per).

La specifica di un indirizzo mittente può anche rendere più chiaro al destinatario che l'email è stata inviata da te per conto di l'utente (ovviamente, tutto dipende dal client di posta / MUA che il destinatario utilizza).

DKIM / DKIM-ADSP / Tasti di dominio

Non c'è nulla che ti impedisca di allegare una firma DKIM o Domain Keys perfettamente valida al messaggio di posta elettronica, tuttavia, devi impostare il parametro "d=" sul tuo dominio, non il dominio di indirizzo From. Non mi è chiaro se questa sia o meno una buona idea, dal momento che gli standard lasciano completamente aperto se il dominio "d=" dovrebbe o non dovrebbe corrispondere all'indirizzo Da, l'indirizzo del mittente, il mittente della busta o qualsiasi altra cosa ; e non ho una conoscenza specifica di come le persone filtrano nella pratica.

Lo standard DKIM-ADSP, d'altra parte, rende abbastanza chiaro che il dominio "d=" è da confrontare esclusivamente con il dominio degli indirizzi di provenienza . I domini che pubblicano la politica di ADSP, dkim=discardable , (ad es. Paypal.com), impediranno di inviare per conto degli utenti su quel dominio, almeno quando il server di posta del destinatario è configurato per filtrare secondo il criterio di ADSP. / p>

Considerazioni finali

Molti altri problemi di recapitabilità della posta elettronica, come iprev / FCrDNS, assegni HELO / EHLO, ecc. sono neutri rispetto all'indirizzo Da, quindi si applica il consiglio standard. Se il nuovo standard DMARC ottiene sempre la trazione, potrebbe presentare problemi altrettanto severi di quelli di DKIM-ADSP, a causa del identificatori allineati requisito.

Oltre alle limitazioni che ho specificato, in teoria non ha alcun problema a modificare l'indirizzo Da, a patto che tu segua tutti i miei consigli sopra. In pratica , naturalmente, ci saranno sempre problemi, perché l'e-mail è un po 'come il selvaggio west in cui ognuno è libero di implementare gli standard in base alle proprie interpretazioni personali.

Outlook sa quando ho inviato la posta da GMail usando un indirizzo diverso da quello del mio account GMail. Li mostra come Da per conto di. Outlook può saperlo solo se GMail invia più intestazioni del solo "Da". E infatti lo fa. Nelle intestazioni di un'e-mail che ho inviato in questo modo, posso vedere:

Return-Path: GMail account
Sender: GMail account
From: Marjan Venema <other account>

Non so JavaMail quindi non posso dirti come, ma potresti fare lo stesso in modo che tutta la posta inviata dal sistema venga visualizzata in Outlook (e probabilmente nella maggior parte degli altri client di posta elettronica) come Da X per conto di Y.

Ed ecco qualcosa che può venire in aiuto:

From: "YOUR CLIENTS NAME" <[email protected]>
Sender: [email protected]
To: destination.com
Date: 13 Jul 2009 15:39:42 -0400
Subject: Whatever subject you need
Return-Path: [email protected]

Questi campi sono validi e consentiranno al server ricevente di identificarti come server. In più, le e-mail inviate ti verranno restituite.