On 11/28/14 17:04, Gilles Chehade wrote:
On Thu, Nov 27, 2014 at 10:00:19PM -0500, Hugo Villeneuve wrote:
On Fri, Nov 28, 2014 at 01:31:53AM +0100, Alexander Hall wrote:
Hi,
I noticed a box of mine having had a misconfigured mail relay, resulting
in lots of mail queuing up. Now, after fixing the configuration, new
mail are properly sent.
However, it seems the invalid 'mta-relay' setting, as seen in the
envelopes of the queued mail does not get revised while issuing 'smtpctl
schedule ...'. Thus, the old mail stays in the queue.
I saw that too while configuring my first smtpd attempt (5.6-stable/sparc).
It made me realize that smtpd is still a young MTA.
Any pointers on how to proceed is appreciated, possibly including
cluesticks as of why the observed behaviour might be the proper one.
No, it is not proper behavior. As a store and forward system with
potentially 4-5 days between submission and delivery, any MTA needs
to be able to adapt in configuration changes across a long period.
So, because a MTA configuration may change across a long period of time
and that during these changes sometimes someone will decide that a mail
that used to be ok to relay no longer is or should no longer be relayed
the same way, you're advocating that we should add logic to the MTA for
taking guesses at what it should do and adapt to all possible changes ?
If a configuration change means that no envelopes is routable anymore,
should the software decide to adapt and trash the entire queue without
an admin intervention ? are you comfortable with that ?
If the admin is already changing the config, doesn't it make more sense
that ... (s)he decides what to do with envelopes that are affected by
these changes ?
I haven't tested the HEAD release yet and didn't found anything in
smptd and smtpctl manual page how to fix it in stable.
My guess is that you will have to resubmit them. Parse "smtpctl
show queue" output, pick field 1,5,6 and then refeed the output of
"smtpctl show message field1" to "sendmail -f field5 -- field6" for
each line. Then delete the stuck ones. (Yeah test that first.)
Good luck.
Hopefully it will get fixed.
As I wrote in the other mail, I think the proper fix is to provide admin
the right tool.
Indeed, that makes sense. Even just re-injecting the mails might fix it,
but then they arrive from localhost rather than from the original
source, so they might be routed differently than they would in the first
place...
I ended up w/ ~
# mailq | cut | xargs perl -pi
Email is hard, let's go shopping. :)
/Alexander
