-
-
Notifications
You must be signed in to change notification settings - Fork 660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(localhost-loop): fix outbound loop when target mx is localhost #2952
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would wrap this in some sort of config too, something like cfg.local_mx_ok (which will disable this check, i.e. outbound to local IPs is disabled by default, as per this patch), and add it to booleans in outbound/config.js, and don't forget the docs.
I'm not sure this is the right default. There are plenty of use cases where a MTA accepts mail and then delivers it to localhost on another port. |
Sure but I guess my opinion is that, that is the rare scenario for people who know what they are doing. If we add a flag to it we have to pick a default and default safe seems best.
… On Jun 15, 2021, at 6:50 PM, Matt Simerson ***@***.***> wrote:
I'm not sure this is the right default. There are plenty of use cases where a MTA accepts mail and then delivers it to localhost on another port.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks for the feedback. Here's an attempt at a config param as suggested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -33,8 +35,10 @@ exports.lookup_mx = function lookup_mx (domain, cb) { | |||
} | |||
else if (addresses && addresses.length) { | |||
for (let i=0,l=addresses.length; i < l; i++) { | |||
const mx = wrap_mx(addresses[i]); | |||
mxs.push(mx); | |||
if (obc.cfg.local_mx_ok || !net_utils.is_local_ip(addresses[i].exchange)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for being late to the party but addresses[i].exchange gives me hostname not IP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback @analogic.
I just tested it and you're right, I get the hostname too, whereas net_utils.is_local_ip
seems to expect an ip.
The change solves #2809 anyway because (from what I understand) the issue was addressing cases where the MX record was returning a local IP (not a hostname), such as with domain yeah.com:
$ dig MX yeah.com
...
yeah.com. 534 IN MX 1000 0.0.0.0.
...
In that case addresses = [ { exchange: '0.0.0.0', priority: 1000 } ]
and the fix does work.
The fix would fail for an MX record returning a hostname resolving to a local ip. Is this a legitimate use case? If yes, perhaps we could use net_utils.get_ips_by_host
[source] to resolve addresses[i].exchange
to an ip? I'm wondering if this can badly impact performance though. I'm not knowledgeable enough on Haraka to evaluate this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use net.isIP
to define if .exchange is an IP or not. When its not an IP, using net_utils.get_ips_by_host
to resolve should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made two PRs as a fix attempt:
Fixes #2809
Changes proposed in this pull request:
Checklist: