On 29 November 2014, Gilles Chehade <gil...@poolp.org> wrote:
> 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 don't, but I believe the initial poster did, in the message that
started this thread: messages routed to invalid relays, clogging the
queue.
> 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.
Excellent! :)
> I'm against having the daemon execute the command automatically,
Yup, I never said it should run 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 ?
See above: mail stuck in queue, with nowhere to go?
> 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 ?
Right, I suppose I should have explained my point, rather than
assume people around me are mind readers. ;)
What I mean by "re-queue" is something like this: the content of
the old message is injected as if it were a new message, and the old
message is deleted. It doesn't matter what the old routing was, for all
intents and purposes it's a new message, that just happens to have the
same content and the same envelope as the old one. There is nothing to
roll back, only the current configuration conts. Does it start to make
some sense now?
The only notable problem with this approach would be that some
recipients might receive the message twice, but not for the reason you
mention: the message might have been already sent successfully to some
of its recipients before it gets requeued. This is unavoidable (or at
least a very hard problem), since old and new alias expansion might
resolve to the same final recipient starting from different inputs.
But I'd say receiving a message multiple times is preferable to not
receiving it at all.
> 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 ?
Nope, I never said this should happen any other way than on explicit
demand, when the admin runs "smtpctl requeue <ID>", or something like
that.
> 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 ?
I haven't used Sendmail for the last maybe 15 years, I don't know
about Exim, and Qmail is all but dead. :) I'm not sure why this matters;
the way each mailer solves a problem depends (among other things) on its
architecture, and Postfix seems to me close enough to your smtpd from
this point of view to offer at least *some* philosophical inspiration.
Which is why I (rudely) interrupted this thread with my suggestion. :)
> 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.
Not sure about Postfix being "right", but it does solve the initial
problem: you fix the relay, you run "postfix -r ALL", and the messages
go on their way. With smtpd you fix the relay, clear the queue, and ask
people to resend their messages (or at least that's my reading of this
thread).
> 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.
Regards,
Liviu Daia
