Attn. postfix users WAS Multiple Postfix smtp instances

[Dhawal Doshy]

Glenn Steen wrote:
> On 04/05/06, Dhawal Doshy <dhawal at netmagicsolutions.com> wrote:
> (snip)
>> http://article.gmane.org/gmane.mail.postfix.user/140871
>> http://article.gmane.org/gmane.mail.postfix.user/140888
>> http://article.gmane.org/gmane.mail.postfix.user/140902
> Hi Dhawal,
> 
> First up, I admire your tenacity and courage... This is a battle I've
> thought of fighting, and subsequently shied away from, more than
> once...

i know what you feel.. i have myself shied away more than once (due to 
death threats from the postfix underworld) and would have again if 
Wietse were not so outright in proclaiming that he would break 
mailscanner compatibility in the next version..

Viktor appears to quite reasonable and open on getting this resolved but 
requires some smarter inputs. i genuinely think i am not the right 
person to pursue this any further.. and someone more technically 
competent with a much better understanding of both postfix and 
mailscanner ought to do so (if the inclination exists).

i have symmetric multiple headaches already and am almost about to give 
up.. and will mostly opt for the wait till it breaks and watch situation.

- dhawal

> In the last link above you say:
> ------
> I do agree that the file isn't renamed as per the new inode and linked /
> logged.. i will communicate this to the MailScanner developers.
> ------
> I'm not entirely certain you are right in this. Jules will no doubt
> correct me if I'm wrong, but at the time when the (new) queue file is
> reintroduced into the postfix incoming queue, it is certainly handled
> as outlined by Viktor... And prominently logged with both old
> (postfix_queue_id.random ...) and new queue IDs, where the new queue
> ID is certainly linked to the current i-node number (as stipulated).
> So there is no discrepancies here. At least not that I can see.
> 
> Further down you and Viktor say:
> -----
>>> 5) Mailscanner MUST maintain the relationship between the file name and
>>> the file inode number. Otherwise mail will be corrupted or lost.
>>>
>>> MailScanner: See reply to point 4. original filename is appended with a
>>> random number.
>>
>> This is wrong. The relationship must be maintained *exacty*, not by
>> appending a suffix.
> 
> Understood.
> -----
> What is wrong here is not what MailScanner does, but the perspective
> of the reply (I know you go on to correct this somewhat further down,
> but bear with me:).
> As far as it goes, MailScanner maintains this relationship (by not
> really touching the queue file, other than to make a copy of it)
> throughout the entire chain. That it is the copy/new queue file that
> is reintroduced to Postfix doesn't change this in any way (that I can
> think of:-). From the Postfix perspective, this operation is a "black
> box", IMHO (Why should they even care what happens to that copy,
> before it is reintroduced? When they are guaranteed that the "trust
> chain" cannot be broken by the actions taken in the "black box"...?).
> Oh well.
> 
> Further:
> -----
>>> 8) Mailscanner MUST NOT modify queue files. If content needs to be
>>> updates, Mailscanner MUST create a new queue file and delete the
>>> original only after the new file has been committed to stable storage.
>>> Otherwise mail will be corrupted or lost.
>>>
>>> MailScanner: See points 4,5,7
>>
>> Exactly, do not reply until understand why this is true. If still 
>> disagree
>> with 8, do not reply. Sorry.
> 
> Agreed, modifications are made to a copy of the queue-file in mailscanner's
> incoming directory and post-processing written to the postfix incoming 
> queue
> directory. I'll anyways get further clarification from the mailscanner
> developers.
> ------
> More "philosophical hairsplitting"... Again, from the Postfix
> perspective, the reintroduced queue file should be seen as an entirely
> new, fully logged, queue file. So this should also be a non-issue.
> 
> Thing is, the Posfix developers don't really know (nor care, it
> seems:-) how MailScanner works, and have never looked at Jules code
> (AFAICS, else they would know at least some of these things already).
> I can certainly not claim a full understanding of it either, but have
> at least looked through it a couple of times... Mostly to assure
> myself of these very things (and to determine why I had so darned many
> duplicates in MailWatch, back when that was a problem). .... And even
> a cursory understanding, like mine, seems to be lacking.
> I'm in no way criticising them for that. They should be, and are,
> focused on what's important to them (Postfix mainly:-).
> 
> I'm not sure that they even need to know particularly much about it
> either, because all they should need know is that the things they
> stipulate is covered nicely already.
> I guess what I'm trying to say is that we need to adjust our thinking
> to the "slightly skewed" Postfix perspective when communicating with
> them.
> For one thing, I don't think they've really appreciated the
> ramifications of the use of the HOLD thing, although it is "their
> feature" so to speak:-).
> 
> Oh, and we do need world domination^H^H^H^H^H^H^H^H^H^Hpeace (:-).
> 
> -- 
> -- Glenn (Who just can't handle another high-volume mailing list more,
> or otherwise would participate more directly on the postfix-users
> list)
> email: glenn < dot > steen < at > gmail < dot > com
> work: glenn < dot > steen < at > ap1 < dot > se