Sono nell’architettura ARM e questo comando genera errori. Suppongo che questo plugin non sia adatto per arm?
Esiste un altro plugin per ricevere email per arm?
Mi dispiace, ma non ho familiarità con arm, quindi non posso consigliare se sia inadatto, ma volevo solo far notare che questo non è un plugin. Spero si tratti solo di un’incomprensione terminologica e che tu non stia cercando di installarlo come plugin, perché non funzionerà. 
1 Mi Piace
Grazie per la risposta. Ah, colpa mia, pensavo funzionasse come un plugin. Se ha un termine diverso, per favore fammelo sapere. Il mio server è in esecuzione su arm64, i nuovi chip, immagino, in amazon ec2.
L’ho appena installato come spiegato nel post. Ma genera errori. Sembra che non funzioni su arm64.
1 Mi Piace
Solo per chiarimento, stai dicendo di aver completato con successo l’installazione standard e di avere un’istanza Discourse funzionante su arm, tuttavia l’installazione specifica di mail-receiver sta fallendo?
Quali sono gli errori che stai riscontrando? Se puoi fornire i messaggi di errore, ciò potrebbe aiutare a identificarne la causa. Fai attenzione a verificare la presenza di informazioni sensibili che necessitano di essere oscurate.
È un po’ difficile (per me) dargli un termine particolare in relazione a Discourse. Sotto il cofano è solo un’applicazione container completamente separata per un server di posta elettronica in sola ricezione che è (è deliberatamente) configurata per recapitare tali email a Discourse tramite la sua API.
2 Mi Piace
Sì, questa è la procedura di installazione standard per installare discourse. E discourse funziona bene, suppongo, su arm64.
Gli errori sono i seguenti:
Status: Downloaded newer image for discourse/mail-receiver:release
docker.io/discourse/mail-receiver:release
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/bin/gem: exec format error
cd /pups && /pups/bin/pups --stdin
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Ho iniziato a usare aws WorkMail per il momento, ma se discourse può avere una semplice funzionalità di ricezione e composizione di posta, allora vale sicuramente la pena usarlo come casella di posta ufficiale.
Non esiste un server di posta semplice. Esiste un server di posta o non esiste. E i server di posta sono estremamente difficili, molto vulnerabili a diventare centri di spam e nella maggior parte dei servizi cloud/VPS sono vietati.
Ecco perché Discourse interrogherà un vero server di posta, ritirando la posta e spostandola. Se un amministratore lo ha configurato.
1 Mi Piace
Credo che tu mi abbia frainteso.
Non mi riferisco alla “Creazione di un server di posta”. Piuttosto, avere un’interfaccia semplice ma gradevole (UX) per comporre (inviare email) e leggere (email in arrivo), in modo da poterla utilizzare per rispondere alle email ufficiali che riceviamo.
Il “semplice servizio email (SES)” di AWS non sta già controllando lo spam, ecc.? Dobbiamo solo fornire l’UX in Discourse in modo da avere una casella di posta e un compositore con un’UX gradevole e semplice.
Non sono del tutto sicuro se fornire un’UX a pagina singola in Discourse sia così complesso (dato che abbiamo già il server integrato in esso e possiamo utilizzare AWS SES tramite Discourse).
Per l’immagine di base di Discourse, lo strumento launcher rileva quando viene eseguito su arm64 e passa a un’immagine arm64 con un avviso che si tratta di una versione sperimentale. Lo stesso non accade per mail-receiver e, guardando le immagini su Docker Hub, sembra che una versione arm64 non esista.
Ci sono due opzioni ovvie che mi vengono in mente:
- Passare a un’istanza EC2 amd64, ottenendo un’installazione di Discourse non sperimentale e permettendoti di installare
mail-receiverinsieme ad essa. - Aggiungere una seconda istanza EC2, l’opzione più piccola con amd64 (t3a.nano, credo), e installare
mail-receiversu quella.
Non importa dove si trovi mail-receiver, il record DNS MX per il tuo indirizzo email di risposta deve semplicemente puntare in modo affidabile ad esso e deve essere in grado di connettersi alla tua istanza Discourse.
Se questo si riferisce alla gestione di email per indirizzi come info@tuaazienda.com, vendite@tuaazienda.com, supporto@tuaazienda.com, ecc., allora penso che la messaggistica di gruppo ti darà ciò che stai cercando.
Ovvero, dopo aver fatto funzionare mail-receiver, puoi creare gruppi appropriati in Discourse e assegnare ai gruppi uno o più indirizzi email in arrivo personalizzati. Quando guardi i messaggi del tuo utente, vedrai caselle di posta/ecc. per tutti i gruppi di cui fai parte.
Se utilizzi questo dominio per le email del personale, ad esempio prettygirl@tuaazienda.com, dovrai configurare qualcosa con il tuo provider di posta elettronica per far arrivare indirizzi specifici (ad esempio, info@) in Discourse. A seconda di ciò che offre il tuo provider di posta elettronica, potrebbe essere difficile far arrivare le email in Discourse con gli indirizzi “from” corretti, poiché non puoi semplicemente inoltrarle, dato che Discourse vedrà tutto come proveniente dal tuo indirizzo invece che dal mittente originale.
In Microsoft 365 / Exchange, una combinazione di un connettore per instradare a mail-receiver e regole di trasporto per far sì che email specifiche utilizzino quel connettore funzionerebbe.
Le email sono difficili, mail-receiver è progettato per semplificare la risposta alle notifiche via email e la creazione di argomenti (nuovi messaggi ai gruppi inclusi in questo) dove il dominio utilizzato non si sovrappone ai servizi di posta elettronica esistenti. Oltre a ciò, stai entrando in un territorio avanzato non supportato, potenzialmente “non è stato progettato per essere utilizzato in quel modo”.
2 Mi Piace
La risposta alla domanda posta nel titolo è “no”.
La 1 è ciò a cui ho pensato fin dall’inizio. Questa è la soluzione raccomandata e supportata a questo punto.
Ho visto di recente attività su discourse_docker riguardo all’aumento del supporto per ARM, credo, ma sembra improbabile che il supporto per il ricevitore di posta su ARM venga aggiunto a breve. Ma questa è solo un’ipotesi. Non ho alcun controllo sulla questione e ci sono molte cose che non so.
L’altra opzione sarebbe capire come far supportare ARM al ricevitore di posta e inviare una PR.
Se ami, ami, ami ARM, allora potresti trovare un ricevitore di posta completo con caselle di posta e tutto il resto e gestire un mucchio di caselle di posta.
2 Mi Piace
Sarebbe certamente possibile supportare mail-receiver sui sistemi ARM. Non c’è nulla di specifico per amd64 (o, almeno, non c’era quando l’ho creato, e non riesco a immaginare che siano state apportate modifiche importanti per invalidare tale supposizione). Si tratterebbe solo di far sì che i manutentori dell’immagine Docker creino una build dell’immagine per arm64, come già fanno per amd64.
Qualcuno potrebbe anche fare una build non ufficiale e metterla da qualche parte, insieme alle istruzioni sulla modifica di una sola riga necessaria al template pups, oppure potresti fare la tua build locale dal repo sul sistema arm64 su cui stai eseguendo.
5 Mi Piace
C’è socketee che viene scaricato in /usr/local/bin da GitHub come parte del Dockerfile. Quello è un binario x86_64 quindi non funzionerà, tuttavia sembra che venga utilizzato solo se configurato esplicitamente.
Nello specifico, la funzionalità sopra indicata fallirebbe su arm64 poiché socketee non riuscirebbe ad essere eseguito. Non vedo nient’altro che non funzionerebbe semplicemente compilando per arm64.
Non sono sicuro al 100%, ma da un’osservazione casuale, sembra che basti aggiungere queste righe al file build per farlo:
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
Sì, l’ho escluso dalla mia analisi perché è estremamente improbabile che qualcuno al di fuori di CDCK lo stia utilizzando, poiché è stato incluso per lo scopo molto specifico di centralizzare i log di Postfix – qualcosa che un normale consumer di mail-receiver quasi certamente non farà.
2 Mi Piace
se mail-receiver non funziona su ARM e IMAP funziona solo con GMail, questo è molto limitante.
È la prima volta che vedo 
funzionare nella mia ombra, e questo mi rattrista molto.
Se qualcuno è interessato, ho creato un’immagine arm64 e l’ho caricata su womble/discourse-mail-receiver:arm64, per tamponare le persone fino a quando il team principale non sarà in grado di creare un’immagine ufficiale. Vedi il README del mio branch per maggiori dettagli sulle limitazioni (nessun socketee per ora; lo aggiungerò se qualcuno dice che ne ha bisogno), su come usarlo e su come segnalare problemi (cioè “dillo a me, non al team principale”).
6 Mi Piace
Ho PR’ed la rimozione di socketee Remove socketee support by Firefishy · Pull Request #28 · discourse/mail-receiver · GitHub
Sarei anche felice di PR le modifiche per allineare mail-receiver con il processo di build ARM64 utilizzato da discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub
1 Mi Piace