Groan! So near, yet so far!
I've refactored my routers and transports so that I now have:
- two transports; one that does DKIM signing, and one that doesn't
- my routers now do the hairy string expansion to decide which transport
to assign
When selecting a transport the routers:
- if the connection is authenticated, or the client host is on-campus,
it does a lookup in a data file to see if the domain of the RFC5322.From
address is listed and, if it is, selects the remote_smtp_dkim_enabled
transport
- else the remote_smtp transport (without DKIM) is selected
Unfortunately it looks like the value of the RFC5322.From (in $h_from)
isn't available at routing time, although it is when the transport later
runs.
I need to use the domain of the RFC5322.From address as we're working
towards a strict DMARC policy, which wants the domain of the DKIM signature
to align with the RFC5322.From address. So it makes sense to base my
sign/don't sign decision on that address.
I'm scratching my head here, but am stumped how to solve this. Anyone got
any bright ideas?
Cheers,
Mike B-)
On 21 November 2016 at 14:55, Mike Brudenell <mike.brudenell@???>
wrote:
> Hi, Jeremy -
>
> On 21 November 2016 at 14:47, Jeremy Harris <jgh@???> wrote:
>
>> On 21/11/16 14:25, Mike Brudenell wrote:
>> > *Question 1:* I suspect that in 4.86 assigning the empty string to
>> > dkim_domain will cancel cutthrough, but if I were to upgrade to 4.88 it
>> > wouldn't. Am I right in thinking this?
>>
>> Yup
>>
>
> Many thanks for the confirmation; I wanted to be sure I wasn't missing
> something.
>
>
> > *Question 2:* Assuming I'm right, is there some way of changing my string
>> > expansion to leave dkim_domain unset?
>>
>> > Is there a sneaky way of doing this?
>>
>> move the expansion that gives do/don't dkim into the router(s) and use
>> it to select one of two transports, noting that the router "transport"
>> option is expanded before use.
>>
>
> That's sort of what I used to have, although I did the lookup within the
> transport. But as you note, I should be able to cunningly move the lookup
> out to the router as well and so decide which transport to invoke.
>
> Many thanks!
> Mike B-)
>
> --
> Systems Administrator & Change Manager
> IT Services, University of York, Heslington, York YO10 5DD, UK
> Tel: +44-(0)1904-323811
>
> Web: www.york.ac.uk/it-services
> Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
>
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
