Kevin Fenzi wrote: > On Sun, Apr 23, 2023 at 11:21:58PM +0200, Björn Persson wrote: > > Kevin Fenzi wrote: > > > We could probibly come up with some > > > better way to start new topics/discussions > > > > Yes I think I can come up with a better way. Give each tag its own > > email address, like a mailing list. That was very easy to come up with. > > I think you mean each category? I don't know Discourse but we're told that something called a tag is roughly equivalent to a mailing list. I suppose categories could have addresses too. > But you may want multiple tags on a post... Like Vít said, you can send to multiple addresses. That's how you cross-post to multiple mailing lists. The Discourse server would then read all the addresses and apply all of those tags and/or categories to the post. When there are multiple recipient addresses in the same domain, a well-behaved SMTP client is supposed to transmit a single copy of the message in a single SMTP session with multiple RCPT commands. Thus the Discourse server will receive only one copy. It is however possible that some badly written program might mishandle such a message and send a separate copy to each recipient address. Each copy would then still contain the whole list of addresses in the To and CC fields. If the Discourse server would read the header fields and not just the SMTP envelope, then the copies would appear as duplicate posts, each with the full set of tags, not as separate posts with one tag each. If duplicates would turn out to be a great nuisance, then the Discourse developers might want to add a deduplication feature. The Message-ID field would be useful for discovering duplicates, but deduplication should not be done based on the message ID alone. The full contents should be compared to ensure that the messages really are identical, in case some defective or malicious email client produces non-unique message IDs. As you can see, it doesn't take any great inventions to do this. The email standards already contain the necessary features. They just need to be implemented, if the Discourse developers are serious about supporting interaction by email. > But that also doesn't solve the spam problem... anyone could send to > those addresses, and indeed spammers will. ;( We're told that only sender addresses associated with a Fedora account are allowed to send to the single global new-topic address. Obviously that would apply to the tag (and category) addresses too. That's analogous to reducing spam to mailing lists by accepting posts only from subscribers. In what scenario do tag-specific new-topic addresses result in a worse spam problem than a single global new-topic address? > But perhaps this could be useful with some other way to autenticate > posts. I haven't seen spammers impersonate subscribers in the mailing lists. The occasional spam that gets into the mailing lists seems to be done by subscribing a disposable address and sending from that address. If spammers would start putting in a legitimate user's address as sender to get the spam into mailing lists or Discourse, then there's DKIM. I have found DKIM by itself ineffective, as most of the spam is DKIM- signed now, but DKIM combined with a requirement for a known sender address should be sufficient authentication to stop spam. The spammer would at least have to actually send from the same domain as the user they impersonate. For registered users whose email provider doesn't sign their messages with DKIM, a verification message could be sent that they have to reply to, like when signing up for a mailing list but repeated for every post that isn't a reply. There's also OpenPGP/MIME. But I rather doubt that such measures will be needed just to fight spam. Strong authentication is for preventing more targeted attacks than spam. Björn Persson
Attachment:
pgpZ7VPWoBVrp.pgp
Description: OpenPGP digital signatur
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
