On 9/23/2013 9:18 PM, Tim Prepscius wrote: > No, I don't mean network dump. > > I mean the full mime-message. > With all the headers that have been attached during the postfix > process and by (in my case) java-mail, etc. > > For instance stuff like this: > Subject: Re: on send call command > In-Reply-To: > <caaj3avuz+b46ogo7umbrkx+bfbr8dcqdz0vpvp+9s9m3e98...@mail.gmail.com> > To: Postfix users <postfix-users@postfix.org> > Date: Mon, 23 Sep 2013 20:08:26 -0400 (EDT) > Reply-To: Postfix users <postfix-users@postfix.org> > X-Mailer: ELM [version 2.4ME+ PL124d (25)] > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset="US-ASCII" > Message-Id: <3ckn624d0mzj...@spike.porcupine.org> > From: wie...@porcupine.org (Wietse Venema) > Sender: owner-postfix-us...@postfix.org > >
The queue file is identical to what is transmitted over the network.[1] Do you need to examine the message for testing, or for operational audit? For testing, pause delivery with "defer_transports = smtp" and examine the queue file with postcat -hbq QUEUEID, which will show exactly what postfix will send out.[1] If this is for operational audit, explain why always_bcc and system logging is insufficient. If this is for some other purpose, please explain your problem more clearly. [1] unless you've configured the optional smtp_header_checks, smtp_body_checks, or smtp_generic_maps, in which case your only choices are always_bcc or a network packet capture. -- Noel Jones
