Re: [exim] TLS error on connection to smtp.office365.com (g…

I think the domain refers to the ultimate destination of the message, and so it is not what I want.
More specifically, my router has
smarthost:
debug_print = "R: smarthost for $local_part@$domain"
driver = manualroute
domains = ! +local_domains
senders = +rb_ucsf
transport = remote_smtp_smarthost
route_list = * DCsmarthost byname
# RB adds next line to avoid trying IPv6 addresses, which are unrouteable
ignore_target_hosts = <; 0::0/0
host_find_failed = ignore
same_domain_copy_routing = yes
no_more
and it's the value of DCsmarthost (a macro) that I want when I'm in the transport or the authenticator, rather than the name it resolves to after all the lookups. It seems a much more natural value to use in passwd.client.

What's the procedure for an RFE?

Ross

P.S. Sorry, Outlook on the web kind of forces top-posting.
________________________________________
From: Exim-users <exim-users-bounces+ross.boylan=ucsf.edu@???> on behalf of Jeremy Harris <jgh@???>
Sent: Sunday, April 30, 2017 3:36 AM
To: exim users
Subject: Re: [exim] TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.

On 29/04/17 21:11, Boylan, Ross wrote:
> remote_smtp_smarthost:

> I would like to check my understanding of what $host means in this context, as well as in the context of the authenticators

It'll be whatever the MX and A, and any CNAME, DNS lookups ended up
with.

> Is there an easy way for the transport and authenticator to access the original host name used by the router?

Original? The lookup sequence starts with $domain (not a host name at
all). Is that what you're looking for


> Finally, is there a way to get what the configuration is *after* all the macro processing?

No. An RFE wouldn't be unreasonable (if implemented it would need to be
restricted to admins though).

You can view single macro values (as an admin)
using "exim -bP macro <MACRONAME>".