Re: Bcc not working?

[Brian Stafford <brian stafford uklinux net>]

On Wed, 20 February 22:20 Thomas Maeder wrote:
> Am 2002.02.20 09:29 schrieb(en) Brian Stafford:

> Anyway, I started this version and sent a message from it with To: and Bcc: 
> both set. This is the output:
...
> S: 220 cicero.glue.ch ESMTP BusinessMail
> C: EHLO madbox
> S: 250-cicero.glue.ch
> 250-PIPELINING
> 250-SIZE 10240000
> 250-ETRN
> 250 8BITMIME
> C: MAIL FROM:<maeder@glue.ch> SIZE=1024
> S: 250 Ok
> C: RCPT TO:<maeder@glue.ch>
> Send_Message: 136848872, 1, From: 250 <maeder@glue.ch>
>  From maeder@glue.ch: 250 Ok
> 
> S: 250 Ok

At this point the envelope for the first message is complete.  No problem so 
far.

> C: DATA
> Send_Message: 136957056, 1, To: 250 <maeder@glue.ch>
> To maeder@glue.ch: 250 Ok
> 
> S: 354 End data with <CR><LF>.<CR><LF>

The 354 status code is an intermediate status indicating that the server is 
prepared to accept the message body.

> H: Date: Wed, 20 Feb 2002 21:48:45 +0100
> H: From: Thomas Maeder <maeder@glue.ch>
> H: To: Thomas Maeder <maeder@glue.ch>
> H: Subject: Test mit Bcc:
> H: Message-ID: <20020220214845.A15240@madbox.hispeed.ch>
> H: Mime-Version: 1.0
> H: Content-Type: text/plain; format=flowed; charset=ISO-8859-1
> H: Content-Transfer-Encoding: 8bit
> H: X-Mailer: Balsa 1.2.4
> H: Content-Length: 1
> H: Lines: 1

Ok, the next messages got mixed up - I'm not sure exactly why.  Possibly there 
is a threading problem?

> Send_Message: 136846344, 1, Send_Message: 136848872, 1, S: 250 Ok: queued as 
> B7F7F3BA5A

This is where the problem starts.  The message should have been submitted 
again, except that the RCPT TO: command would list the Bcc recipients and the 
message headers should include the Bcc: header the second time around.

As you can see, libesmtp has progressed to the QUIT command to terminate the 
session.  This suggests to me that your sources are out of sync with the 
latest CVS or something of that nature.

Normally, libESMTP will only abort a multiple message session midway on an 
unrecoverable protocol or socket error.  Since the DATA command terminated 
with a 250 status there was no such error.

When libESMTP was originally integrated into balsa, the bcc function was 
broken.  The message was submitted once.  It relied on the Bcc header being 
passed to the server and the envelope included the Bcc recipients and the 
To/CC recipients.  Then one hoped the server would strip the Bcc header fror 
non-bcc recipients.

The current Bcc algorithm was added a few months later after some detailed 
reading of the description of bcc in RFC 2821 and 2822.  The behaviour you see 
suggests to me that your copy of libbalsa/send.c is out of date but the 
additional info with the protocol trace (the Send_message: ... lines) suggests 
other parts of balsa are more recent.

If your copy of libbalsa/send.c is up to date, the following comment and code 
should be seen around line 574

             total_messages_left++;
             libbalsa_message_flag(msg, TRUE);
             /* If the Bcc: recipient list is present, add a additional
                copy of the message to the session.  The recipient list
                for the main copy of the message is generated from the
                To: and Cc: recipient list and libESMTP is asked to strip
                the Bcc: header.  The BCC copy of the message recipient
                list is taken from the Bcc recipient list and the Bcc:
                header is preserved in the message. */
             bcc_recip = g_list_first((GList *) msg->bcc_list);
             if (!bcc_recip)
                 bcc_message = NULL;
             else
                 bcc_message = smtp_add_message (session);
             new_message->refcount = bcc_recip ? 2 : 1;

At this point your trace should look like the one that Pawel put on the list.  
Had he not done so I would have generated the trace myself, as I get the same 
results.  About halfway down Pawel's trace you will see the 250 OK response to 
the DATA command immediately followed by the MAIL FROM: for the second copy of 
the message.  If you examine the two copies of the message you will see that 
they differ only in the Bcc: header.  Most importantly the Message-Id is the 
same.

NB an SMTP server *must not* change the Message-Id.  All recipients are 
guaranteed the same message-id as the one the message was submitted with.  If 
not, a server somewhere in the chain is broken.

> C: QUIT
> Send_Message: 136957056, 1, 250 Ok: queued as B7F7F3BA5A
> 
> 250 Ok: queued as B7F7F3BA5A
> 
> S: 221 Bye
> Locking mailbox Ausgang
> Unlocking mailbox LibBalsaMailbox: Closing Ausgang Refcount: 1
> Locking mailbox Ausgang
> Unlocking mailbox Send_Message: 136846344, 1, Disconnected
> Send_Message: 136848872, 4, Writing /home/maeder/mail/outbox...
> Sorting mailbox...
> 0 kept, 1 deleted.

I'd suggest that you check your sources are indeed up to date.  Perhaps you 
should get the latest tarballs (or CVS) and build them in a seperate directory 
to your existing copy of balsa.

Maybe before that, try building balsa with threading disabled.  I'm not sure 
why that message got mixed up with the protocol trace above.

Hope this is of some help.

--
Brian Stafford