Add support for TLS authenticated "sibling host" relayers #212
Conversation
The use case for this is e.g. a www server that is a separate machine to the mailinabox, but which needs to send emails to the internet - for example it may be running Wordpress or some other web app and need to notify arbitrary users of comments etc. In such cases, as the www administrator is using mailinabox, they're almost certainly better off letting mailinabox do as much as possible as far as email is concerned (as opposed to having the www sibling host do full delivery itself) - among other things this simplifies reasoning about DNS records.
|
Hello, Why wouldn't you just have the other machine log in (on port 587) as a user would? i.e. Giving it a username & password. That's how I've always configured outbound mail in my websites anyway. |
|
Doing it this way couples the two machines less closely. It means that every source of email on the www host (Wordpress/other web apps/cron outputs) can just submit to the www host's Postfix server and then forget about things - no need to configure each email source with user/pass/host details. It also has the benefit that the mailinabox being offline - for 2 minutes or 2 days - is not a problem - the www host's Postfix installation will take care of getting them from its queue to mailinabox. Having e.g. Wordpress talk directly to the remote mailinabox would mean users would get errors or miss emails if the mailinabox is down when e.g. Wordpress tries to send email. Unless I've missed your point entirely and you are not questioning the use of a local Postfix smarthost, just the use of TLS certs instead of passwords... If so, my preference for certificates is that I find things easier to reason about with separate authentication mechanisms for humans and machines. If I had the Postfix smarthost authenticate with a user/pass, it would have to use my own user/pass (as I've only defined the one account, just with a bunch of aliases). I'd rather not have that password (hashed or not) sitting around on the www server. And the server doesn't have to worry about forgetting a password or the time it takes to type, so there's no reason I see not to use keys. |
|
I hadn't thought about the case of the server being off-line. That makes sense. I understand the decoupling aspect. The part I'm questioning was really certs vs username/password. It doesn't have to be yours -- you can make a new username/password pair for every peer host that you want to authenticate. (There's even an API.) It's essentially the same overhead as (or easier than) creating a new certificate. I am trying hard to avoid adding complexity to this project. |
|
I other reason I neglected to make explicit earlier was that I has assumed that the mailinabox configuration rejects email submission from an authenticated user if the MAIL FROM is not their main address or an alias they receive for. Assuming that to be the case, user/pass authentication would be problematic for sibling hosts - for example, I might have my own personal account receive for the alias root@siblinthost.tld, but that sibling host might send email as root@siblinghost.tld (e.g. cron output). The mailinabox would reject submission of such emails because the sibling host's account wouldn't "own" that alias. I briefly dug into Postfix/Dovecot docs and the mailinabox scripts and what I've read so far makes me think that mailinabox doesn't actually check MAIL FROM against the user's main address and aliases. If so, do you see this as a problem? If so, should I open an issue for it? For a small installation with only a single user or a small number of trustworthy users it might be OK but I imagine spoofing could be an issue with larger installations. A few docs:
|
|
Preventing spoofing is a whole can of worms. I'm not really worried about this sort of spoofing for now. Also it would also prevent you from using the machine the way you want with username/password. And I want to close this issue, so that means not fixing the spoofing problem! |
|
Would you mind if I did open an issue for preventing this sort of spoofing but assigned it to the M3 security milestone? (The fact it would stop relaying for machines is a non-issue for me, I'm running with TLS auth from my fork and will maintain it for myself). |
|
Sure. |
|
Great. It's #217. I can't see any obvious way of assigning it to M3 so I'm guessing only you can do that. |
The use case for this is e.g. a www server that is a separate machine to
the mailinabox, but which needs to send emails to the internet - for example it
may be running Wordpress or some other web app and need to notify arbitrary
users of comments etc.
In such cases, as the www administrator is using mailinabox, they're almost
certainly better off letting mailinabox do as much as possible as far as email
is concerned (as opposed to having the www sibling host do full delivery
itself) - among other things this simplifies reasoning about DNS records.
If this change (with any necessary tweaks) can be accepted I might later have
a go at adding relayer key administration to the web control panel.