On Jun 23, 2005, at 4:56 AM, Philip Hazel wrote:
> EITHER remove Exim's memory of this
That's what I was looking to do.
> Sledgehammer: just delete /var/spool/exim/db/* That removes all
> memory.
ugh... looks bad
> Scalpel: learn to use the exim-fixdb utility to remove just the
> relevant data records. Like learning to use a real
> scalpel, needs a bit of training. :-)
not much training though -- did the exact job i needed
> Set delay_after_cutoff=false in the SMTP transport (see the URL above).
I had previously tried that -- no luck. I think it could have been
because it was the main mail server to one of our biggest clients, that
hosted 10 of their domains and probably 40+ addresses that we had been
trying to message for over a week.
>> That struck me as odd -- shouldn't i get a
>> 220 TLS go ahead
>> off of that response?
> Only if the host is working correctly. :-)
That's what i thought -- their sysadmins didn't seem to know what they
were doing and just broke the mailserver when they upgraded.
Thanks for the heads up on tls_avoid_hosts -- i had never seen that
option before.
