Relaying For Other Machines

The Relaying For Other Machines section of the Advanced Configuration page on the website could use a couple of simple changes:

  1. The port has to be specified in relayhost (relayhost = box.example.com:587)
  2. TLS needs to be specified (smtp_use_tls = yes)

I’ve set up an account on my MIAB box dedicated to send email for a remote workstation. It works, but only if I specify the account as a parameter to mail:

echo "relay test" | mail -r remoteworkstation@example.org -s "relay test" me@example.org

That section of the Advanced Configuration page really makes it seem like that isn’t necessary. Is there a way to configure the remote workstation so that all email (regardless of the user doing the sending) is sent from the same address (remoteworkstation@example.org in this case)? I tried /etc/aliases but it had no affect.

I’ve been messing with aliases, virtual alias domains, and recipient canonical maps, but am having no luck.

The problem is the sender’s address on the remote workstation (bill@example.org) not being owned by the account on the MIAB server the remote workstation uses to send (remoteworkstation@example.org):

Aug 11 20:47:19 tiny postfix/pickup[18166]: 61CF6460AF0: uid=1000 from=<bill>
Aug 11 20:47:19 tiny postfix/cleanup[18184]: 61CF6460AF0: message-id=<20190812024719.61CF6460AF0@tiny.local>
Aug 11 20:47:19 tiny postfix/qmgr[18165]: 61CF6460AF0: from=<bill@example.org>, size=332, nrcpt=1 (queue active)
Aug 11 20:47:20 tiny postfix/smtp[18186]: 61CF6460AF0: to=<me@example.org>, relay=box.example.com[123.123.123.123]:587, delay=0.98, delays=0.04/0.05/0.79/0.1, dsn=5.7.1, status=bounced (host box.example.com[123.123.123.123] said: 553 5.7.1 <bill@example.org>: Sender address rejected: not owned by user remoteworkstation@example.org (in reply to RCPT TO command))
Aug 11 20:47:20 tiny postfix/cleanup[18184]: 78358460B07: message-id=<20190812024720.78358460B07@tiny.local>
Aug 11 20:47:20 tiny postfix/bounce[18188]: 61CF6460AF0: sender non-delivery notification: 78358460B07
Aug 11 20:47:20 tiny postfix/qmgr[18165]: 78358460B07: from=<>, size=2324, nrcpt=1 (queue active)
Aug 11 20:47:20 tiny postfix/qmgr[18165]: 61CF6460AF0: removed
Aug 11 20:47:21 tiny postfix/smtp[18186]: 78358460B07: to=<tiny@example.org>, orig_to=<remoteworkstation@example.org>, relay=box.example.org[123.123.123.123]:587, delay=0.76, delays=0.01/0/0.56/0.19, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 1B2D27E7C3)
Aug 11 20:47:21 tiny postfix/qmgr[18165]: 78358460B07: removed

Solved it.

I was close with recipient canonical maps. The actual solution is with sender canonical maps. Just add the following to main.cf:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Add the following to /etc/postfix/sender_canonical:

root     tiny
bill      tiny

Build hash database:

sudo postmap /etc/postfix/sender_canonical

And reload Postfix’s configuration:

sudo postfix reload

This Postfix configuration is all done on the remote workstation, tiny in my case. After it is in place, both root and bill can send email via the tiny account, which must exist on the MIAB box, and the SASL credentials must be configured (on the remote workstation) as detailed in the Relaying For Other Machines section of the Advanced Configuration page.

Create the alias bill@example.org being forwarded to remoteworkstation@example.org. That should be the solution without creating an unsupported modification.

Your sender_canonical_maps in main.cf likely will be clobbered when you upgrade MiaB requiring you to make your modification again.

I’m sorry. I wasn’t clear.

Other than creating an account corresponding to the remote workstation on the MIAB server, all the modifications to Postfix are on the remote workstation.

Last night, I got my first emails from smartd on the workstation. I’m pretty happy about that.

No, don’t be sorry. I was misreading your post due to lack of sleep. I am not sure why I thought you were modifying the MiaB … I can only claim lack of sleep caused it. I’m sorry.

I still think that you’d have success with the solution I mentioned … you seemingly have things working now, so why mess with a good thing?! That is the beauty of the internet - sometimes there is more than one way to accomplish things. :slight_smile:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.