How to retrieve queue_id after submission

[Gary Smith-20]

Hi team,

 

I may have asked this years ago, but I can’t find it in my email.  I have a need to retrieve the queue_id of emails submitted at time of submission when issuing submissions with the -G option.  I can see that there is a queue_id on all of the output specified in -vv.  With that I can grab all the output and extract queue_id, but I’m wondering if there is a better or recommended way of doing this?

 

Example:

 

cat test2.msg  | /usr/sbin/sendmail -G -i -f [hidden email] -- [hidden email] 2>&1 | grep "send attr queue_id"

postdrop: send attr queue_id = 874DA54C89

 

 

Gary Smith

[Wietse Venema]

Gary Smith:
> Hi team,
>
> I may have asked this years ago, but I can't find it in my email.
> I have a need to retrieve the queue_id of emails submitted at time
> of submission when issuing submissions with the -G option.  I can
> see that there is a queue_id on all of the output specified in
> -vv.  With that I can grab all the output and extract queue_id,
> but I'm wondering if there is a better or recommended way of doing
> this?

The Postfix sendmail+postdrop commands create a queue file in the
maildrop directory. That is NOT the queue ID that Postfix will use
during actual message deliveries.

If you need the queue ID that is used during message deliveries.
then you need to submit mail with SMTP (preferably, using the
"submission" port).

        Wietse

[Gary Smith-20]

> Gary Smith:
> > Hi team,
> >
> > I may have asked this years ago, but I can't find it in my email.
> > I have a need to retrieve the queue_id of emails submitted at time of
> > submission when issuing submissions with the -G option.  I can see
> > that there is a queue_id on all of the output specified in -vv.  With
> > that I can grab all the output and extract queue_id, but I'm wondering
> > if there is a better or recommended way of doing this?
>
> The Postfix sendmail+postdrop commands create a queue file in the
> maildrop directory. That is NOT the queue ID that Postfix will use during
> actual message deliveries.
>
> If you need the queue ID that is used during message deliveries.
> then you need to submit mail with SMTP (preferably, using the "submission"
> port).
>
> Wietse

Wieste,

Sorry for the slow follow up.  To make sure that I'm on the same page,

Exiting:
master.cf:
smtp      inet  n       -       n       -       -       smtpd
        -o content_filter=jbaddrfix:dummy
jbaddrfix unix  -       n       n       -       10      pipe
  flags=Rq user=filter argv=/etc/postfix/custom/jb_mail_processor.py --from ${sender} --recipient ${recipient}

main.cf:
virtual_alias_maps = hash:/etc/postfix/custom/virtual_alias

So for all incoming email I want to pass it off to the jb_mail_processor script.  This script internally breaks the email down into a list of unique emails based upon the --recipient map values passed in from smtp to jbaddrfix.

Inside of the script file we re-inject it back into the process via "/usr/sbin/sendmail -G -I -f @sender -- @recipient"

Instead of using the /usr/sbin/sendmail I should run it directly back into the submission/smtp as a new email?  If so, what's the best command to do that, and best way to log the queue id of that new email being submitted?

Sorry, not trying to be dense here, I've just always done it using sendmail and haven't needed tracking until now.

[Wietse Venema]

Gary Smith:

> > Gary Smith:
> > > Hi team,
> > >
> > > I may have asked this years ago, but I can't find it in my email.
> > > I have a need to retrieve the queue_id of emails submitted at time of
> > > submission when issuing submissions with the -G option.  I can see
> > > that there is a queue_id on all of the output specified in -vv.  With
> > > that I can grab all the output and extract queue_id, but I'm wondering
> > > if there is a better or recommended way of doing this?
> >
> > The Postfix sendmail+postdrop commands create a queue file in the
> > maildrop directory. That is NOT the queue ID that Postfix will use during
> > actual message deliveries.
> >
> > If you need the queue ID that is used during message deliveries.
> > then you need to submit mail with SMTP (preferably, using the "submission"
> > port).
> >
> > Wietse
>
> Wieste,
>
> Sorry for the slow follow up.  To make sure that I'm on the same page,
>
> Exiting:
> master.cf:
> smtp      inet  n       -       n       -       -       smtpd
>         -o content_filter=jbaddrfix:dummy
> jbaddrfix unix  -       n       n       -       10      pipe
>   flags=Rq user=filter argv=/etc/postfix/custom/jb_mail_processor.py --from ${sender} --recipient ${recipient}
>
> main.cf:
> virtual_alias_maps = hash:/etc/postfix/custom/virtual_alias
>
> So for all incoming email I want to pass it off to the jb_mail_processor
> script.  This script internally breaks the email down into a list
> of unique emails based upon the --recipient map values passed in
> from smtp to jbaddrfix.
>
> Inside of the script file we re-inject it back into the process
> via "/usr/sbin/sendmail -G -I -f @sender -- @recipient"

This creates the temporary queue file in the maildrop directory,
which is not recorded in Postfix's delivery logs.

> Instead of using the /usr/sbin/sendmail I should run it directly
> back into the submission/smtp as a new email?  If so, what's the
> best command to do that, and best way to log the queue id of that
> new email being submitted?

A dedicated SMTP service that receives mail like the 'advanced'
example in http://www.postfix.org/FILTER_README.html. This service
will report the new queue ID in its response to 'end-of-data'.

250 2.0.0 Ok: queued as XXXXX

This is the queue ID that is recorded in  Postfix's delivery logs.

        Wietse

> Sorry, not trying to be dense here, I've just always done it using
> sendmail and haven't needed tracking until now.

[Gary Smith-20]

> -----Original Message-----
> From: [hidden email] <[hidden email]>
> On Behalf Of Wietse Venema
> Sent: Monday, April 8, 2019 1:18 PM
> To: Postfix users <[hidden email]>
> Subject: Re: How to retrieve queue_id after submission
>
> Gary Smith:
> > > Gary Smith:
> > > > Hi team,
> > > >
> > > > I may have asked this years ago, but I can't find it in my email.
> > > > I have a need to retrieve the queue_id of emails submitted at time
> > > > of submission when issuing submissions with the -G option.  I can
> > > > see that there is a queue_id on all of the output specified in
> > > > -vv.  With that I can grab all the output and extract queue_id,
> > > > but I'm wondering if there is a better or recommended way of doing
> this?
> > >
> > > The Postfix sendmail+postdrop commands create a queue file in the
> > > maildrop directory. That is NOT the queue ID that Postfix will use
> > > during actual message deliveries.
> > >
> > > If you need the queue ID that is used during message deliveries.
> > > then you need to submit mail with SMTP (preferably, using the
> "submission"
> > > port).
> > >
> > > Wietse
> >
> > Wieste,
> >
> > Sorry for the slow follow up.  To make sure that I'm on the same page,
> >
> > Exiting:
> > master.cf:
> > smtp      inet  n       -       n       -       -       smtpd
> >         -o content_filter=jbaddrfix:dummy
> > jbaddrfix unix  -       n       n       -       10      pipe
> >   flags=Rq user=filter argv=/etc/postfix/custom/jb_mail_processor.py
> > --from ${sender} --recipient ${recipient}
> >
> > main.cf:
> > virtual_alias_maps = hash:/etc/postfix/custom/virtual_alias
> >
> > So for all incoming email I want to pass it off to the
> > jb_mail_processor script.  This script internally breaks the email
> > down into a list of unique emails based upon the --recipient map
> > values passed in from smtp to jbaddrfix.
> >
> > Inside of the script file we re-inject it back into the process via
> > "/usr/sbin/sendmail -G -I -f @sender -- @recipient"
>
> This creates the temporary queue file in the maildrop directory, which is not
> recorded in Postfix's delivery logs.
>
> > Instead of using the /usr/sbin/sendmail I should run it directly back
> > into the submission/smtp as a new email?  If so, what's the best
> > command to do that, and best way to log the queue id of that new email
> > being submitted?
>
> A dedicated SMTP service that receives mail like the 'advanced'
> example in http://www.postfix.org/FILTER_README.html. This service will
> report the new queue ID in its response to 'end-of-data'.
>
> 250 2.0.0 Ok: queued as XXXXX
>
> This is the queue ID that is recorded in  Postfix's delivery logs.
>
> Wietse
>
> > Sorry, not trying to be dense here, I've just always done it using
> > sendmail and haven't needed tracking until now.

Wieste,

All of that makes complete sense.  I have setup advanced filters in the past for applications that handled SMTP injection but I've haven't had to directly send email via SMTP through the advanced filter (well not in a decade probably) .  

Here is where I'm at:
I have setup an advanced filter on localhost:10026
I have testing the filter to make sure it will indeed relay the email (with sender/network validation)

I think my final step, and where my confusion is, is how to drop the email from my content filter and then forward it to localhost:10026.  Is there some type of cheater script out there that can take the same 3 pieces of data that sendmail would require (sender, recipient, raw message) to pump that into localhost:10026 or do I need to use something like netcat?

This is the final piece, everything seems to be running smoothly.

[Wietse Venema]

Gary Smith:

> Here is where I'm at:
> I have setup an advanced filter on localhost:10026
> I have testing the filter to make sure it will indeed relay the email (with sender/network validation)
>
> I think my final step, and where my confusion is, is how to drop
> the email from my content filter and then forward it to localhost:10026.
> Is there some type of cheater script out there that can take the
> same 3 pieces of data that sendmail would require (sender, recipient,
> raw message) to pump that into localhost:10026 or do I need to use
> something like netcat?
>
> This is the final piece, everything seems to be running smoothly.

If your system is written in Perl or Python, use one of the available
SMTP protocol modules.

Otherwise, there must be many 'surrogate' sendmail programs that
pretend to be like /usr/sbin/sendmail but behind the scenes use
SMTP commands.  The list that I have is 20 years old. Myabe 'acme
sendmail' still works. You will have to deal with error handling
(just return a suitable status to pre-filter Postfix).

        Wietse