[23472] in bugtraq
Re: Mail Essentials reveals identity of first BCC recipient
daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q?J=F6rgen_Persson?=)
Wed Dec 12 15:36:18 2001
Date: Wed, 12 Dec 2001 20:15:25 +0100
From: =?iso-8859-1?Q?J=F6rgen_Persson?= <jpn@tlth.lth.se>
To: bugtraq@securityfocus.com
Message-ID: <20011212201525.A24429@tlth.lth.se>
Mail-Followup-To: =?iso-8859-1?Q?J=F6rgen_Persson?= <jpn@tlth.lth.se>,
bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <15383.10630.436261.175544@eris.euroconex.prv>; from ronan.waide@euroconex.com on Wed, Dec 12, 2001 at 09:55:18AM +0000
On Wed, Dec 12, 2001 at 09:55:18AM +0000, Ronan Waide wrote:
> Hi Bugtraqers,
>
> I recently received a marketing mail from a supplier who uses an email
> content filter called Mail Essentials from GFI Software (see
> http://www.gfisoftware.com/me/mesfeatures.htm for more
> information). The message had no destination address, having been sent
> to a BCC list. On inspecting the Received: headers, I found one
> inserted by Mail Essentials:
>
> Received: From mail.server by other.server
> Mail essentials (server 2.422) with SMTP id: <513@mail.server>
> for <bcc_person@address>; Wed, 29 Aug 2001 16:19:12 +0100
> smtpmailfrom <originator@address>
>
> The 'bcc_person@address' was, presumably, the first person on the BCC
> list - it certainly wasn't /my/ address. I brought this to the
> attention of GFI software over a month ago, and the eventual response
> was to the effect that 'BCC headers get stripped out' - evidently the
> problem was misunderstood. Since I've not heard anything more from
> them after clarifying the situation, I'm posting the problem here in
> case anyone happens to use this software in-house.
>
> Cheers,
> Waider.
True, the described behaviour is usually not desirable. ''GFI Software''
ought to consider to change it.
On the other hand, RFC 2821 and RFC 2822 clearly indicates that the Bcc:
field is not to be trusted in general unless you know for certain how it
will be handled.
RFC 2821, section:
4.4 Trace Information
7.2 ''Blind'' Copies
7.5 Information Disclosure in Trace Fields
RFC 2822, section:
3.6.3. Destination address fields
5 Security Considerations
Sincerely,
Jörgen
