Beperkingen op "Aangepast inkomend e-mailadres" (alleen voor gehoste sites, misschien?)

Hallo Discourse Community —

Het volgende is iets dat ik door vallen en opstaan heb waargenomen, maar waarvoor ik geen documentatie heb gezien noch een waarschuwing of foutmelding ben tegengekomen.

Op onze site, die wordt gehost door Discourse (waarvoor we zeer dankbaar zijn!), lijkt het instellen van een aangepast inkomend e-mailadres voor een categorie alleen te werken als het e-mailadres voorafgegaan wordt door “foo+{iets}@discoursemail.com” (waarbij ‘foo’ de algemene slug voor onze site is).

Meer specifiek, ik stel vaak een nieuwe categorie in, stel een voor mij intuïtief e-mailadres in, stuur een testmail naar dat adres en krijg nooit een bounce (correctie: ik kreeg er uiteindelijk wel een paar uur later een) noch zie ik het verschijnen in de ontvangen of geweigerde e-mail logs van onze site. Vervolgens herinner ik me mijn eerdere ervaringen, stel ik het adres in op foo+\u003ceennnaam\u003e, voer ik nog een test uit en werkt het onmiddellijk.

Als ik het me niet verbeeld, lijkt dit begrijpelijk als een manier voor Discourse om e-mails die bestemd zijn voor de ene gehoste site te onderscheiden van de andere, maar ik wilde controleren of ik gelijk heb. Of, als ik het mis heb, of er andere verklaringen zijn waarom mijn eerste keuzes van e-mailadressen naar /dev/null lijken te gaan.

Bedankt!
-Brad

1 like

It may seem simple/reductive to state out loud, but the custom email address only works if it actually gets delivered to the site.

So you can’t just put anything there, the address must get delivered to the site for it to stand a chance of working.

There’s no way for Discourse to do any verification of that address to ensure that happens, so the onus is on the admin to ensure that happens.

On our hosting I recommend leveraging a few addresses that we’ve prearranged to get delivered to your site:

  • {ANYTHING}@{YOUR PREFIX}.discoursemail.com
  • {ANYTHING}@{your.site.hostname}
2 likes

Bedankt @supermathie

Voor onze (gehoste) site realiseerde ik me niet dat …@{OUR PREFIX}.discoursemail.com een optie was en heb ik altijd alleen …@discoursemail.com als hostnaam geprobeerd te gebruiken, omdat dat is wat het standaard “accepteer inkomende e-mails” adres gebruikt (en ik heb mijn oorspronkelijke vraag hierboven bijgewerkt om dit te verduidelijken, aangezien ik de hostnaam in de oorspronkelijke vraag heb weggelaten). Ik zal dat proberen, bedankt voor de tip!

Hoewel ik begrijp dat Discourse geen e-mailadressen kan verifiëren voor zelf-gehoste instanties van Discourse, zou het dan mogelijk zijn om de gehoste instanties een waarschuwing of fout te laten genereren als het e-mailadres niet van een verwacht formaat was? (of een verwacht formaat bij gebruik van een …discoursemail.com adres?

Nogmaals bedankt,
-Brad

1 like

There is no bound to the “expected format” other than “valid email address”, so this isn’t feasible.

This might be something we could do.

3 likes

Bedankt nogmaals voor het antwoord!

Ik denk dat je mijn vermoeden hebt bevestigd dat dit een probleem is dat specifiek is voor gehoste Discourse-sites zoals de onze. Ik weet niet hoeveel moeite het zou kosten om dergelijke sites te laten verifiëren dat de …discoursemail.com-adressen die in dit veld zijn ingevoerd geldig zijn, maar een dergelijke functie zou me de afgelopen jaren veel tijd en frustratie hebben bespaard bij het opzetten van nieuwe mailinglijsten en aliassen, en me afvragen waarom ze niet werken. Ik kan me voorstellen dat het ook anderen zou helpen.

Als alternatief zou zelfs een kleine tooltip bij dat veld voor een gehoste site die aangeeft dat een legaal adres slug+...@discoursemail.com of ...@slug.discoursemail.com moet zijn, al veel helpen. Hoewel ik niet weet of het specifiek maken van die tip voor gehoste Discourse-sites die aanpak onwerkbaar maakt.

-Brad

This is not true — the constraint is that the email must be delivered (not addressed) to one of these addresses to work. An example is the following setup which is what we and many of our customers use:

  • (in Discourse) configure Postings category to accept inbound email sent to postings@contoso.com
  • (on contoso.com mail server) configure postings@contoso.com to forward to {ANYTHING}@contoso.discoursemail.com
  • end result: mail addressed to postings@contoso.com gets sent to the Postings category

This functions effectively the same as:

  • (in Discourse) configure Postings category to accept inbound email sent to postings@contoso.discoursemail.com
  • end result: mail addressed to postings@contoso.discoursemail.com gets sent to the Postings category
1 like

@supermathie — Goed punt dat het afleveradres relevanter is dan het adres waaraan de post is geadresseerd.

Mijn vorige verzoek verfijnen, ik denk dat een waarschuwing bij het proberen in te voeren van inkomende e-mailadressen die overeenkomen met de patronen @discoursemail.com of @*.discoursemail.com, maar die niet beginnen met slug+… of eindigen met @slug.discoursemail.com, nog steeds waardevol zou zijn om te waarschuwen voor communities die door Discourse worden gehost.

Dit zou nog steeds je eerste geval toestaan (aangezien het geen discoursemail.com als achtervoegsel heeft), terwijl het me nog steeds waarschuwt voor het proberen in te stellen van een slug-users@discouresmail.com adres, wat het type patroon is waar ik altijd naar greep en dan in de war raakte toen e-mails ernaar stilzwijgend werden genegeerd.

(Merk op dat je tweede geval ook geen waarschuwing zou genereren, ervan uitgaande dat contoso de slug van je community is).

-Brad

Dit onderwerp werd automatisch gesloten na 2 dagen. Nieuwe antwoorden zijn niet meer toegestaan.