Straightforward direct-delivery incoming mail

(Jeff Atwood) #110

(Greg) #111

Thanks @mpalmer good to know. I’ll see if I can get some time for that :slight_smile:

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 :wink:

(Freddie Haddad) #112

Do I need to change the DISCOURSE_MAIL_ENDPOINT to 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 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

(Michael Howell) #113


At least, that’s what I did and it worked.

(Geoff Forster) #116

Working. Posts like lightning. Had to open port 25 on ufw.

(Christoph) #117

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?

(Matt Palmer) #118

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.

(Michael Howell) #119

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).

(Matt Palmer) #120

Correct. MTAs are supposed to queue mail for several days before returning it to sender.

(Diogocsc) #122

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 )
2 - vi /etc/postfix/
3 - add or replace a line with: message_size_limit = 20480000 , where 20480000 is 20mb
4 - run postfix reload
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
(Matt Palmer) #123

(Jay Pfaffman) #124

I’ve got a site that’s getting spammed by random addresses at 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:

  - file:
      path: /etc/postfix/access
      contents: |    REJECT

  - file:
      path: /etc/postfix/
      contents: |
        smtpd_sender_restrictions = hash:/etc/postfix/access
        reject_unauth_destination = hash:/etc/postfix/access

  - exec:
      - postmap hash:/etc/postfix/access

(Tim Sawyer) #125


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[216]: connect from[]
<22>Nov  5 05:46:46 postfix/smtpd[216]: E1F72BD476:[]
<22>Nov  5 05:46:46 postfix/cleanup[223]: E1F72BD476: message-id=<>
<22>Nov  5 05:46:46 postfix/qmgr[131]: E1F72BD476: from=<>, size=4565, nrcpt=1 (queue active)
<22>Nov  5 05:46:47 postfix/smtpd[216]: disconnect from[] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
<23>Nov  5 05:46:47 receive-mail[225]: Recipient:
<19>Nov  5 05:46:47 receive-mail[225]: Failed to POST the e-mail to 301
<22>Nov  5 05:46:47 postfix/pipe[224]: E1F72BD476: to=<>, 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?

(Stephen) #126

Is the inbound email that you’re collecting replies on actually nobody@ ?

(Tim Sawyer) #127

No, it’s set to forum-replies. But I get the same failure when it is.

<23>Nov  5 06:20:05 receive-mail[262]: Recipient:
<19>Nov  5 06:20:05 receive-mail[262]: Failed to POST the e-mail to 301
<22>Nov  5 06:20:05 postfix/pipe[261]: D96B3BD478: to=<>, relay=discourse, delay=0.32, delays=0.16/0/0/0.15, dsn=4.3.0, status=deferred (temporary failure)

(Tim Sawyer) #128

Fixed it. The problem was https vs http. Edited yml and ran launcher rebuild.

(Bhanu Sharma) #129

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

(Luka Renko) #130

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?

(Jay Pfaffman) #131

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.

(Luka Renko) #132

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?