Running 2.3.4 but still got "unable to resolve MX record"

[Stefan Heinrichsen]

Hi all,

I’m currently running Version 2.3.4 FREE # 1507 and regularly face MX resolving issues when try to send mails to external servers. This affected e.g. @gmail.com and other big domains which are setup correctly for sure.

If I go into the container and use nslookup to resolve MX records it works as expected. A failed message can be see here:

https://pastebin.com/xvnQKw94 (I placed REDACTED as some Names and UserIDs)

I’m not sure how to further text/debug the MX resolution process of haraka.

Any hints? I’m totally willing to provide further help/logs/etc if I get a rough direction where to search.

Best regards,
Stefan

[SH]

From: REDACTED <[e-mail]>
To:REDACTED <[e-mail]>
Cc: REDACTED<[e-mail]>
Subject: REDACTED
Organization: UN-Hack-Bar e.V.
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

I am not sure I follow - there is no gmail in headers. Are you authenticated to send messages or are you using some custom whitelist/routing/settings. At /log/delivery/*-total you will find UUID of connection/transaction/delivery and than con/tx/del folders which contain a lot of debug info by UUID

[Stefan Heinrichsen]

I’m sorry, I was unclear. We are using some alias setup and “Copy on Receive” filters. So mails going to info@.. are forwarded to three mail addresses on our server and those are then aliases/forwards to external mail accounts (here the gmail.com address comes in) and to one archive@ mailbox on our server. So it looks like

[e-mail] → redirect to “[e-mail]”, “[e-mail]”, “[e-mail]” and “[e-mail]”.
From there on [e-mail] has a redirect to “private@gmail..com”, user2 for another destination address etc. Only the somelocalmailbox is hostet on our server.

I can see the message I uploaded at pastebin is queued but was not possible to deliver at the end with the “Status: 5.1.2 (550 Tried all MXs gmail.com)”. I think I need to figure out why the server could not work the MX (was it not possible to resolve? was it not possible to connect? something else?).

What really puzzels me: Sometimes it is working but sometimes mails are queued and then we get the failure with “Tried all MX”

[Stefan Heinrichsen]

OK, now I got closer after getting your hint to work with the UUIDs… I see this in the “del” area of the logs for a testmail:

2021-10-07T11:06:51.350Z [1] [INFO] [outbound] hook=get_mx plugin=queue/lmtp function=hook_get_mx params=gmail.com retval=OK msg="[object Object]"
2021-10-07T11:06:51.350Z [1] [DEBUG] [outbound] Got a MX from Plugin: gmail.com => 0 {"using_lmtp":true,"priority":0,"exchange":"127.0.0.1","port":24}
2021-10-07T11:06:51.350Z [1] [INFO] [outbound] Attempting to deliver to: 127.0.0.1:24 using LMTP (0) (5)
2021-10-07T11:06:51.352Z [1] [DEBUG] [outbound] running deferred hooks
2021-10-07T11:06:51.352Z [1] [DEBUG] [outbound] running deferred hook in log plugin
2021-10-07T11:06:51.409Z [1] [DEBUG] [outbound] hook=deferred plugin=log function=hook_deferred params="" retval=CONT msg=""
2021-10-07T11:06:51.410Z [1] [INFO] [outbound] Temp failing 1633604811339_1633604811339_0_914_qz7KFz_22_mail.un-hack-bar.de for 64 seconds: Tried all MXs

But why did the MX for gmail.com resolve to 127.0.0.1??! Of course this will not work…

[SH]

I see, yep it seems like bug. I’ll try to simulate that. It happens mostly when transaction is not marked as relay-able and Haraka tries to push it through lmtp as it has no other option to do outbound

• info@ is alias or proper mailbox with sieve redirect?
• user1@ is alias or proper mailbox with sieve redirect?

‌

[Stefan Heinrichsen]

Well thats kind of a relieve that I’m maybe not to stupid to find the error in our “normal” mail setup.

info@ is a an alias/redirect
user1@ is a mailbox with a sieve rule (copy to external but keep a local copy too)

[Stefan Heinrichsen]

I have some more input on this case:

I’m using my private mail hoster “posteo.de” for handling mails. If I send mail with from: field as “[e-mail]” to “info@un-hack-bar,de” all works fine. BUT: If I send the same via my mail hoster and use their identify function to set from: to “[e-mail]” the mail gets into the queue and get stuck.

Of course the SPF record is correctly defined to include posteo.de as a valid source for sending mail for domain @un-hack-bar.de

[SH]

So if I understand correctly you also use “default SMTP route” to route all your emails to posteo?

[Stefan Heinrichsen]

My comment regarding posteo was more an addtional detail. Somehow it seems important what the “From:” Address of a sent mail ist. We don’t use any smarthost or similar if you mean this with “default SMTP route”. We use the default setup where poste.io acts as a real SMTP server and does the whole delivery on its own by contacting the destination SMTP Servers directly.

[SH]

I've run following scenario:

[e-mail] (external) -> [e-mail] (alias) -> [e-mail] (sieve red.) -> [e-mail]
                                                            -> [e-mail]
                                                            -> [e-mail]

Everything worked OK and email was delivered. I am still missing something which does your configuration different.

I need all three logs (con & tx & del) at once from last part with gmail.com delivery.

[Stefan Heinrichsen]

Sorry, I was offline yesterday. As the above logs are kind of gone by now I created new ones which are a simple as possoble (so no mix of mailboxes and aliases and distribution to several users etc.). For both testmails I used [e-mail] as receiver. This is a alias which forwards to @gmail..com

UUID “E07E5A42-F29E-4884-8740-D9C2FA1CA2B0” was send from my mailprovider posteo.de with my regular email ([e-mail]). This one got delivered as expected.

UUID “34F4E35E-5832-4D60-ACED-AEEF57948B16” was send also from my mailprovider posteo.de with a “spoofed” mailadress “[e-mail]”. This one was not delviered.

You can download the log files here.

If useful I most probably could also arrage a ssh account within the docker container.

[SH]

Aha! I see!

-> EHLO mout01.posteo.de
-> MAIL FROM:[e-mail]

Problem is that in this case posteo.de use envelope “MAIL FROM” with domain which is at mailserver without any authentication and thus not triggering “relaying” flag. What is the reason for that? I can easily fix it but I want to know exact usecase since any manipulation with relaying flag can be quite dangerous.

[Stefan Heinrichsen]

In my specifc use case it is just because I handle all my mails at one provider and the poste.io is main for forwarding my mails with the right domain name to my private mailbox. I don’t use any mail clients but always use this posteo.de service. But still I want to be able to send mails from our “official” domain from my private mail hoster. Pretty similiar for many other of our users.

I guess this risk here is to generate some kind of spam-mailservice if this handled wrongly? Where can I see those relaying rules? Anything I can do locally so you don’t have to change some default behaviour of poste.io?

[SH]

eliminate lmtp queue hook and process directly without side efects ref #895

→ <<cset 88de952fcd2b>>