MS additional header line

[Glenn Steen]

On 18/01/07, Kevin Miller <Kevin_Miller at ci.juneau.ak.us> wrote:
> Vasiliy Boulytchev wrote:
> > Received: by mx00.cbici.net (CommuniGate Pro PIPE 5.1.3)
> >   with PIPE id 4537081; Thu, 18 Jan 2007 13:22:52 -0500
> > Received: from smtpout.mx.citinternet.com ([67.128.25.254] verified)
> >   by mx00.cbici.net (CommuniGate Pro SMTP 5.1.3)
> >   with ESMTP id 4537072 for vasiliy at cbici.net; Thu, 18 Jan 2007
> > ...snip
> > The
> > ESMTP id 4537072
> > is not what MailWatch and MS use for message ids.
>
> Nope, because that ID is from a previous MTA process.  I think the ID
> you're looking for is the PIPE id - in this case 4537081.
>
> Remember that MailScanner does a two step with the MTA.  First the MTA
> receives the mail from somewhere, then hands it off to MailScanner for
> analysis, then hands it back to an MTA for delivery.  The 4537072 id is
> the first MTA interaction where it is received.  The PIPE id 4537081 is
> presumably the ID that Communigate Pro is giving it after MailScanner
> has done it's thing.  On my system at least, the ID used by MW is the
> last id assigned by the MTA.
>
> But I've never played with CGP so maybe it does it differently?
>
Not really replying to you specifically Kevin, but to all in this
thread.... The devil is indeed in the details here, methinks:-)
IIRC how Vasiliy has his setup done there is a "frontside" postfix MTA
(on one box?) that receive and MailScanner/MailWatch etc, then use
some script made by dear ol' John Rudd to transport the mails over to
CGP.
So what Vasiliy sees in MailWatch is the postfix queue file ID (as
usual) with the nice little extra entropy tagged on. In this case, the
ID is 8D55F178FF, so that message would have an id in MW of
8D55F178FF.XXXXX ... and here is where all the confusion stems
from:-).
Those extra bits are nowhere in sight in the headers, so you are
correct about that Vasiliy. But should they be? I don't really know if
I need them... I can always either look for the real message ID (in
MailWatch), look for the queue file id (also in MW), grep the mail log
(for the queue file ID) etc etc. So sure, you don't have it to easily
cut'n'paste, but it is far from gone;-).

I suppose if one really wanted to, there could be a way to add that in
an X-Temporary-ID or somesuch, but... the ID is only meaningful for
tracking in the log and in MailWatch... It really is rather temporary
in nature (we construct and deliver a completely new queue file with a
completely new ID after scanning....).

So basically, my advice boils down to:
- Use the mail log
- Use the reporting functions in MailWatch (if this is to find a
quarantined entity, the report mail contains the ID ratehr prominently
too, but the report page will always work:-)
- If all else fails... Use the source Luke;-D

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se