Quali precauzioni dovrei prendere prima di consentire agli utenti di inviare e-mail tramite la mia app?

2

Sto lavorando a un'applicazione di gestione dei contatti / leggera CRM e vorrei poter consentire ai miei utenti di inviare e-mail ai propri contatti attraverso la mia applicazione. Ovviamente questo apre una grande quantità di worm in termini di sicurezza, quindi mi piacerebbe sapere cosa si può fare per mitigare o minimizzare il rischio sia per la mia organizzazione che per gli utenti autentici (non spamming), oltre a mantenere la mia app stimabile.

L'applicazione stessa renderà le richieste API a un provider SMTP di massa di terze parti e consentirà loro di eseguire l'invio effettivo, anziché inviarlo direttamente dai nostri server.

Queste sono alcune delle precauzioni attuali che sto prendendo:

  • Gli utenti potranno inviare e-mail solo ai propri contatti o account già presenti nel sistema, non solo elenchi di indirizzi email di massa di indirizzi.
  • Le e-mail sono a tariffa limitata, ogni utente sarà in grado di inviare e-mail n in un periodo di 24 ore in cui n si basa sul proprio piano di abbonamento.
  • Utilizzo della funzione "per conto di" per l'indirizzo del mittente.

Quello che vorrei sapere in particolare è:

  • Alcuni utenti potrebbero voler inviare da una mancata risposta o da un altro indirizzo aziendale, diverso dall'e-mail che usano per accedere. Come dovrei verificare meglio gli utenti o avere accesso all'indirizzo? Non posso sempre utilizzare le email di verifica perché, se vogliono inviare da un indirizzo non monitorato, ovviamente non potranno controllare la suddetta email di verifica.
  • Qualcuno è in grado di spiegare come utilizzare i record SPF (o far utilizzare i miei utenti) in questa istanza? Ho letto di loro ma la mia conoscenza è ancora traballante in questo settore.
  • Ci saranno precauzioni speciali da adottare se ridimensioniamo l'app su più server?

Come nota aggiuntiva, come il leader del mercato Salesforce, intendo consentire ai miei utenti di inviare un numero illimitato di e-mail singole (non voluminose) ad altri utenti, ma soprattutto sto parlando in particolare delle e-mail inviate a non-utenti .

    
posta Leylandski 23.08.2016 - 11:47
fonte

2 risposte

0

Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.

  • Primo passo ovvio, email a limite di velocità per utente.

  • Limita le nuove iscrizioni. Nel tuo caso sembra che gli utenti debbano pagare per l'accesso, quindi è un limite di velocità efficace. Questo è importante se si inviano e-mail a limite di velocità per utente. Ovviamente non vuoi che una singola persona lo elimini creando facilmente un ampio pool di utenti.

The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

  • I ricevitori di posta spesso tengono traccia della reputazione del mittente per indirizzo IP. Dato che stai utilizzando un provider di terze parti per inviare le email, allora è il loro IP a prendere il colpo di reputazione non il tuo. Questo è importante, dal momento che non vuoi che il tuo server email aziendale di rilievo sia sullo stesso IP che invia email meno controllate.

  • Potrebbe essere meglio limitare le e-mail inviate in modo da non essere riconosciuti come attaccanti DoS da parte di diversi ricevitori di posta, ma il tuo provider potrebbe farlo automaticamente.

Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.

  • Se non puoi verificare di essere il proprietario dell'indirizzo email, devi invece verificare che siano proprietari del dominio. Questo è un buon argomento per una domanda separata, ma in breve, ti suggerisco di esaminare in che modo i provider di certificati SSL verificano la proprietà.

    • Verifica email per set limitato di nomi utente dell'account amministratore noti. ( [email protected] , ecc.)

      In alternativa, controlla WHOIS e invia la tua verifica via email al contatto dell'amministratore lì.

    • Verifica DNS richiedendo loro di aggiungere una regola TXT casuale specifica.

    • È possibile utilizzare la verifica della pagina Web in formato HTML, ma ciò potrebbe potenzialmente essere disconnesso da ciò che è realmente necessario verificare.

Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.

  • I record SPF sono gestiti dal titolare del dominio From.

    • Se stai inviando dal tuo dominio, con una risposta del dominio del cliente, SPF è semplice da configurare, ma dovrebbe essere una domanda separata.
    • Se si sta inviando dal dominio del cliente, è responsabilità del cliente elencare gli IP del server di invio, in modo che non aggiungano accidentalmente punti di spam a tali e-mail.

      • Per comodità del cliente, dovresti pubblicare probabilmente una regola SPF, in modo che il tuo cliente possa include . In questo modo, se apporti modifiche, ad esempio il cambio di provider SMTP, i tuoi clienti non dovranno aggiornare il loro set di regole SPF.

        • La regola SPF che pubblichi può essere un semplice include di ciò che il tuo provider SMTP ha pubblicato sul loro fine.

Will there be any special precautions to take if we scale the app over multiple servers?

Come ho detto sopra, i ricevitori tengono traccia della reputazione per IP. (nel tuo caso, il provider SMTP) Vorrei sottolineare che i tuoi server dovrebbero essere sincronizzati in modo tale che venga applicata la limitazione della velocità. Non si desidera che l'utente che si connette a un server diverso sia in grado di ignorare un errore di limite di velocità.

As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

  • Potresti prendere in considerazione l'invio di questi da un altro IP (se il tuo provider SMTP ti assegna gli IP) in modo da ottenere una reputazione di posta separata dalle e-mail di massa.

  • Dovresti sempre avere un limite di velocità, anche se non pubblicizzato, per impedire l'invio di script o script per gli utenti.

Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.

Questo è utile dal punto di vista dell'utente, ma presumo che tecnicamente possano aggiungere contatti al proprio sistema utilizzando uno script utente, quindi questo probabilmente non è rilevante per lo spammer determinato?

Using the "on behalf of" feature for the sender address.

Non sono sicuro al 100% di come lo stai facendo, ma sembra una cosa ragionevole da fare.

    
risposta data 23.08.2016 - 16:55
fonte
0

Che cosa è stato detto in questa risposta , oltre alla convalida dell'input e alla SANITIZZAZIONE

Assicurati che tutti i caratteri speciali e i byte, specialmente; : "" \% < > e 0x00 Sono rappresentati da qualche forma codificata dell'originale prima che vengano memorizzati e trasferiti. Poi traducili indietro quando mostri il messaggio.

    
risposta data 23.08.2016 - 17:24
fonte

Leggi altre domande sui tag