Onorare Resent-* nel destinatario dell'email

Funzionalità
1

Abbiamo un flusso di lavoro in cui utilizziamo Discourse come archivio e-mail. Abbiamo un indirizzo e-mail di gruppo e i nostri agenti aggiungono quell’indirizzo in Cc quando iniziano una discussione via e-mail con un cliente.

Questo funziona benissimo finché un cliente non risponde specificamente all’agente, ignorando tutti gli header Cc e persino Reply-To. L’agente dovrebbe quindi inoltrare l’e-mail (re-inviare) all’indirizzo e-mail di gruppo. L’inoltro è il metodo preferito qui, in modo che Discourse archivi l’e-mail originale includendo tutti gli header originali, timestamp, ecc.

L’inoltro di un’e-mail viene eseguito copiando il messaggio esatto e aggiungendo gli header Resent-From e Resent-To. Questi vengono purtroppo ignorati da Email::Receiver. Dovrebbe semplicemente aggiungere tutti i Resent-* ai rispettivi campi regolari.

Ho iniziato a implementare questo, e sono arrivato a far sì che create_incoming_email tenga conto dei campi. Ho quindi potuto vedere le e-mail, inclusi i destinatari presi da Resent-To, nell’elenco delle e-mail in arrivo in Discourse.

Tuttavia, ciò che non riesco a fare è far sì che get_all_recipients rispetti anche i campi Resent-*. Ho aggiunto resent-to resent-cc resent-bcc all’array %i() dei campi e-mail, ma sembra ancora non restituire i destinatari da questi campi.

Qualsiasi aiuto è benvenuto, in modo che io possa creare una PR per questa modifica!

2

Sembra una funzionalità piuttosto pericolosa e incline all’impersonificazione. Come proponi che il resender venga autenticato?

Inoltre, Discourse ha già un’elaborazione esistente per le email inoltrate.

3

Questa sembra una funzionalità piuttosto pericolosa e incline all’impersonificazione. Come proponi che il resender venga autenticato?

Con l’header Resent-From. Ma in realtà non ha importanza; la parte interessante è se il mittente originale può essere autenticato, non il resender.

Inoltre, Discourse ha già un’elaborazione esistente per le email inoltrate.

Solo per gli inoltri citati. Questo presenta diversi problemi:

  • Non archivia l’email originale, solo una copia citata del suo corpo
  • Non c’è supporto per messaggi inoltrati come allegato (con header completi)
  • È incompleto (si basa su un prefisso speciale nell’Oggetto per riconoscere un’email inoltrata)
4

E come succede esattamente? E se chi lo rinvia mente e fabbrica completamente un’email che si suppone sia stata inviata solo a loro?

5

E come succede esattamente? E se il reinviante mente e fabbrica completamente un’email che sarebbe stata inviata solo a lui?

Potrebbe anche omettere tutta la roba Resent- e falsificarla fin dall’inizio, senza affermare che gli è stata inviata per prima.

Penso che tu abbia un’idea sbagliata di cosa fanno le intestazioni Resent- - che infatti non fanno assolutamente nulla. Non vengono prese in considerazione nemmeno quando i server di posta controllano SPF o DKIM, quindi falsificare un’email reinviata è difficile quanto falsificare l’email originale.

Nel mio caso, un’email reinviata da uno sconosciuto esterno verrebbe bloccata dal filtro antispam per violazione SPF. Il motivo per cui il mio scenario con gli agenti che reinviano email a Discourse funziona è che sono esentati da tali controlli dopo essersi autenticati al nostro server di posta.

Consentire a Discourse di utilizzare l’intestazione Resent-To è quindi poco più di una funzionalità di convenienza, perché è così che i normali client di posta creano una copia contraffatta di un’email che hanno ricevuto in precedenza. Non cambia nulla sull’autenticazione.

1 Mi Piace