The discussion centers on a bug where Discourse rejects emails from known users who lack permission to post in a private category, while accepting emails from anonymous users. The original reporter, downey, outlines that emails from unregistered addresses work, but those from registered non-members are rejected with a can_create? failed error. zogstrip confirms this is intentional behavior: the system associates the email with the user first, then checks permissions. Since the user is not in the allowed group, the post is blocked. The email_in_allow_strangers setting currently only applies to staged (unactivated) users.
Several users, including wityr and Christian_Kindel, argue this is counter-intuitive and problematic, especially for mailing list mirrors where known subscribers are blocked while unknown senders are accepted. dachary proposes code patches to bypass validation when email_in_allow_strangers is enabled, though sam explains that the current restriction is a security measure to prevent email spoofing and impersonation. Sam suggests a long-term solution involving a verification step where the user confirms the email was sent by them.
Other participants, such as Simon_Manning, argue that modern email authentication protocols like SPF, DKIM, and DMARC provide sufficient protection against spoofing, suggesting that the system could safely accept emails from known users if these checks pass. sam considers adding a site setting to allow operators to accept this risk. Simon_Manning further clarifies that the issue is specific to private categories; in public categories, known users with permissions can post via email without issue. The consensus among developers is that fixing this requires a comprehensive approach to security, potentially leveraging email authentication results to allow known users to post in restricted categories without compromising safety against impersonation. The issue persists in recent versions, affecting projects like the Tor Forum that rely on email-to-forum functionality.
Have a “private” category that only has create/reply/see access for members of a specific group. No other permissions.
Enable “anonymous email in” for that specific via a unique working alias to the incoming POP account.
Have a non-staff user that is not a member of the group send an email report in to the category email address from the email address associated with their account.
Send in an email from an account not associated with any known Discourse account.
Expected Behavior:
Both #3 and #4 result in new topics in the private category, and the group can begin discussion.
Actual Behavior:
The email in #4 works but email in #3 is rejected with the can_create? failed error.
When we receive an email, we first try to associate it to a user, and then we check for permissions. Since the user isn’t part of the group, they can’t post.
The email_in_allow_strangers field on the category only works for staged users.
Can confirm #3 still not working. Is the best workaround right now to have emails directed at a group rather than a category? Not my preferred arrangement but I can switch until a patch comes out.
This scenario seems to be replaced these days with the group functionality as a type of workaround, although I could see some use cases that it might still be just as valuable for categories/topics/discussions.
Like you say, this is just a (bad) workaround. IMO this should be controllable on a per-category level. Clearly a bug that this works only for anonymous but not for known users.
Ho appena riscontrato questo problema mentre cercavo di impostare una categoria per l’elenco delle informazioni delle nostre organizzazioni. Questa categoria consente l’accesso solo a un determinato gruppo, ma abbiamo selezionato l’opzione per consentire email da utenti anonimi. Gli indirizzi email non associati a nessuno dei nostri utenti Discourse possono inviare un messaggio che apparirà nella categoria, ma gli utenti registrati che non fanno parte del gruppo vengono rifiutati a causa di “Livello di fiducia insufficiente”. Penso di aver compreso la ragione tecnica per cui funziona in questo modo (funziona solo per gli utenti in staging), ma c’è un motivo per cui questo sarebbe il comportamento desiderato o previsto? A mio parere, se scegliamo di consentire agli utenti anonimi, probabilmente vorremmo permettere anche a tutti gli utenti registrati.
Anche noi abbiamo riscontrato questo problema con il nostro sito la settimana scorsa. Per noi, la situazione è la seguente:
Sebbene la maggior parte delle nostre categorie sia destinata solo agli utenti registrati, volevamo un modo per un non membro della comunità di mettersi in contatto con gli sviluppatori principali via email per fare una domanda rapida, sollevare un problema, ecc.
Abbiamo fatto questo impostando una categoria per accettare email da utenti anonimi utilizzando un indirizzo personalizzato (ad esempio, ourproject+contact@discoursemail.com). Abbiamo impostato i permessi della categoria in modo che fosse leggibile solo dai membri principali del progetto per evitare di generare troppe email o rumore per la comunità in generale (il che significava rendere le discussioni creabili e rispondibili anche dai membri principali, poiché non c’è modo di limitare l’accesso in lettura senza limitare anche l’accesso alla creazione/risposta).
Tuttavia, abbiamo poi scoperto che se l’utente anonimo avesse successivamente creato un account ufficiale, non avrebbe più potuto inviare email all’indirizzo di contatto. Questo sembra controintuitivo, dato che ora sono più ufficiali e registrati di prima, ma possono fare rigorosamente meno di quanto potevano fare prima.
Ciò mi ha causato molta confusione prima di trovare questo argomento e sembra ancora una situazione sfortunata.
Questo problema persiste ancora nella versione 2.7.8. È confuso il fatto che una mail inviata all’indirizzo email associato a una categoria venga accettata quando il mittente non ha un account registrato nel forum, ma venga rifiutata se lo ha.
Credo che la seguente patch (rispetto al ramo main corrente) possa risolvere il problema saltando le convalida quando email_in_allow_strangers è impostato per la categoria, nello stesso modo in cui viene saltato per gli utenti in staging. Ha senso?
diff --git a/lib/email/receiver.rb b/lib/email/receiver.rb
index 7c76c44d61..dd3bc3cfb0 100644
--- a/lib/email/receiver.rb
+++ b/lib/email/receiver.rb
@@ -762,7 +762,7 @@ module Email
elided: elided,
title: subject,
category: destination.id,
- skip_validations: user.staged?)
+ skip_validations: (user.staged? || destination.email_in_allow_strangers))
elsif destination.is_a?(PostReplyKey)
# Non mettiamo in staging nuovi utenti per gli indirizzi di risposta alle email, esci se l'utente è nil
Non funziona perché le validazioni riguardano il contenuto del post, non i permessi per creare o meno un post…
Ho testato la patch sottostante e funziona. È un trucco, non provarlo a casa Il suo merito è identificare grossolanamente dove dovrebbero avvenire le modifiche. La sfida è capire come farlo in modo corretto. Qualsiasi consiglio sarà molto gradito
diff --git a/app/jobs/regular/notify_mailing_list_subscribers.rb b/app/jobs/regular/notify_mailing_list_subscribers.rb
index c535296105..1d3bf79637 100644
--- a/app/jobs/regular/notify_mailing_list_subscribers.rb
+++ b/app/jobs/regular/notify_mailing_list_subscribers.rb
@@ -74,7 +74,7 @@ module Jobs
DiscourseEvent.trigger(:notify_mailing_list_subscribers, users, post)
users.find_each do |user|
- if Guardian.new(user).can_see?(post)
+ if Guardian.new(user).can_see?(post) && Guardian.new(user).can_see_category_staged?(post.topic.category)
if EmailLog.reached_max_emails?(user)
skip(user.email, user.id, post.id,
SkippedEmailLog.reason_types[:exceeded_emails_limit]
diff --git a/app/models/category.rb b/app/models/category.rb
index 630a74c425..6c253650c6 100644
--- a/app/models/category.rb
+++ b/app/models/category.rb
@@ -201,7 +201,7 @@ class Category < ActiveRecord::Base
end
else
permissions = permission_types.map { |p| CategoryGroup.permission_types[p] }
- where("(:staged AND LENGTH(COALESCE(email_in, '')) > 0 AND email_in_allow_strangers)
+ where("(LENGTH(COALESCE(email_in, '')) > 0 AND email_in_allow_strangers)
OR categories.id NOT IN (SELECT category_id FROM category_groups)
OR categories.id IN (
SELECT category_id
@@ -209,7 +209,6 @@ class Category < ActiveRecord::Base
WHERE permission_type IN (:permissions)
AND (group_id = :everyone OR group_id IN (SELECT group_id FROM group_users WHERE user_id = :user_id))
)",
- staged: guardian.is_staged?,
permissions: permissions,
user_id: guardian.user.id,
everyone: Group[:everyone].id)
diff --git a/lib/guardian/category_guardian.rb b/lib/guardian/category_guardian.rb
index 94a48466d6..2a4ba8015c 100644
--- a/lib/guardian/category_guardian.rb
+++ b/lib/guardian/category_guardian.rb
@@ -64,6 +64,14 @@ module CategoryGuardian
end
def can_see_category?(category)
+ return false unless category
+ return true if is_admin?
+ return true if !category.read_restricted
+ return true if category.email_in.present? && category.email_in_allow_strangers
+ secure_category_ids.include?(category.id)
+ end
+
+ def can_see_category_staged?(category)
return false unless category
return true if is_admin?
return true if !category.read_restricted
Non è forse già presente questo problema, indipendentemente dal parametro Accetta email da utenti anonimi senza account?
Condivido quel punto di vista: quando un’email è associata a una categoria e la casella Accetta email da utenti anonimi senza account è selezionata, un’email in arrivo
associata a un account Discourse
a cui non è consentito leggere i messaggi secondo i parametri Sicurezza della categoria
L’uso di SPF/DKIM/DMARC, che ora è molto più diffuso rispetto al 2016, non protegge a sufficienza da questo problema?
Qualsiasi buon provider di posta elettronica (per l’utente) non consentirà ad altri utenti di inviare da indirizzi che non appartengono a loro e qualsiasi buon provider di posta elettronica o servizio di ricezione (per l’istanza Discourse) dovrebbe rifiutare le e-mail che non superano la validazione di origine.
Esisteranno provider che non convalidano l’indirizzo del mittente e/o non impostano record SPF/ecc., ma se un utente sceglie di utilizzare un provider di posta elettronica che non fa nulla per proteggere dall’impersonificazione, sembra ragionevole che possa essere impersonato.
Non ci sono entrato particolarmente a fondo, ma sembra che Email::AuthenticationResults faccia già una qualche validazione dell’origine. Forse nel breve (più breve) termine, il verdetto potrebbe essere reso disponibile (se non lo è già) in modo che queste email possano essere accettate con un verdetto di superamento.
Nella tua soluzione a lungo termine, la verifica “eri davvero tu?” potrebbe anche essere saltata in caso di verdetto di superamento.
Il suo merito è identificare grossolanamente dove dovrebbero avvenire le modifiche. La sfida è capire come farlo in modo corretto. Qualsiasi consiglio sarà molto gradito 