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. > > Any pointers on how to proceed is appreciated, possibly including cluesticks > as of why the observed behaviour might be the proper one. >
The observed behaviour may not be the proper one, but at some point we had to take a decision as to how smart the daemon should try to be: You send a mail, OpenSMTPD accepts it and tells you it will take care of it. Now, you change the ruleset, how far should OpenSMTPD go to determine itself what needs to be changed ? Are aliases it expanded still valid, should they be reprocessed or removed ? If reprocessed, we may end up sending mail to people who originally were not meant to receive it, if removed we may end up deleting mail that some people were meant to receive. How do we decide what is the right behaviour ? If a mail that was accepted would be discarded now, do you still send it, or do you trash it despite the fact you acknowledge you would send it before ? There are many other cases, such as local deliveries turning into relaying, or the opposite, which lead to funky situations where there's no way we can figure out how to "automagically" fix the envelopes. So from there, we have two paths: 1- we consider that an envelope is processed according to the rule it has matched when it was accepted; 2- we reevaluate the rules every time we process an envelope and we try to guess what most people expect in every possible combination of a config change ... I can tell you right away that last time we discussed this, we couldn't even get 3 people to agree on the action to take in one of the simplest case ... I prefer 1- because: a- changing your config in incompatible ways that cause an envelope to no longer be routable is not something you do on a regular basis, and the clusterfuck kludge required to add smartness to cope with these few times will be a pain for everyone for very small arguable gain. b- if you change your config and it leads to a situation where smtpd is no longer able to route an envelope, then it's probably up to the admin and not the software to decide if/how the envelope should be dealt with. some admins will want mails to be routed, others will not, there's no way for the software to automatically decide what the correct answer is. c- no matter what changes you make, the behaviour is predictible: an envelope is processed the way it was told to process it when the daemon accepted it. things may change and may no longer be what you want, but there's no guessing how things will be handled. Now do we want to prevent you from reevaluating mails that are already in queue ? Nope, but IMO the proper fix is not to turn the daemon into a smart guesser but rather to enhance smtpctl so that when an admin makes a config change, (s)he can decide to reevalute or not some envelopes or not. -- Gilles Chehade https://www.poolp.org @poolpOrg
