On 09/26/12 12:50, Gilles Chehade wrote:
On Wed, Sep 26, 2012 at 11:20:31AM +0200, Alexander Hall wrote:
Hi!
Hi,
When setting up your first host or hosts to use smtpd it is
inevitable to make some mistakes here and there, which e.g. could
cause delivery attempts of an email to the wrong host ("relay via
boo.hoo").
Now, that is obviously not a problem per se, but after fixing the
config, I cannot seem to "re-evaluate" those entries, causing them
to be forever locked in the queue. So far, I've ended up manually
editing the envelopes and fixing the issues I've found.
Is this expected or unexpected behaviour? Maybe some rfc even
mandate that routing decision should be taken on first arrival, and
may not change later?
This is an expected behaviour.
I'll expand on that since this has been discussed a few times in private and
I think it's worth being referenced in list archives ;-)
First of all, to clarify the situation, OpenSMTPD does cope with changes and
will dynamically lookup hosts, routes, MX, etc ...
The re-evaluation thing has to do with a very specific case: what should the
daemon do when a configuration changes in a way that a relay node has become
a destination node, or the way around.
There is no way to handle re-evaluation in a way that removes all ambiguity,
and there is no way to do it reliably. Re-evaluation can lead to lost mails:
rejecting mail that had been acknowledged as accepted, not notifying sender,
not sending to all recipients expanded from an alias, etc, etc ... There can
be no correct answer to the following questions:
- do we process aliases if a relayed mail is now local ?
- how can we ensure the original sender gets notified if we now reject ?
- do we cancel all previously expanded aliases if we no longer expand ?
- do we do it if we switched from a local node to a relay ?
There are tons of questions like these where there is no valid answer.
Re-evaluation is complex, it will add a lot of code to make OpenSMTPD smart,
behind the admins backs, and we know in advance that it cannot be done right
because what re-evaluation tries to fix is an admin issue not something that
can be fixed with code.
Currently OpenSMTPD provides a predictable behavior: mails are handled using
the decision that was taken when they were committed to queue. If you change
the configuration in a way that's compatible, no worries. Otherwise, it will
not work around the admin fuckup and will probably bounce but at least there
will be not undefined behaviour, someone will get notified and we'll be able
to explain exactly what has happened despite the configuration change.
That being said, what I'm against is OpenSMTPD trying to take smart decision
by itself. I have plans in the future to extend smtpctl so that an admin can
fix the aftermaths of a config fuckup *manually* ;-)
Yeah this all makes sense. Thanks for the thorough explanation.
/Alexander
