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.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
