Outbound: treat mails to local domains with connection.relaying set to true as local mails...

[abhas]

Currently what's happenning is that the outbound plugin considers any mail that has connection.relaying set to true as an outgoing mail - even if the mail is destined to a local domain.

I discovered this while trying to debug LMTP deliveries with dovecot while sending a mail from a client using authentication. LMTP would just not get called if I authenticated to send mail. However, if I disabled SMTP AUTH in my client, then LMTP deliveries would happen just fine.

[abhas]

I would like to add that qmail behaves exactly like this. Irrespective of whether you authenticate or not, mails addressed to any domain in control/locals are treated as local mails and remote (outbound) deliveries are not attempted for them.

[baudehlo]

Right but Haraka will split the mail up, send the local mail to itself using the MX record and the remote mail to wherever. So it ends up working, just a tiny bit more overhead.

On Feb 17, 2014, at 1:57 PM, Abhas Abhinav notifications@github.com wrote:

Currently what's happenning is that the outbound plugin considers any mail that has connection.relaying set to true as an outgoing mail - even if the mail is destined to a local domain.

I discovered this while trying to debug LMTP deliveries with dovecot while sending a mail from a client using authentication. LMTP would just not get called if I authenticated to send mail. However, if I disabled SMTP AUTH in my client, then LMTP deliveries would happen just fine.

— Reply to this email directly or view it on GitHub.

[abhas]

The problem will still happen in two cases:

1) Haraka is running on a local IP behind the firewall and so when it queries the MX and receives a public IP for the MX, it tries to connect and fails (because the firewall only forwards the public IP to the LAN IP from the WAN).

2) Haraka is not the real MX for the domain -- it is, say, a satellite server that is configured to receive emails for a domain through another front-facing MX. (ie. the front-facing MX receives the mail and then forwards it to Haraka...) So if Haraka were to send it back to the front-facing MX that would be an extra email hop for the email.

[baudehlo]

Case 1 makes no sense. If you're using Haraka for outbound it needs to be able to connect to mail servers. Firewalling off your own MX server but leaving the rest of the world open would be a very odd thing to do.

In case 2 the mail still gets there so im not going to worry about an extra hop.

On Feb 17, 2014, at 4:19 PM, Abhas Abhinav notifications@github.com wrote:

The problem will still happen in two cases:

1) Haraka is running on a local IP behind the firewall and so when it queries the MX and receives a public IP for the MX, it tries to connect and fails (because the firewall only forwards the public IP to the LAN IP from the WAN).

2) Haraka is not the real MX for the domain -- it is, say, a satellite server that is configured to receive emails for a domain through another front-facing MX. (ie. the front-facing MX receives the mail and then forwards it to Haraka...) So if Haraka were to send it back to the front-facing MX that would be an extra email hop for the email.

— Reply to this email directly or view it on GitHub.

[smfreegard]

This is how I'm using LMTP here - but I route all mail via outbound.

var outbound = require('./outbound');
var hostname = require('os').hostname().toLowerCase();

exports.hook_queue = exports.hook_queue_outbound = function (next, connection) {
    var transaction = connection.transaction;
    outbound.send_email(connection.transaction, next);
}

exports.hook_get_mx = function (next, hmail, domain) {
    var plugin = this;

    // Check for local host name
    if (domain.toLowerCase() === hostname) {
        hmail.logdebug(plugin, 'message to local host');
        var mx = {
            priority: 0,
            exchange: '127.0.0.1',
            port: 24,
            using_lmtp: true
        };
        return next(OK, mx);
    }
    // No match - use MX lookup
    return next();
}

[smfreegard]

@abhas - see https://gist.github.com/smfreegard/d23fab2363c78f436508 for an alternative to the stock queue/lmtp plugin; this version will allow the connection.relaying case work correctly if you specify the inbound domains in lmtp.ini in their own section e.g.

[inbound-domain.com]
;host = optional host defaults to 127.0.0.1 if not specified
;port = optional port defaults to 24 if not specific

This basically means you're having to specify the inbound domains twice, once here and once in host_list or host_list_regex (or rolling your own hook_rcpt plugin that uses this list).

[abhas]

@smfreegard Thanks a lot for this gist. It works as expected. Meanwhile, I had actually used the plugin snippet that you'd posted.

Now what I'm going to do is read the contents of host_list from within your lmtp.js plugin so that I only have to add the domain to one file.

[smfreegard]

@abhas - can you try https://github.com/baudehlo/Haraka/pull/475 ??

baudehlo and I discussed this on IRC last night and this is what we came up with. The changes mean that you will not have to run a modified queue/lmtp plugin now as it will automatically know which domains are considered 'inbound' and will route them to LMTP accordingly.

[smfreegard]

BTW - the reason I'm asking you to try this is because I can't easily test this here, so it would be most appreciated.

[abhas]

Sure Steve. I'll test this and tell you how it works out.

[baudehlo]

Any update on this?

[abhas]

@smfreegard I tried out #475. Sorry for taking so long to do that and get back to you.

• The ok_domains approach works fine in the case of LMTP.
• For some reason, in my case, the retval passed to the rcpt_respond is 906 and not 900 (which is what constants.ok seems to resolve to). In fact, if I don't authenticate to relay the email, it is 900 but if I authenticate (the case that we're trying to find a solution for here), then retval is 906 for me. So if I remove the if comparison it works as expected for me. It took me quite a while to debug this because it wouldn't just work for me unless I remove the if statement.

However, I think is a very special case for LMTP. The problem remains unsolved for queue/qmail-queue and so I think, a similar logic needs to be applied for all queue plugins in a general manner. Or maybe outbound should handle this.

I had a question here -- though this code is in lmtp.js the actual delivery is done by the outbound plugin; at least that's what the logs say. So is queuing and delivery handled by outbound and not the various queue plugins?

[baudehlo]

This has been fixed by adding the option enable_outbound to smtp_forward and proxy. Closing.