On Sat, Nov 29, 2014 at 02:13:46AM +0200, Liviu Daia wrote: > On 28 November 2014, Gilles Chehade <gil...@poolp.org> wrote: > > On Thu, Nov 27, 2014 at 10:00:19PM -0500, Hugo Villeneuve wrote: > [...] > > > 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 ? > [...] > > No: the original HELO, FROM, and RCPT TO should be saved in the > queue file, and there should be a command to re-queue the message. Then > when a message is re-queued the entire envelope is resolved again from > scratch, according to the current config: problem solved. >
Well, that depends how you define the problem ;-) I'm not against having a command to re-enqueue, that is actually what I suggested myself. YES, WE SHOULD HAVE A COMMAND TO REENQUEUE. I'm against having the daemon execute the command automatically, and the reason is that in the "if you resolve again from scratch" case, you have some things that are going to be changed and others that aren't. Since "problem is solved" according to you, can you tell me which ones ? I mentionned aliases yesterday, with your method we would resolve again, so we would go through aliases expansion again. Let's put aside the fact that everyone would get a mail twice because we're going to be adding an insane amount of kludge anyway so a few to work around this special case isn't an issue anymore. You have resolved again so that the routing method changes, yet you have decided that expansions caused by the previous routing method should not be rollbacked. How do we decide what needs to be rollbacked and what doesn't ? Can you provide a list we can all agree upon ? Are you comfortable with taking decisions away from the admin and making the software take them instead... to cope with changes the admin will do to the configuration ? Is it ok if the software decides that all mail is going to dev/null because of a config change and without admin having an option to actually validate ? > This is essentially what Postfix does, and I have yet to hear anybody > arguing it should do something else. :) > Are you confident that this behaviour in Postfix is the same as that of Sendmail, Exim, Qmail to name the most common ? Just asking because you seem to imply that Postfix is doing things right and I'd like to hear about what makes its "resolving again" strategy any better than the others then. As for "hearing people argue", I don't consider this as a sign of doing things right. I work with Linux daily, I'm constantly irritated by some things I have to cope with, and you have yet to hear me argue about it. My mailbox is full of comments about people irritated about other MTA's but it has no technical value whatsoever. Ps: I won't be home before Monday so expect delays in my replies. -- Gilles Chehade https://www.poolp.org @poolpOrg
