Re: [exim] access to bcc headers

Startseite
Nachricht löschen
Nachricht beantworten
Autor: W B Hacker
Datum:  
To: exim users
Betreff: Re: [exim] access to bcc headers
Brett Parker wrote:
> On 23 Mar 09:03, Raphael Bauduin wrote:
>> Hi,
>>
>> I'm working on an Exim config that saves the mails sent into the
>> user's Sent folder in maildir format.
>> This works fine, except when users send mails with people in BCC.
>>
>> I'm looking to correct this, but I have problems accessing the bcc
>> header. At what time do I have access to the bcc header?
>> I tried in the ACLs and in the system filters, to no avail.
>
> In theory - never... however, there is a potential way to get the BCC
> people - you get a list of envelope receipients, remove addresses that
> exist in To: or Cc: fields and the rest are Bcc: receipients.
>
> Cheers,


Here is a stripped-down real-world example [1]:

=========

1LlhoH-00044R-RT-H

#stripped of preserved expansion and acl_m variables #

3
    # the recipients count


askbill@???
wbh@???
wbh@???

    # the list of recipients


040T To: Bill Hacker <askbill@???>

    # The only 'To:' address.
    # Ergo the other two are 'most probably' Bcc: [2]


==========

FWIW, there are two other considerations:

First - you don't need to do this if 'archiving' alone is all that is
wanted. Each of those will see a recorded router/transport traversal on
delivery, and can be captured with an 'unseen' router or shadow
transport. You just will not know if it was a 'primary' addressee or a
CC:/Bcc:

OTOH, as an MTA, you are not *supposed to*.

Second: If your goal is *specifically* to ascertain the difference and
record 'Bcc:' - which carry an expectation of confidentiality - be aware
that this may NOT be the sort of intrusion universally welcomed.

Or even legal - depending on where you sit, and how your host
jurisdiction responds to intrusion by OTHER jurisdictions. Ask a Swiss
banker about that sort of thing...

Not an Exim issue, but not to be ignored, either.

HTH,

Bill


Notes:

[1] Created by:

- setting Exim configure to 'queue_only = true'

- restarting Exim with 'q55h'

- sending myself a test message

- cp'ing the very much larger copy of the above out of
/var/spool/exim/input. ~/mainlog had the messageID.

** remembering to set everything back to normal, so we don't have to
wait 55 hours for our mail!!! EG: 'q55s' here.


[2] Previously known to be so in the case of this test message.
*Otherwise* subject to both sets of CAVEATS previously posted by Graeme.