#haraka

morning

morning

afternoon

hey, how can I setup Haraka to proxy/relay everything to other SMTP server? I have an issue that the other SMTP server accepts emails whereas Haraka gives "[core] S: 550 No MX for your FROM address". How can I use Haraka in middle so that it wouldn't give this error?

zma: remove the mail_from.is_resolvable plugin from config/plugins if you don't want it to run.

_smf_: thanks a log!

lot

btw, after each succesful email I get lot of spam like this:

[DEBUG] [-] [core] [smtp_client_pool] [25:10.65.140.65:300] availableObjects.length=1

is it all ok?

zma: that's just the connection pool logging - if you don't want to see it change your loglevel - echo LOGNOTICE > /path/to/haraka/dir/config/loglevel

_smf_: logging doesn't matter, as long as it's not indication of problem or keep connecting to IP mentioned unnecessarily

zma: it's not indicating a problem - it's DEBUG logging showing the connection pool details that the smtp_proxy plugin uses. Understand that if you use smtp_proxy, then Haraka will connect to your backend SMTP server for each connection from the MAIL command onwards.

_smf_: thanks for clarification. My use case is just to have it as gateway between two networks, so we can have firewall config to only allow smtp traffic through that, so Haraka can be as dummy as possible for proxying/delivery purposes.

having said that, it works with current config now, but it may do things that it wouldn't have to atm

ultimatt: hi. have you seen my email regarding rcp_to.qmail ?

ultimatt: you around>

I started to get "[WARN] [32132F33-44B7-4C99-91D5-9723A04D7EFE] [core] client [10.236.236.87] connection timed out"

what's the right setting to increase client timeouts?

zma: the default is 300 or 600 seconds. That should be ample.

See docs/CoreConfig.md for the settings to increase it. But I'd be wondering why you have an internal client wanting to keep the connection open for that long.

_smf_: yes, it's internal. It's possible that sender has strict iptables rules.

What's iptables got to do with it unless it's filtering out the FIN packets.

e.g. it's too strict and Haraka isn't therefore seeing the connection end.

_smf_: I don't know, I'm speculating. Any other direction to look at would be welcome too.

No idea really - I don't know your architecture or what 10.236.236.87 is or what it's running.

If the connection timeouts aren't causing you an issue - you could probably ignore them.

_smf_: it's running our custom python based application that is supposed to send email notifications, that we would route through Haraka to main smtp server

I don't know if the client is responsible to somehow close the connection, and it's something on implementation detail

Why do you need Haraka for that? I'd be looking at the python code to make sure it's sending a QUIT at the end of the session and terminating the connection.

I think that QUIT maybe something that is missing, will look into it. But we do know that if connected directly to main SMTP (M$ something), it does work

but "working" is a relative term, it may be false positive as some other solutions are not as strict about, having QUIT

but I'll re-test based on this info and verify

It would be unusual for Haraka not to detect if the remote client 'hangs up'. So a connection timeout would mean that the remote client is keeping the connection open.

_smf_: thanks, we found missing quit on smtplib use, which is probably the root cause