Re: [RFC] : correct handling of sent mails

Le 03.09.2002 18:44, M. Thielker a écrit :
> Hi,
> not the recipient gets two copies, the sentbox does. Currently, mail is 
> first queued to the outbox, and copied to the sentbox at that time. 
> Later it gets sent out through smtp.
> The proposal is to copy the mail to the sentbox when it's actually given 
> to libesmtp and sent successfully. This is the correct behavior.
> However, the function to send mail is in libbalsa, IIRC. The copy to 
> sentbox operation would also need to be moved to libbalsa.
> The email is then given to libbalsa with Bcc: stripped, this will create 
> one copy of the mail in the sentbox. It is then given to libbalsa again, 
> with bcc: intact. That would create the second copy.
> Libbalsa has no way to know for sure if an email given to it has been 
> sent already and only the bcc recipient's copy is being sent. That 
> information would, to be reliable, have to be passed to libbalsa a well. 
> That will change the API footprint.
> IMHO simply not saving a copy if a Bcc: header is present is too 
> simplistic, it will not work if some desktop user adds the same users to 
> To: and Bcc:. In this case, a stripped version would _not_ be sent at 
> all, so if messages with a bcc: header are not saved, the message would 
> never be copied to the sentbox.

In fact the code provides you with almost all information you need now : 
it builds a list of messages to be processed and when the bcc header is 
there it puts only ONE message in this list (though it puts 2 messages in 
the queue submitted to smtp transport) with a refcount of 2 ("normal" 
mails have a refcount of 1). So you don't have the double message problem.

> I also see yet another problem in this approach: Imagine that the 
> submission of one of the two versions fails, for some reason. Should the 
> message be considered sent, therefore be in the sentbox, or should it be 
> requeued, therefore be in the outbox? If it's copied to the sentbox, 
> then moved back to the outbox, it would be saved in sentbox once more on 
> the (sucessful) submission retry.

This is the real decision we have to make. Because if one of the messages 
has been sent it should be in the Sentbox, but next time the other version 
will get sent eventually and put in the sentbox also (though here we could 
just try to test if it is a bcc version of a mail and check in the sentbox 
if it has been already put in). The problem boils down to what sense we 
give to a mail in sentbox in that case.

> There really ought to be state information associated with the message 
> to indicate if it's been copied to the sentbox. But then imagine it's 
> pulled back from the sentbox to the draftbox and re-sent unaltered. 
> There really should be another copy saved in the sentbox, since the 
> message was actually sent twice, but if the state info says it's already 
> saved, this wouldn't happen.

There it's clear to me : if user moves out a mail from the sentbox, he 
knows what [s]he is doing, Balsa should not do anything behind [her]his 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]