#36 Different auth-credentials 2.0

[Leona]

Hello Walker!
I kindly ask your for help.
I've found an issue using the "split:" filter together with the "mx:" client filter.

a. When the message is splitted by domains, only the first envelope gets the IP address in the "ForwardToAddress:" field.
b. Only the message that has the IP address on that field is processed, even though without it, they might go through the "--forward-to" smarthost.
c. All above happens without running any other filter but "--client-filter=mx: --filter=split:"
d. Also, using an additional filter to populate the ClientAccountSelector field, only writes to the first envelope as well. Probably because I need a foreach on the splitgroup messages, but I don't how to do it in the pipeline.

This is the config I am running:

--server-auth=C:\ProgramData\e-mailrelay\EmailRelay.auth --remote-clients --client-tls --close-stderr --forward-on-disconnect --forward-to-some --forward-to=smtp.office365.com:25 --log --log-address --log-file=C:\ProgramData\e-mailrelay\EmailRelay-log-%%d.txt --log-time --pid-file=C:\ProgramData\e-mailrelay\EmailRelay.pid --spool-dir="d:\spool\in" --verbose --port=588 --client-auth="C:\ProgramData\e-mailrelay\EmailRelay" --filter=@app/emailrelay-selector.js --filter=split: --client-filter=mx:1.1.1.1

PS: Find attached the Clientaccountselector script.

[Graeme Walker]

Hi Leona. (a) The ForwardToAddress is never populated by the split filter; it sets ForwardTo. (b) If you can see a ForwardToAddress then I think it must have come from the mx client filter when there was a failed forwarding attempt.

(d) The split filter spits out zero or more copies of the current message, but only the original is processed by other server-side filters. That means that the ordering of the filters on the command-line is significant and you should have the split filter last -- which you do. Can you confirm that your script runs before the built-in split filter? Try using "--verbose" twice to get a bit more logging.

[Graeme Walker]

I think there is a problem with the command-line option ordering not being preserved. That would explain what you are seeing (TBC) in your tests, with the split filter running before the filter script.

[Leona]

Hi Walker
Increasing the verbosity of the logging was the key to finding the solution.
I have a problem with the local name server and because of that, I was pointing the mx filter to a public dns without specifying the port, which causes a failover to the local dns.
As the issue described before happens also using only the split and mx filters, I was mislead to believe that it was something caused by the split/mx processing, also because I could see the resolved IP of the destination domain in the envelope, before the message is processed, only for the first one by chance.
In the end adding the port "--client-filter=mx:1.1.1.1:43" fixed the issue.

I have only one doubt left, if the destination could not be resolved by the mx filter, shouldn't it failover to the "--forward-to" smarthost?

Your help is always much appreciate. Thank you very much.

[Graeme Walker]

I'm glad you sorted that out. I panicked myself thinking there might be a bug with respect to ordering the filters because the code uses std::multimap, but std::multimap has guaranteed ordering of values with the same key since c++ 2011.

Clearly there should be at least a warning if you give a network address without a port number.

I don't think the ForwardToAddress should default to the "--forward-to" address just because of a DNS error. You might have a filter that sets the ForwardTo domain and the ClientAccountSelector in tandem, so having the ForwardToAddress default without changing the client account might be a security lapse.