Relay

[msimerson]

unified relay plugin.

Includes all features of existing relay plugins with better docs, tests, and automatically config file loading after changes.

[baudehlo]

I think we need to have a deeper conversation about Haraka allowing relaying by IP address.

It leaves us wide open to mail loops. And those are yuck.

I did have an idea that we could use a unique ID (server UUID?) in the EHLO line that is passed in outbound.js, and checked in connection.js. I'm sure there's flaws in that idea.

This brings to the thoughts we were having 2 weeks ago (?) about splitting transactions and I re-remembered why we don't support that - because it's not safe. Mail is supposed to be reliable, but Haraka does everything at SMTP time. If you split the transaction you drop reliability. e.g. rcpt1@domain1, rcpt2@domain2, split the transaction and queue the first, it succeeds, queue the second, if it fails we have no support for sending a bounce (required). Perhaps we could add all the infrastructure for that, but I mostly want to keep things simple. Other SMTP servers get around this by splitting transactions AFTER the final-dot (i.e. after the transaction is closed), and the transaction has been reliably queued to disk.

Any thoughts?

[baudehlo]

Also note #151 is an attempt to filter out local addresses from outbound sending. So it might be worth cleaning up and applying.

[msimerson]

My first thought is that this PR doesn't add or even change Haraka relaying. It just consolidates all the relaying features into one place, making it easier to find the docs and grok the available options.

My second thought is, hasn't mail looping problems already been solved by mail servers?
qmail: This message is looping: it already has my Delivered-To line. (#5.4.6)
postfix: .... status=bounced (mail for mail.example.com loops back to myself)

Matt

[baudehlo]

Yes it's not directly related to this plugin. I should have probably opened a different issue to discuss it.

I think we check for received header counts (same as qmail) for mail loops, but it'd be much nicer to be able to do it on the first loop not the Nth (I think 100 in qmail's case!). Also the more important issue is the reason we can't split transactions, but we should probably discuss it in a new issue.

[msimerson]

I readily admit I may not be thinking clearly enough about the problem right now but it seems that any "solution" is going to involve designating every transaction with a "local / remote" that is more definitive than connection.relaying.

[baudehlo]

Moving this discussion to #573

On Sun, May 11, 2014 at 9:33 PM, Matt Simerson [email protected]:

I readily admit I may not be thinking clearly enough about the problem
right now but it seems that any "solution" is going to involve designating
every transaction with a "local / remote" that is more definitive than
connection.relaying.

—
Reply to this email directly or view it on GitHubhttps://github.com/baudehlo/Haraka/pull/541#issuecomment-42789980
.