Closed Bug 29421 Opened 25 years ago Closed 24 years ago

Empty mail generates unnessesary mail information

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(1 file)

The generated info by an empty mail
(deleted), text/plain
Details
Go into Mozilla and change the pref to send HTML mail. Now compose a new mail. Leave the message text field empty. Send the empty mail. Choose Send both as text and HTML mail asked for. If you look at the source of the send mail it contains both a empty text and HTML message. There is no need for this. Expected: If the mail message is empty only headers are send. This is also how 4.x and Outlook works.
Attached file The generated info by an empty mail (deleted) —
QA Contact: lchiang → pmock
reassign ro rhp
Assignee: ducarroz → rhp
Actually, you will only see this if generating multipart/alternative mail messages and technically, the message is not blank, there is a <BR> in the body. Also, this is the exact behavior of 4.x and its correct because multipart alternative requires you send both body parts. If your environment is setup to send plain text messages and you don't enter any text, you will get what you are expecting. - rhp
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
If I delete all text in the body and therefor are sending en empty mail, why should Mozilla send this mail as "multipart/alternative"??? That must be a bug! If the body is empty Mozilla should not be constructing any mime part information. Just send the headers. That's the way Netscape 4.7 works!
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Sorry, but I spent about an hour digging into this one and it behaves as it should for me. I would like someone in QA to verify what is going on. The only time you should get multipart alternative is in one of 2 cases. The first is that you select it from the Options -> Format menu. The second is from the intelligent send feature, but in this case you will receive a selection dialog and you will be asked to choose what format you want to send. I have tested both of these and they both work for me. Peter, can you give this a whirl and verify one of us :-) - rhp
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Peter is on sabbatical. I'll get it done for you on Monday.
Oh, wait...ok, you are asking for "Send both as text and HTML mail asked for" so you will get multipart/alternative. So, if this is fixable, the issue is determining if the body of the message is "Empty". This is not simple because we get an empty HTML document even if there is no content entered by the user. This is an intelligent send issue. - rhp
Oh, wait...ok, you are asking for "Send both as text and HTML mail asked for" so you will get multipart/alternative. So, if this is fixable, the issue is determining if the body of the message is "Empty". This is not simple because we get an empty HTML document even if there is no content entered by the user. This is an intelligent send issue. - rhp
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Hi JF, Not sure if this is possible since we get an empty HTML document from and HTML compose even if you don't enter any text. The fix would be to determine that there was no user input and then not ask the user for the format and send an empty message. - rhp
Assignee: rhp → ducarroz
Status: REOPENED → NEW
Accepting.
Status: NEW → ASSIGNED
Target Milestone: M16
In this case, we intelligent HTML send feature should detect that the body doesn't contains any formatting (see bug 28420) and therefore we will switch automatically in plain text for the transmission. At this point it will be very easy to detect if the body is empty or not. Now, what's about if we just have a signature? we should send it anway, right?
Depends on: 28420
4.7 behavior when sending a message with an empty body using html compose: Here is what page source shows after all the header info: <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> &nbsp;</html> Seamonkey behavior when sending a message with an empty body using html compose: Here is what page source shows after all the header info: <html><head></head> <body> <br> </body> </html>
Not beta2 stopper. Marking M18.
Oops. Really marking M18 now...
Target Milestone: M16 → M18
> Choose Send both as text and HTML mail asked for. [long cut] > If I delete all text in the body and therefor are sending en empty mail, why > should Mozilla send this mail as "multipart/alternative"??? Because you *explicitly* asked for it. Why do you select "send as both plain text and HTML", if you don't want HTML? > That must be a bug! No, I think, it would be a bug, if there were no multipart/alternative info, since you asked for it. I really don't understand the problem. I'd mark this INVALID. We could turn this bug into a request to not send any body (not even newlines), if there has been nothing entered (but I don't see a practical need for it).
This seems to have been fixed in build 2000061820
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Forgot to mark fixed.
Only the only unnecessary info is: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: