DigitalOcean blocca SMTP e costringe l'uso di SendGrid

[MachineScholar]

Non sono sicuro esattamente dove postare questo, ma mi chiedo se qualcun altro stia riscontrando questo problema. Ho seguito la guida ufficiale all’installazione utilizzando DigitalOcean e Mailgun. Ma recentemente ho notato che ho molte eccezioni di lavoro Jobs::UserEmail e non riesco a inviare email di prova.

Log degli errori

Message (20584 copie segnalate)

Job exception: execution expired

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `open'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `tcp_socket'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:672:in `block in do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:671:in `do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:642:in `start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in <class:Config>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'

Non sono riuscito a capire cosa abbia causato il problema, perché nessuna impostazione è stata modificata, la mia istanza è aggiornata e il mio account Mailgun è ben al di sotto dell’utilizzo del piano gratuito. Pertanto, ho creato un ticket di supporto con DigitalOcean perché pensavo che potessero aver bloccato la porta 587, e ho ricevuto una breve risposta dicendo che hanno imposto restrizioni sul traffico SMTP e che raccomandano di utilizzare il loro partner SendGrid.

Email di DigitalOcean

Comprendiamo che hai preoccupazioni riguardo alle restrizioni SMTP in vigore sul tuo account. DigitalOcean non è un host di posta elettronica dedicato e la lotta contro lo spam è una battaglia costante. Per questo motivo, sono state imposte restrizioni su tutti gli account.

Vorremmo anche fornire un ulteriore background su questo problema. Poiché gli indirizzi IP negli ambienti cloud vengono utilizzati e restituiti ai pool disponibili molto frequentemente, sono considerati dinamici e inaffidabili. Ad esempio, ti viene attualmente assegnato un indirizzo IP e sei un utente di posta elettronica responsabile. Segui tutte le best practice per la posta elettronica e non invii mai spam o posta indesiderata. Successivamente, quando non avrai più bisogno di quel Droplet, lo distruggerai e l’indirizzo IP sarà libero di essere assegnato a un altro utente DigitalOcean. Quell’utente coglie l’occasione per inviare un grande volume di spam prima che il nostro team di sicurezza intervenga sull’account in violazione.

I provider di posta elettronica come Gmail, Microsoft e altri non possono determinare se l’e-mail proveniente da un IP sia legittima o meno finché non acquisisce una cattiva reputazione. A quel punto, il danno è già stato fatto. È più sicuro bloccare tutta la posta proveniente da piattaforme, come i provider di servizi Internet e gli ambienti di hosting cloud, in cui gli indirizzi IP vengono assegnati dinamicamente e sono intrinsecamente rischiosi.

Sebbene ciò riduca le vie che gli spammer hanno a disposizione, influisce anche sugli utenti legittimi. Il nostro team di operazioni di abuso sta lavorando con le SBL per far rimuovere gli IP dalle blacklist. A causa di ciò, stiamo limitando il traffico SMTP su tutta la piattaforma DigitalOcean. Ciò significa che non siamo in grado di rimuovere la restrizione SMTP applicata al tuo account.

Comprendiamo che il tuo flusso di lavoro potrebbe avere esigenze di posta elettronica. Come soluzione a questa restrizione, abbiamo collaborato con SendGrid per offrire a tutti i nostri clienti una soluzione migliore in cui non dovrai preoccuparti della reputazione degli IP e del blocco. Puoi leggere di più in nostro articolo qui. Tramite SendGrid, sarai in grado di inviare 100 email gratuite al giorno e se il tuo requisito va oltre il piano gratuito, non esitare a contattare il supporto SendGrid per optare per un piano migliore per soddisfare le tue esigenze.

Siamo sempre felici di aiutarti se hai ulteriori domande, quindi non esitare a contattarci.

----

Questa è una risposta automatica per accelerare il servizio fornendo tutte le informazioni necessarie per aiutarti. Devi rispondere a questa email per ulteriore assistenza.

Team di supporto DigitalOcean

Qualcun altro ha riscontrato questo problema casuale? Certamente non voglio essere costretto a passare a SendGrid senza un buon motivo.

Modifica…
Ho appena notato questo argomento Looks like DO is disabling Smtp in their Discourse hosting plans quindi sembra che chiunque utilizzi DigitalOcean potrebbe essere fregato.

[Don]

Ciao

Non sono sicuro se sei sul server UE, ma Mailgun ha alcuni problemi di connessione ora, quindi le e-mail non possono essere inviate. Ho anche molti errori in /logs.

Vedi: https://status.mailgun.com/

[MachineScholar]

Grazie! Sono sul server EU, tuttavia questo problema persiste da diversi giorni purtroppo, quindi non è colpa di Mailgun. E ho un’altra istanza che non ha utenti e anche questa è configurata con il server EU di Mailgun, e quell’istanza invia email di test senza errori. Quindi ho concluso che questo problema non può essere colpa di Mailgun.

[pequiste]

DigitalOcean non è l’unica opzione. Potresti considerare di passare a un provider europeo per il tuo VPS.

Ho fatto lo stesso per la piattaforma di email transazionali e sta andando alla grande.

So che Digital Ocean è la scelta predefinita per l’installazione di Discourse, ma la loro offerta VPS non ha nulla di speciale. Se non funzionano più, non funzionano più.

[MachineScholar]

Ottimo consiglio, e grazie. Tuttavia, le offerte di DO si integrano molto bene con altre cose che sto costruendo e cercando di connettere senza problemi, quindi sarebbe meraviglioso se non facessero mosse così losche. Quasi ogni server Ubuntu potrebbe — in teoria — funzionare bene, quindi il tuo punto è del tutto valido.

[MachineScholar]

AGGIORNAMENTO! Devi semplicemente aprire un ticket di assistenza e lamentarti abbastanza da farli sbloccare le porte. Posso confermare che ora le email di test vengono inviate e tutto sembra funzionare.

[dettagli=“Email di supporto clienti DO”]

Ciao,

Stiamo facendo seguito con un aggiornamento.

Il nostro team di sicurezza ha sbloccato le porte SMTP sul tuo account.

Dovresti ora essere in grado di configurarle, ma se riscontri difficoltà, faccelo sapere così possiamo indagare ulteriormente!

Siamo sempre felici di aiutare se hai altre domande, quindi non esitare a farcelo sapere.

[/details]

[Linus_pi (Linus)]

Ci sono aggiornamenti su questo argomento? Ho ricevuto la stessa risposta due volte dicendo che non la sbloccheranno a causa delle loro policy. Ma il provider di posta elettronica che sto usando non può aprire la porta 2525. Ho il sito web principale lì, quindi non vorrei lasciare quel servizio.

Sembra strano che DO sia dove Discourse è ospitato più spesso e che questo non li faccia riconsiderare. Qualche pensiero?

[Jagster (Jakke Lehtonen)]

@Linus_pi

Qualche idea?

Solo una. Perché rimanere e pagare per qualcosa che non si può ottenere ciò di cui si ha bisogno?

[Linus_pi (Linus)]

Beh, perché apparentemente ha funzionato per qualcun altro e questo li ha portati a sbloccare la porta.

Inoltre, e cosa importante: è un progetto cooperativo senza scopo di lucro con un focus sociale che cercherò di supportare rispetto a un servizio di una società. Quindi cercherò di allungarlo il più possibile.

[supermathie (Michael Brown)]

Per riferimento, ecco il post di DO su questo argomento:

SMTP restricted by default | DigitalOcean

E sembra che la porta 587 (invio autenticato) sia bloccata per impostazione predefinita:

Why is SMTP blocked? | DigitalOcean Documentation

A mio parere, bloccare 25 (SMTP) e 465 (SMTPS) per impostazione predefinita come misura antispam è ragionevole, ma bloccare 587 è insensato e sembra essere stato fatto per ignoranza del suo scopo.

[Linus_pi (Linus)]

Grazie, ho insistito con DO nel ticket aperto affinché spiegassero perché alcuni utenti sono interessati e altri no, ma loro insistono sulla loro politica. Immagino che abbia a che fare con i nuovi account, come spiega il tuo link. Ma ci potrebbe comunque essere un modo per verificare l’attività non di spam di un account o addirittura per controllarlo. La loro risposta è stata “Ci sono alcuni parametri che non possiamo divulgare per la sicurezza della nostra piattaforma”. Quindi immagino sia così. O cambiare il servizio email o cambiare VPS per discourse. Ma potrebbe succedere altrove? Chi lo sa…

[pacharanero (Marcus Baw)]

Per un motivo non chiaramente spiegato da DigitalOcean, hanno iniziato a bloccare le porte 465 e 587 il 6 marzo Release Notes | DigitalOcean Documentation “Le porte SMTP 465 e 587 sono ora bloccate sui Droplet.” Questo ha interessato un droplet istanziato oltre 2 anni fa, e che in precedenza funzionava correttamente nell’invio di email.

Tuttavia, ho sicuramente dei droplet su DO che sono in grado di inviare email utilizzando la porta 587, e ho anche dei droplet che hanno improvvisamente smesso di poter inviare.

Sono assolutamente inorridito che DO abbia fatto questo senza alcuna forma di notifica o avviso. Mi informano della manutenzione pianificata di LON1 circa 5 volte a settimana, quindi non capisco come non possano avvisarmi di una modifica potenzialmente dannosa alla rete. Ho scoperto che questo droplet non inviava email solo perché il cliente mi ha contattato per dire che sembra esserci un problema, il che è imbarazzante e poco professionale. Basti dire che gradualmente sposterò tutti i miei server da DO, ove possibile. (Uso molto Hetzner di questi tempi)

Dopo quella che è stata, temo di dirlo, un’email piuttosto aspra da parte mia oggi, hanno sbloccato le porte e ora tutto funziona.

Qualcuno ha suggerimenti su un modo per “monitorare l’uptime” dell’invio di email? Ci sono diversi modi in cui l’invio di email può fallire, e a meno che non si monitorino tutte le email di un forum, è difficile “accorgersi” sempre che l’invio di email non funziona più.