Thanks @mpalmer good to know. I’ll see if I can get some time for that
So this is less urgent now that I realise Discurse is smarter than I gave it credit for - but many of my users are very used to pressing Reply-All in their mail client for replying to our mailinglist. Most clients realise there’s only one person, and just use the Reply-To address, but a few put both addresses in, the Reply-To & the original noreply that is used as the sender.
I now see that DIscourse will handle that correctly so long as both addresses are present, but initially it looked like that wasn’t the case (bad testing on my part) so I was curious about blackholing rather than getting a BadDestinationError on every post.
Still, it may come in handy for addresses that get spammed or something, so I’ll see if I can work it in
Do I need to change the
https if I’m using SSL?
I ask because the instructions are not working for me. The log shows:
Failed to POST the e-mail to http://sunrisepoint.org/admin/email/handle_mail: 301
I tried editing
containers/mail-receiver.yml and changing the endpoint to
https, but even after stopping and starting the service and after bootstrapping again, it still shows
http in the logs.
I have force https enabled in the settings.
Got it! I had to issue the command
./launcher rebuild mail-receiver
At least, that’s what I did and it worked.
Working. Posts like lightning. Had to open port 25 on ufw.
Running this setup, let’s say your mail-receiver container fails for some reason (i.e. it is not running) - or your whole server is down, for that matter - and let’s say during that offline period, someone replies by email.
Is there any rule of thumb for how long we can expect that the reply will nevertheless be delivered, once the mail container is running again? I suppose the answer starts with “It depends”, but what does it depend on?
It depends on the configuration of the sending MTA, but typically MTAs will follow (or at least hang around in the general vicinity of) the RFC. Postfix’s default configuration is for retry delays ranging from five minutes to a little over an hour, but I’ve seen other MTAs that have retry intervals of up to a day. As a rule of thumb, if you haven’t seen it 24 hours after your receiving MTA comes back up, chances are you’ll never see it.
In other words, your mail-receiver can go down for an hour or so and it won’t be a problem (“retry intervals” is how long it will wait before trying again, not the maximum amount of time it will keep retrying before eventually bouncing the mail).
Correct. MTAs are supposed to queue mail for several days before returning it to sender.
I wonder if there is any way of writing in the mail-receiver.yaml file the message_size_limit, in order for it to be preconfigured on the postfix side.
I was trying to send attachments through email and couldn’t, until went to the logs and noticed postfix was refusing the message and then, following steps from Changing the Postfix maximum email size - Electric Toolbox managed to activate this, with some minor adaptations.
Here is what I did to setup 20mb limit:
0 - in /var/discourse run
./launcher enter mail-receiver
1 - run
postconf | grep message_size_limit to check the limit (probably you will get something like message_size_limit = 10240000 )
3 - add or replace a line with:
message_size_limit = 20480000 , where 20480000 is 20mb
4 - run
5 - confirm the value of message_size_limit running again:
postconf | grep message_size_limit
6 - Test sending that email !
I was trying to send emails with attachments smaller than 10mb and couldn’t so I guess that we really need that line over there if we want attachments to work. Right now I don’t find the need to go back and make this a “certainty”. Refute it if you find it otherwise.
Changing Max Attachment Size
I’ve got a site that’s getting spammed by random addresses at
qq.com dozens of times an hour. My first response was to stop accepting mail for the publicly-advertised email address (forwarded to an admin group). But we’re still bouncing a zillion emails for these incoming addresses.
I’m trying to drop that incoming mail. I tried like this, but it’s not working. Apparently I don’t know what to do to trigger this stuff getting
pups to pay attention to:
run: - file: path: /etc/postfix/access contents: | qq.com REJECT - file: path: /etc/postfix/main.cf contents: | smtpd_sender_restrictions = hash:/etc/postfix/access reject_unauth_destination = hash:/etc/postfix/access - exec: cmd: - postmap hash:/etc/postfix/access
So I’ve worked through the domain stuff and have mail being received at my server.
./launcher logs mail-receiver
gives the following:
<22>Nov 5 05:46:46 postfix/smtpd: connect from st11p05im-asmtp002.me.com[220.127.116.11] <22>Nov 5 05:46:46 postfix/smtpd: E1F72BD476: client=st11p05im-asmtp002.me.com[18.104.22.168] <22>Nov 5 05:46:46 postfix/cleanup: E1F72BD476: message-id=<E2E6F51C-E0CA-4923-BF42-DADD6F132C8C@mac.com> <22>Nov 5 05:46:46 postfix/qmgr: E1F72BD476: from=<email@example.com>, size=4565, nrcpt=1 (queue active) <22>Nov 5 05:46:47 postfix/smtpd: disconnect from st11p05im-asmtp002.me.com[22.214.171.124] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 <23>Nov 5 05:46:47 receive-mail: Recipient: firstname.lastname@example.org <19>Nov 5 05:46:47 receive-mail: Failed to POST the e-mail to http://community.wd6awp.us/admin/email/handle_mail: 301 <22>Nov 5 05:46:47 postfix/pipe: E1F72BD476: to=<email@example.com>, relay=discourse, delay=0.35, delays=0.16/0/0/0.19, dsn=4.3.0, status=deferred (temporary failure)
The Failed to POST … line looks bothersome. My site is actually https but I goofed up editing the yml. Do I need to change that? If so how do I make the container see the edit ./launcher restart?
Is the inbound email that you’re collecting replies on actually nobody@ ?
No, it’s set to forum-replies. But I get the same failure when it is.
<23>Nov 5 06:20:05 receive-mail: Recipient: firstname.lastname@example.org <19>Nov 5 06:20:05 receive-mail: Failed to POST the e-mail to http://community.wd6awp.us/admin/email/handle_mail: 301 <22>Nov 5 06:20:05 postfix/pipe: D96B3BD478: to=<email@example.com>, relay=discourse, delay=0.32, delays=0.16/0/0/0.15, dsn=4.3.0, status=deferred (temporary failure)
Fixed it. The problem was https vs http. Edited yml and ran launcher rebuild.
Can the container be configured to offer TLS ?
Some of the users use emails that send TLS enforced emails and their mails usually hard fail with
TLS is required, but was not offered by host
I am also exploring this setup and have two questions:
- is it possible to set forwarding of specific email (e.g. admin@ to my gmail)
- is TLS setup possible with mail-receiver?
You can set up a group with admin as the incoming address and put a user with your Gmail address in it. You’ll then get notifications at the Gmail address. It won’t be the same as forwarding though.
I don’t think that the setup supports tls or if the box.
Even though, I would prefer forward to be done even with Discourse being down, but this could work. However, I did not find this option on existing group and also not on newly created group. Do I need to enable something in settings to get this “incoming address” option?