> > 1) does the milter API and its placement in the server's execution provide
> > a
>
> > place where I can determine that STARTTLS has failed?
>
> No. Milter processing happens as mail enters the queue, delivery and STARTTLS
> success or failure happen when mail is leaving the queue.
>
> > (and where I can manually redirect the message and remove it from normal
> > processing) (milter against the STARTTLS command?)
>
> Milters process mail being received, not mail going out.
DUH!!! I'm so embarrassed. Got caught thinking too much without realizing
this
simple fact. Sorry about that and thank you for pointing it out.
> > 2) does anyone know of a milter that might serve as a good example so I
>don't
>
> > have to start from scratch?
>
> Outgoing TLS policy failure is a non-milter problem. If you want traffic
> that fails mandatory TLS delivery to be re-routed for alternative processing,
> you can use a custom transport for mandatory tls:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> transport_maps = ${indexed}transport
>
> transport:
> example.com tlssmtp
>
> master.cf:
> tlssmtp unix - - n - - smtp
> -o smtp_tls_security_level=encrypt
> -o smtp_fallback_relay=[127.0.0.1]:12345
>
> Note that not all failures will be starttls failures, so the fallback
> relay will also receive mail when the remote peer is down, or tempfails
> a particular recipient, ...
THANK YOU, Viktor, for the good tip. I think that smtp_fallback_relay was the
setting that I didn't know about. That's perfect (although it's NOT perfect as
you rightly note... sadly, the boss types don't care even if they understand
all
the caveats... frustrating!). THANK YOU again!!!!
