Closed Bug 12916 Opened 25 years ago Closed 3 years ago

Allow bounce/redirect of mail messages

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr78 wontfix)

Status:
RESOLVED FIXED
Milestone:
90 Branch
Tracking Flags:
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: phil, Assigned: mkmelin)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: helpwanted)

Attachments

(11 files, 2 obsolete files)

Patch v0.1
18.70 KB, patch
Details | Diff | Splinter Review
v0.02
19.47 KB, patch
Details | Diff | Splinter Review
Bounce extension 0.0.3
27.50 KB, application/x-xpinstall
Details
mailredirect extension working in TB 2.0
103.48 KB, application/x-zip-compressed
Details
Bug 12916 - enable Redirect of messages. r=aleca!,benc!
48 bytes, text/x-phabricator-request
Details | Review
Zip containing my take at css and svg-icons for redirect menuitem and subjectCol
3.44 KB, application/x-zip-compressed
Details
redirect.svg
527 bytes, image/svg+xml
Details
redirect-forward.svg
1.00 KB, image/svg+xml
Details
redirect-reply.svg
1019 bytes, image/svg+xml
Details
redirect-reply-forward.svg
1.22 KB, image/svg+xml
Details
Screenshot of new Thunderbird redirect window
78.80 KB, image/jpeg
Details
Here's a frequently requested feature: Subject: Messenger: Redirect Button Date: Tue, 31 Aug 1999 19:33:03 -0500 From: Thomas Swan <tswan@sunset.backbone.olemiss.edu> Reply-To: tswan@olemiss.edu Organization: The University of Mississippi Newsgroups: netscape.public.mozilla.wishlist In our office, we have appointees for checking departmental email accounts. These need to be redirected to other recipients for a response. Normal forwarding doesn't solve this. When the proper recipient receives the email and the "replies" to it, the "reply" is sent to the secretary. The work around is having to cut and paste addresses into and out of the messages. This is often time consuming, not to mention aggravating. Redirecting mail would sending as the original sender adding a notation of who was doing the relaying. Eudora Light and Eudora Pro have this feature and it's the only reason why our office has not switch to another email client [we would rather use messenger :) ]. I have kept requesting this feature through normal channels, but it seems to have not fallen on the right ears. I would hope it would this time. Thanks, Thomas Swan
Whiteboard: HELP WANTED
Blocks: 11769
Keywords: helpwanted
Summary: [HELP WANTED] Allow bounce/redirect of mail messages → Allow bounce/redirect of mail messages
Whiteboard: HELP WANTED
Target Milestone: M20
I hate to ask, if someone can give me a starting point (module etc.) I'll be happy to give a shot at implementing this feature. I prefer not to just complain :)
I am not sure on what modules are involved, but it seems like redirect (how Eudora does it) is a variation of forward with out putting things like ">" infront of the original message. Then moving the from addres to the "To" line. Maybe someone can point out where all that is hiding.
You may want to ask in the mailnews newsgroup on news.mozilla.org to get an idea of which part of the code to look in first. Thanks.
What Eudora does is as follows... Also, it allows you to edit the message before sending it on, which I'm not sure I'm crazy about except that the person could put addtional instructions in there... Anyway, the original message is copied without any forwarding marks > | a sample Header follows From myname@myplace.com Fri Mar 24 00:33:24 2000 Return-Path: <myname@myplace.com> Received: {lots of stuff} X-Sender: myname@myplace.com X-Mailer: {whatever} Date: {Date} To: newrecepient@someotherplace.com From: Smoote <original@hisplace.com> (by way of Hawley <myname@myplace.com>) Subject: {whatever} Mime-Version: 1.0 Content-type: {standard stuff} I agree with you on what would need to be done. Essentionally a copy of the forward would work, changing instead of doing the call to set the From: value from the user's profile/preferences to the original senders address with the modifications and not modifying the messages contents with the "quote" markup... I'll try the newsgroup... thanks... P.S. I desperately want this in the mail/news client... :)~
tswan, that's great news -- thanks for volunteering to work on this! I think the key features that "bounce" is similar to are Drafts or Edit Message As New. You certainly need to whack the From header, but then you'll need to decide how many of the original headers you need to maintain vs. the ones you can let mozilla replace. You might also reassign this bug to yourself.
I don't believe this blocks Bug 11769. This is entirely different and not filter based. The definition of bounce in the summary is not to act as a rubber shield but to facilitate redirection of email to the proper recipients. 11769 is a different beast entirely... P.S. I'm still at a loss on where to begin, I've been thumbing through pages of code trying to follow a trace on the forward, and where to start modifying the code to allow for a redirect. I'm scared from what I've seen so far is that the headers are generated from the current identity or the identity associated with the message. I'm still looking... If anyone has any additional pointers I would greatly appreciate it...
adding me, rhp and ducarroz to the cc list. we'll help get thomas started. it sounds like he really wants to contribute to mailnews. reassign to tswan.
Assignee: nobody → tswan
Currently, going through source and finding areas that may need to be changed. Possibly starting a little hacking this weekend. I'll put a status update in a little while.
Status: NEW → ASSIGNED
Thomas, glad to have you hacking away! let us know if you need help or have questions.
As Phil points out, this is similar to the Drafts functionality. Recently alecf and I were contemplating one way to do this using Drafts to do most of the work (which, not coincidentally, would make moderating a list easy in Mozilla). Right now, if you refile a received message in Drafts and then instantiate it in composer and send it, it attempts to use your default email address as the From: line. Instead of mapping an unknown From: header to the default, your code could assume that an unknown From: header means "this is a redirect". The thought is that this probably would actually be pretty straightforward to code.
I'm about to complete a project that's been demanding most of my time... I should be ready to dive head first within a week... If anyone has an understanding of how the current mail system works, I'd appreciate a guiding hand at least in the beginning...
There's a whole team of mail developer on the newsgroup netscape.public.mozilla.mail-news ready and willing to answer your questions! :)
I know the last comment on this is a while ago, but I'm going to post this anyway. When you press the B key in PINE (you need to have this feature enabled in Setup), you can "bounce" a message, which is what this RFE describes. It sets the following headers: Resent-Message-ID: [the message ID on the message you got] Resent-To: [an address you enter] Resent-Date: [the date/time when you press "B"] Resent-From: [the person who did the bouncing]
David Turner, does it leave the other headers untouched? Especially keeping the msg-id would be important, for threading.
Message-ID: is assigned a new value. However, ReSent-Message-ID: keeps the Message-ID of the bounced/redirected message. The Recieved: headers keep the information as if it were bounced from mail server to mail server. The From:, Date:, Subject:, Content-Type: headers are preserverd along with the Reply-To: The following headers are added after Content-Type: Resent-Date: {Time the message was redirected/bounced} Resent-From: {Bouncer} Resent-Subject: {New Subject if you changed it during the bounce} Resent-Message-ID: {Original message ID, supposedly to help or other bookkeeping purposes} Added headers are as followes Resent-Date:
IMO, Mozilla should preserve the Message-ID. Otherwise the msg won't be threaded correctly by the majority of mailers. It is still the same msg, just forwadrd, similar to (automatic) forwarding email accounts.
Thomas Swan: What mail client are you using? Everything I said before applies to PINE (Outlook->PINE->NS4, for completeness). I just did a test with Outlook 5.0 for the Mac (NS4->Outlook->PINE). It added new Recieved headers as per Thomas Swann's example, and also followed his example on the Message ID. I'm not sure which is more correct - depends on who you are trying to preserve threading for: the original reciever, or the new reciever.
It sounds like Pine is doing exactly the wrong thing regarding Resent-Message-ID as per RFC 822 section 4.2. We should do the right thing, which would preserve threading.
> depends on who you are trying to preserve threading for: the original reciever, > or the new reciever. Please explain. With my suggestion, will threading break for anyone?
Dan Mosedale: Yes, PINE breaks RFC 822 (4.6.1, not 4.2). Ben Bucksch: What Outlook did (and RFC 822 requires) broke threading for the original sender. What PINE does appears to break threading for nobody. My vote, if I get one, and if it is infeasable for it to be configurable, is that PINE is correct and Outlook is wrong.
As I read 4.6.1., the forwarder should just add Resent-Message-ID, leaving the original Message-IS intact. This would be in line with my suggestion, adn I cannot see how this would break threading for anybody.
I have to agree. I don't think we should keep the original message ID, as it is technically a different message.
Alecf, the application, as defined by the reporter (tswan), is not much different from an automatic forwarder: all mail to <info@example.com> goes to <someguy@netscape.net> - just that here, somebody reads the mail for <info@example.com> and decides, based on the content, if it should go to <someguy@netscape.net> or <someotherguy@netscape.net>. In neither case, the msg is substantially altered - it is still the same one. Even our news/mail gateways at Mozilla.org preserve the msg-id. I would agree, if the forwarder would edit the forwarded msg, but I wouldn't call that "redirect" or "bounce" anymore, and thus exclude from this bug.
David Turner: 4.2 is relevant here. Specifically: Whenever the string "Resent-" begins a field name, the field has the same semantics as a field whose name does not have the prefix. However, the message is assumed to have been forwarded by an original recipient who attached the "Resent-" field. This new field is treated as being more recent than the equivalent, original field. For example, the "Resent-From", indicates the person that forwarded the message, whereas the "From" field indi- cates the original author. as well as Note: In general, the "Resent-" fields should be treated as con- taining a set of information that is independent of the set of original fields. Information for one set should not automatically be taken from the other. alecf: Consider that SMTP envelope splitting by MTAs is a very similar action: it creates a new copy of the message, adds headers (Received), and changes transport semantics, all while retaining the same Message-ID. However, it's certainly true that 4.6.1 would seem to support doing as you suggest. It would be interesting to know what the latest IETF-DRUMS son-of-RFC82x drafts say about this stuff. I bet they say more specifically what to do.
Mutt keeps the Message-id intact on bounce, but adds a Resent-Message-Id which is new. This seems like the right thing to do (since the message hasn't been changed substantially from the original) but it really depends on what most clients do (do they thread by Message-id or by Resent-Message-Id)? Bummer that Pine and Mutt seem to do exactly opposite things, though.
Akkana: What you describe Mutt doing is what I describe PINE doing. They agree. It's Outlook (and maybe RFC 822) that disagrees. RFC 822 4.6.1 and Alecf seem to support the Outlook method of doing things. But, this breaks threading (I tried it). If you reply to a bounced message (to the original author), your in-reply-to header will be one that he's never seen (the bouncer created it). Since threading is important, and blind standards compliance isn't, I suggest that, at least by default, Mozilla follow Pine and Mutt (rather than Outlook). To be fair, I can think of one possibly negative consequence: Some people may set up filters to ignore "duplicate" messages via message id (according to: http://www.exim.org/pipermail/exim-users/Week-of-Mon-19980727/008568.html, which also points out why these filters are a bad idea). In general, ignoring the duplicate is actually correct. RFC 2076 agrees with Outlook and Alecf: "Resent-headers. When manually forwarding a message, headers referring to the forwarding, not to the original message. Note: MIME specifies another way of resending messages, using the "Message" Content-Type." If there's still a strong belief in standards compliance despite the threading thing, it could easily be a configurable.
What RFC 822 4.6.1 says is arguable (unless you know the intend of the author :) ). "Version" and "instance" can be understood from a user-perspective, based on the body and important headers, not technical headers. The fact that MTAs are allowed to add headers supports this interpretation. For me, this paragraphs requires a new msg-ID, if the user opened a draft or a msg is forwarded with altering the body. I cannot see a clear statement that is requires a new msg-id for manually redirected msgs. RFC2076 is clearer, but the question is how authorative it is. How is the msg-ID different from, say, the date? If we have to change the msg-id, we also have to change the Date. I could go on... Basically, this is contrary to the whole feature and makes IMO no sense.
To me Redirect/Bounce should work as closely to my mail client acting as a .forward file to another recipient. Also, I would assume this amount of activity is a wake-up call to start doing some code walking?
Ben Bucksch: You also must change the date on a resend, yes. PINE "breaks" this one, too. Still, I don't see how it matters what the standard says, since we all (you, me, Thomas) agree that even if Jon Postel rose from the grave and told us that RFC 822 means what Outlook does, it would still be the wrong thing for Mozilla mail/news to do. I think RFC 822 thinks of a message as "from MUA through any number of MTAs to MUA and no further." As this doesn't suit us, we must abandon it. Thomas Swan: Yes to all of that.
*** Bug 69135 has been marked as a duplicate of this bug. ***
Alright, I now have a bunch of people on the CC and have a chunk of time to devote to adding this... Time to knock it out... Is there anyone on this list that can give me a hand and help me get started... I've got the latest nightly snapshot of the source, compiled and running on Linux.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Don't mark it fixed before you've got it checked in. Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ack... Didn't meant to change it to FIXED...
Status: REOPENED → ASSIGNED
OK, there's a new mail RFC. Outlook is wrong, PINE and Mutt are right. The new RFC also describes multiple bounces - they work kinda like multiple Received headers. See section 3.6.6 of: ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt
I really need to do something about this (e.g. work on it). And, I think I have a computer that I can do the development on. However, I really do need some help in getting started.
Thomas: what sort of help are you looking for?
Thomas, if you have any concrete questions, just ask.
*** Bug 103301 has been marked as a duplicate of this bug. ***
Ok, I know have time to devote to this thing again... what areas am I going to need to touch in order to have this. UI, and mailnews core. I'm pretty sure that this won't be too involved, although I'm still trying to figure out where I can modify the mail header before sending the message out again. As noted above, I think this should work very similar to either the forward (in-line) or the reply, but with not changing the reply-to and the from headers of the original message. I've got a linux machine and a win32 machine, I'd rather develop on the linux box if it would be the easiest. Suggestion?
As per the mozilla.org 1.0 document, we shouldn't implement new features until post-1.0 unless they are really important. I don't think this fits that requirement.
The bounce part is duped in bug 109930. You may want to take a look at KDE's Kmail which has these features. (Also Mac OS X's Mail.app: see http://bugzilla.mozilla.org/attachment.cgi?id=66696&action=view .)
OK, I was confused earlier today when I suggested that bug 12916 and bug 109930 overlap. What Mail.app does is wrap the "bounced" message in a new one with comments like this (described in RFC 2034, http://sunsite.dk/RFC/rfc/rfc2034.html): > Final-Recipient: RFC822; user@isp.net > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; postoffice. > Diagnostic-Code: SMTP;550 5.1.1 unknown or illegal alias: user@isp.net > Last-Attempt-Date: 2002-01-27 23:51:53 -0500 This is also what the emzlm program calls "bouncing" -- see e.g. http://lists.nas.nasa.gov/archives/ext/linux-security-audit/2000/05/msg00132.html. So, to me, it is in the summary of bug 12916 that the word "bounce" is confusing. (Although, I must admit that this word does not appear in RFC 2034.)
Looks like I'm ready this time... Any suggestions on whether I should develop against a nightly snapshot or the last milestone?
these days the nightlies are quite stable.. worth developing on IMO
It seems like someone only needs to fix the "From:" line in "Edit Message As New" (in the Message and context menus) for this to work. I'm looking at RC2 (2002052006); I'm not sure if that was the case on the builds available when this was last discussed.
Wow.. It seems a lot of discussion has been done on this and I just want to add one small thing. The best way a spammer confirms your email address is by sending you a mail. If it does not bounce back.. you are in his list and then you will join many other lists. Can we could add a button for SPAM bounce on the tool bar (or context menu), which bounces the message back to the sender imitating that the address was incorrect. It would also need to add a few fake lines into the header so the spammer does not catch you.
regarding commend #46: note that 90% of spam email have fake sender addresses, so this wouldnt work. In any case this would be a feature different from ordinary mail bounce, so please file a new bug.
Already exist: Bug 109930
*** Bug 168497 has been marked as a duplicate of this bug. ***
QA Contact: lchiang → esther
bug 109930 and bug 12916 are both ASSIGNED, yet I can't find a difference between the two. Is this a dupe?
Now, I seem to be alive with development time again. Regarding comment 50, yes there is a difference. Bounce described for this bug is an enhanced version of forwarding. The bounce back mentioned in bug 109930 is a auto responder or auto reply mechanism.
No longer blocks: 11769
I would be very happy if redirection of emails would work. Bouncing is not the kind of thing I am interested in. But in my daily business work there are a lot of mails that I get which should have been addressed to somebody else. If I forward them, there is no easy way to reply to the original sender. That is very annoying. As I said: Having a possibility to redirect messages would make me very happy already. ============================ Furthermore, I would like to state here that I am quite disappointed about the development in the Mozilla mail/news client. Redirection e.g. is a very basic feature that is missing so long. And there is no progress in the development. There are lots of features in every new version of the browser module. But the mailer still looks like to Netscape 4 mailer. No real innovations, many basic features don't work reliably (autorewrap, line breaks when replying to format-flowed-messages) and obvious bugs are not fixed in years; it even seems that the mail and news component is ignored by the developers. Here some examples: Pop-up email notification indicates wrong number of new emails http://bugzilla.mozilla.org/show_bug.cgi?id=138631 Apr 2002, very basic, very obvious, probably easy to fix [FEATURE] Remember last selected message in a folder http://bugzilla.mozilla.org/show_bug.cgi?id=10872 Jul 1999, basic usability feature, very annoying From the 098 Word wrap is malfunctioning in some cases http://bugzilla.mozilla.org/show_bug.cgi?id=124113 Feb 2002, basic feature, obvious bug, annoying, still valid for 1.0.1 and also reported for 1.2 alpha Rewrapped quoted messages gets space-stuffed http://bugzilla.mozilla.org/show_bug.cgi?id=140884 Apr 2002, basic feature, obvious bug, RFC violation(?) New messages always appear at bottom even when the Inbox is sorted by date in descending order http://bugzilla.mozilla.org/show_bug.cgi?id=50938 Aug 2000, very obvious UI bug, very annoying especially in the news module that shows the same(?) behaviour. Your postings are never sorted correctly. Any comments? Maybe a developer or somebody fom the QA can comment on my impressions that there is no real progress in the development of the mail/news module. René
sorry to continue digress - i don't know about you, but handling 247 bugs in 14 days is nothing to complain about: http://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=& product=MailNews&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type= allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr& status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED& bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=& emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring& email2=&bugidtype=include&bug_id=&votes=&changedin=14&chfieldfrom=&chfieldto= Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0= noop&value0-0-0=
> I am quite disappointed about the development in the Mozilla mail/news client. This is so totally offtopic here. Apart from being wrong: There is a whole team dedicated to Mailnews. Always was.
I keep watching the progress. Let's see.
I'm mainly concerned about the Redirect function, but a bounce function would be cool too. However, as a far more useful feature, I suggest that we concentrate on the Redirect function first; this would really be great in terms of easing both office and home use of Mozilla. Thanks.
Hi again, Thomas (or whoever is in charge here), you might want to look at the Mahogany Mail open-source project found here http://mahogany.sourceforge.net/. They claim to have the Redirect function. Since it is open source, I am hoping that the legalities can be cleared with the Mahogany project with relative ease. Thanks.
Spandan: legal issues are only one problem (and just because they're both open source does not make that easy, either...not all open source licenses are compatible). It's doubtful that Mahogony's internal architecture is anything like Mozilla Mailnews'.
This is an important feature for situations where all headers need to be preserved exactly intact. Examples include reporting spam and getting tech support. Pegasus Mail has this feature; if you uncheck the "edit the message before forwarding" option, it forwards in this fashion. Headers are prepended (Forwarded-To:, Forwarded-By:, Forwarded-Date:, and of course additional Received: headers and so forth documenting the path that the message travels), but the original headers are all preserved. "Redirect" is probably the best terminology to use for this. "bounce" would lead to unfortunate confusion, since normally smtp servers "bounce" messages that are undeliverable. "Forward" is technically correct and is what Pegasus calls it, but users may associate that with the other two styles of forwarding (inline or MIME). "Redirect" should be as clear as can be to all concerned. It is _not_ necessary to let the user edit the message before redirecting; the whole point of redirect is to preserve the message intact. (That can also be done by forwarding as attachment, but many recipient mail clients don't handle that particularly gracefully, and if the redirecting user has nothing to add it leaves a pointless empty body.) Users who want to edit the message should forward it inline.
Is this bug same as "bounce junk mail" (RFE to junk mail feature)? Or there should be open another bug? Tnx
Eugene: No. Other than having a similar name, this feature is not at all related to forging mail server bounce messages. That's bug #109930. This bug is about being able to forward a message to another person with the original headers intact (rather than by encapsulating it in another messages, which is how regular forwarding works)--this is useful in office environments, but has nothing to do with spam fighting.
Comment 60 is a perfect example of the kind of confusion I was talking about (in comment 59). That's why I say that the UI should use the term "Redirect". The term "Bounce" should be reserved for the sort of thing bug 109930 is about, since it has been used that way as long as sendmail has existed, and we already have two kinds of Forward (inline (the old way) and as an attachment (per MIME)). "Redirect", however, has no other meanings (related to email) except for what this bug is about doing, so that is the term to use.
Re 'bounce' confusion. Indeed, I was searching for a bug, and the term 'bounce' (IMO) is misused here, and, as such, caused me to have to read through the whole bug to find out that it isn't what I was wanting. I suggest removing 'bounce/' from the summary, since the term is more commonly used in the other context (as in mail.app). Max.
Max: I think the term "bounce" should remain in the summary, because removing it would probably lead to dupes, since there is at least one significant mail client (I forget which) that calls it that. Also, reading the whole bug should not be necessary, since it is clear from the description of the bug, and even more clear from comment 4, that this is not similar to a mail-server bounce. When I spoke of using "redirect" instead of "bounce", I was talking about the user interface in mail/news, not the summary in Bugzilla. (False positives in a Bugzilla search are better than having someone miss finding the bug and filing a dupe.)
Most linux mail clients support that feature and all of them I know call this "bounce". So the term "bounce/redirect" in the UI would probably make things clear to both Windoze and Linux users. *Should* there ever be a "bounce back" function (hopefully not) it should be called "bounce back to sender" in the UI to point out the difference. IMO the UI for this feature should not allow any manual modifications to the original message. So either show the standard compose window with the original message, but nearly all of the input fields like message text, subject, attachments etc. disabled, or just show the dialog that allows for reciepients and identity (for resent- header info) selection.
Maybe "Allow redirect (bounce to new recipient) of mail messages" would still allow the keyword bounce, but make it clear that it is not bounce back.
*** Bug 194786 has been marked as a duplicate of this bug. ***
This bug has been open for nearly four years due to a fundamental problem in the way projects like Mozilla work. Namely, people like Thomas Swan and myself and others who are not involved with the Mozilla project, but would love to implement it, can't. Sure, we have access to the source, but the fact is that the Mozilla source is a huge and complicated beast that is not at all friendly to newcomers. Thus, only very, very rarely will something get implemented by a developer who hasn't been working on Mozilla for quite some time. I just spent a good two hours poking through the MailNews source, and all I've come away with is a vague idea of where I *might* be able to begin implementing this. Problem is, everything is so interrelated that I haven't got the slightest idea whether I'm overlooking something or whether something I do might break something else. This is a very simple change. All that needs to happen is the same functionality used for "Edit As New", except instead of *my* address being pasted into the "From" header, the original sender's address should remain. Perhaps to stay compliant with the RFC we'll need to add a new header or two. No big deal. This is easy, easy stuff, but it's not going to get implemented until someone more involved with MailNews either does it themselves or provides a starting point for those of us who haven't got a clue where the change needs to be made. There is no reason this should have been left sitting for four years, especially with the original submitter and many others itching to implement it. This is a five minute change. All we need is a pointer in the right direction. Anyone?
> This is a five minute change. No, this is far from a 5 minute change. I have worked on Mailnews before, but I wouldn't know how to implement it without looking closly into the source (probably more than 2 hours). Given the way Mailnews works, the problem with features like this is usually the to pass the command and the relevant data to the right place in the code, you might have to touch lots of files to achieve that. It is unclear, if we can use the Edit As New datapath, it might alter the message in unintended ways or be hooked to the UI. > There is no reason this should have been left sitting for four years There is: This is a (IMHO minor) new feature, and there are lots of real bugs lying around. Something like 15000.
strike that "minor", before somebody argues about it. BTW: Even if it were a 5 minute change, it would still take several hours to get it into the Mozilla tree :-(.
Okay, I'll grant you the benefit of the doubt with regards to how long this modification would take, since I've never touched the Mozilla source. This has been mentioned in previous comments, but I'll mention it again: redirect support has, in the time since this bug was first opened, become a standard feature of mail clients. Mozilla is one of the few major mail clients that doesn't implement it. As a result, while I love Mozilla Mail and want very badly to use it as my primary mail client, the lack of this one feature is preventing me from doing so. Like many people, I use a server-side spam filter that requires me to submit spam by redirecting it to a special address, since the filter needs to parse the unaltered headers and can't handle the alterations caused by forwarding. I'm sure many other people are in the same situation. I really think redirect functionality is comparable to the "reply to all" functionality now found in almost every mail client. It's not necessary, but it has become so widely used that no mail client could get by without implementing it. This is hardly an enhacement; it's part of a standard featureset that is missing from Mozilla Mail and hinders our capability to compete with other, more feature-complete mail clients.
While this might be true, it is true for 80-90% of the enhancements requests. Not to talk about the bugs. If I were you, I'd look into nsMsgCompose.cpp (or nsMsgSend.cpp?), if you are willing to spend (at least) a few days on this bug. I fear I won't be able to help you further, though.
Regarding comment 71 and comment 72, I know the frustration. I had a likely candidate working over a year ago, but had no success taking it any further because of the size of the codebase and where some of the pieces are located. LXR provided some relief in navigating the codebase. Where I could use some help is identifying where and how I can change/override/add the headers for the message object to reflect the needed changes. If I could find that information, I'm sure I could get something back out pretty rapidly. I had the UI built for it and some of the changes to bring about the appropriate behavior at least for the interfaces and events. When I was working on it, I became overwhelmed and could not find where I could access and change the headers. I remember Seth and I had chatted once or twice, but most of the core and/or more active developers are involved in other projects and/or bugs of more importance that this; hence, it has been on the back burner for some time. My time to devote to this is random as well as I have had many other projects and demands pull me away from this.
Whiteboard: [should be a mailnews extension]
Given Seth quite brief comment (in the status whiteboard), and assuming it can in fact be an extension (not sure why such a feature should be one, because it's as useful as forward and quite little code), you might want to look at the MDN extension. It also messes with headers, maybe that helps you.
Sspitzer: What is your justification behind this being a mailnews extention and not part of the core? While I agree that Bug 109930 should be an extension as you marked it, why this one? I feel that it's part of a core mail program. For any given message you should be able to Reply, Forward, or Bounce it. Do you disagree from these are the core responses to a message (excluding deleting it, moving its folder, etc and other management functionality)
I agree with Steve - this is standard functionality in practical all Linux email clients and - as far as I know - several Windows clients. It does not clutter the UI, it does not require external programs, and it does not pose any additional risks. This is simply a missing feature.
To #76: This feature is not only part of most Linux clients, it's also part of many windows clients: Opera has it, Eudora has it, the Bat! has it, the small popcorn mail client has it. I don't know of any email client that does not have this feature but Mozilla. What I need this feature for? Often, I have to redirect messages to the right person in our company. If I forward them, all replies will go back to me, if I redirect them, the replies can go to the original sender. René PS: Concerning the 'bounce': To me a bounce is an error message if the mail cannot be delivered. My suggestion would be to delete the "bounce" from the subject if someone feels the need to change it. Why having two wods for one feature?
Actually, ages-old email clients such as "elm" have this feature since the Beginning of Time. It is not exactly cutting edge :-)
I agree with comment #71: this is an essential feature both in larger organisations and for homeworkers or anyone who tries to organise a networked team. Please proceed as follows: (1) has priority over (2) 1) get redirect working for one selected mail with an associated short-cut 2) extend redirect to work for a bunch of selected (marked) mails, where each will be sent individually to the same recipient, but all with just one command. Maybe the short-cut could also work on one or more selected mails, so that there would be no need to remember two different short-cuts? I am sorry that I have neither the time nor sufficient expertise to help with the necessary programming. Ian Leveson
Outlook and Outlook Express, today's mail client standards, do not have this feature (unless the very latest versions do). I may want the feature myself, being used to Eudora, but I can't honestly argue that the general population expects it.
Pine supports bounce. Isn't Pine a better indicator of the features that should be considered essential?
I just checked Pine 4.44, Pine does support this and has had it for sometime. Go to OTHER CMDS and there is *B*ounce. I personally think it needs to be labeled Redirect, but the *R* was already taken...
The ancientness of this feature, in both Unix and Windows email clients, is not in dispute. People are citing Linux clients, but Windows clients also (e.g., Pegasus Mail) have had this feature since before there was Netscape (though the terminology "redirect" may be newer). Regarding Outlook: Outlook is the canonical example of a broken, inadequate mail client that lacks important features. Its lack of this feature can in no way be construed as meaning that the feature is somehow unimportant.
Blocks: majorbugs
HI there... I too need this feature....I use PMMAil 2000 (www.pmmail2000.com) for my client and it has a bounce feature that works well...you might check with peter nielsen over there...tell him I sent you. I use the Mozilla client on my laptop at times and I forgot to check the "leave mail on server" and got mail stuck in mozilla. Also, it would be nice if I select a group of messages to forward or "bounce/redirect" that instead of making them attachments or inline that I be able to resend them out individually. Thanks, Leon Zetekoff, NCE Blandon, PA
I also have a use for this feature, but I found way around it in my case. All our mailboxes are on an IMAP server, and I changed the premissions on all inbox folders to give the postmaster account 'list' and 'append' priviledges. Now I can just drag and drop messages into the correct folder. This solution isn't perfect, because it bypasses the forwarding/processing rules of the SMTP server.
To make this list larger :)...bouncing like in kmail would be great..it seems it can help again spam....so, userfull...
Michel Brabants: Did you even read the preceding discussion? This bug has nothing to do with that.
Let me add my "me too"! I sorely miss this feature after switching from kmail and Eudora before that. I handle messages sent to a helpdesk, and sometimes folks forget to address their messages properly; those messages end up clogging my personal inbox. The redirect feature of kmail and Eudora makes short work of those pesky misdirected e-mails. Please include this feature in future releases if somebody has the time to work on it.
Let me add my "me too"! I sorely miss this feature after switching from kmail and Eudora before that. I handle messages sent to a helpdesk, and sometimes folks forget to address their messages properly; those messages end up clogging my personal inbox. The redirect feature of kmail and Eudora makes short work of those pesky misdirected e-mails. Please include this feature in future releases if somebody has the time to work on it.
Thomas: take a look at the patch in bug 61520 for an example of code that adds headers to a message. Also, I'm often around irc.mozilla.org in #mozmail if you have other questions.
Thank you for the pointer. I'll and see if I can get this working again before 1.5a. I'll try to catch you in irc over the next few days.
Hi, while we're waiting for a bounce/redirect feature to appear in Mozilla, I've written a tiny Python script that will let you do the same job. After installing it, instead of a regular bounce, you do a forward to "bounce@localhost" and set the Reply-To: header to the true bounce recipient - that's it. You can download the script from http://privat.hgesser.com/software/MailBounce/ Works for me, might not work for you. If so, please try fixing it, it's truly a tiny script :)
PLEASE PLEASE PLEASE try to implement this for 1.5, this important request is almost 4 years old, I think its time to bring this baby in! I can't believe I have to keep Pegasus Mail on the side *just* for this one feature... Not implementing a bounce/redirect feature severely limits the usability of Mozilla in certain office environments.
Four years is a long time indeed. I suspect Thunderbird/Mozmail code doesn't allow for a redirect function to be built in easily, otherwise the team would certainly have added it by now, wouldn't they? *sigh* I'd try to build it myself for you, but I'm stuck with this mouse brain of mine ;-)
I have to add my two cents. YES, PLEASE OH PLEASE ADD THE BOUNCE BUTTON.
Attached patch Patch v0.1 — — Splinter Review
I present this crude patch to help speed up development. It does provide the ability to bounce a single message to a single person. It needs a better UI, decent error and input checking and memory freeing properly, but it works for me and may work for people who need bounce now. It's a patch for Mozilla 1.4, and I'm running Linux gtk2. Anyone with a better knowledge of UIs/NSPR want to help out? :-) (In case anyone can't find it, the Bounce option is on the "Forward As" menu).
Anyone? I'd have thought at least one of nearly 70 Ccs and 80 voters would have wanted to try out bounce functionality. It does give you Bounce/Redirect, it's just not ready for checking into the tree. The more people try it, the more it can be improved and the sooner it can be checked in!
I would find this feature incredibly useful for: - forwarding SPAM unaltered - redirecting helpdesk requests to request-tracker unaltered I look forward to seeing it in Mozilla and wish I had the time & moz code experience to do it myself.
> - forwarding SPAM unaltered forward as attachment would forward unaltered. *This* feature wouldn't.
Luke, perhaps this could be done in a way so that we could package it as a XPI file? I'm willing to help
I know nothing about XPI so I'm not sure I can do much on that one. I can rewrite the patch as a mailnews extension (like Read Notification is), and if that can be bundled as an XPI it would be good.
I disagree on this being a mailnews extension - why not include it as a proper feature as originally requested? Especially if work is needed on the backend ...
'Extention' is a bit of a confusing term I think, as the mailnews extensions are built by default (eg read notification comes in every mozilla.org build I believe), its just keeping it under extensions means its easier to turn off if size is critical and you're building it yourself, and it keeps the codebase cleaner. The bounce patch could happily be an extension as it doesn't really punch any holes in the existing API, it just adds new calls. The XPI suggestion is just to give something that's easier to try now, I think. I hope that when the patch is of a decent quality it can end up in the main tree, and I've seen nothing that suggests otherwise. I haven't bothered to tidy up the patch yet as I'm not aware of anyone else using it. There's been talk on this bug of someone coming up with a GUI, and as thats the bit I'm least competent at, would they mind contributing it?
So what exactly would be needed for the GUI? If I understand this correctly, we would need a dialog that lets you specify an arbitrary number of To: and CC: addresses, but does not allow Reply-To:, Followup-To: or Newsgroup: addresses? Since the email text and subject must not be changed, we can simply avoid showing it, right? Another option that might be easier or more difficult than its own dialog would be to show a modified version of the window that gets shown when a "Reply" is done: the textareas would have to be read only, and only the "Send" "Address" and "Save" buttons should be shown in that case. It would also require the menu bar to be modified so that menu options like "spell" "quote" etc. are either greyed out or dropped.
The light weight POP3 client popcorn behaves this way: 1. Select a message 2. Press button [redirect] 3. Message is opened in a compose window 4. I can specify a new To: and I also can edit the whole message! 5. The message is sent with the same headers (if not modified in the composing window) Opera's mail client (version 7.20) behaves this way: 1. Select a message 2. Press button [redirect] 3. Message is opened in a compose window 4. I can specify a new To:, CC:, FROM etc. and I also can edit the whole message! 5. The message is sent with the same headers (if not modified in the composing window)
Kmail allows modification of subject and text while evolution does not. Is there a specification of what the correct semantics of "redirect" is? RFC822 does not seem to define this. From a logical point of view, allowing to modify the subject or body seems to be wrong to me (though it would be more easy to implement :) ). At least the client should not invite the user to do such a thing similar to how it should not invite faking the header fields (though one could do all these things and still conform to RFC 822 ...)
Editing of the mail body should *only* be available if a pref is set. This way we keep novice users editing the body. Something like: mailnews.bounce.editbody
I agree that editing the body should not be the default option for this feature. It seems to me that if you want to add comments of your own, forwarding is the better approach.
Having an editable body is very bad from a not-mauling-the-message point of view, so I haven't implemented it or even made it particularly easy to add. If we make it editable, then there will be no easy way to bounce a message completely as it was (even if you _don't_ edit it).
Having body and/or subject modified is not a good option at all. i would vote -100 for these to be available *at all*. the whole idea of bouncing a message is leaving a message as-is if you want to modify it, why not just use forward option??
Equate this feature to getting snail mail addressed to someone other than yourself, you slapping on the correct address for that person, and then putting it back in the mail, WITHOUT opening the envelope. That's all this "redirect" feature should do. It should relabel the *unaltered* message with a new "To:" address and change the "From: someone@somewhere.com" field to something like "From: someone@somewhere.com (via me@here.com)". That's all it needs to do. A "bounce" feature is something entirely different. "Bounce" would send the message back to the sender as "undeliverable" or "refused by recipient" or something to that effect. I don't personally care for such a feature, but the "redirect" feature is something I would find highly useful.
I agree with Owen. Please let's call this "redirect" to avoid confusion. I just verified Luke's patch (Win2k) - while I agree that appending to from the string " (via newsender@domain.com)" would be helpful, he does add a number of new "resent-from" headers.
Perhaps, the ability to edit the message should be a preference. There is a utility to it, such as annotating something for someone and them replying to the original sender or changing the priority of an incoming message as you redirect it. Luke, thank you for the patch, I'll give it a try on a linux system this weekend. p.s. Sorry, I've been away from this way to long.
However if we wave the message near a compose window (for editing) then the compose window gets to reMIMEify it as it sees fit, which I personally view as a Bad Thing. If you want to pass a message on with annotations then surely forward-as-attachment lets you do that?
Luke has the right idea. If you want to add to or change the content of the message, then you should be "forwarding" it as an attachment. I don't think we can call sending a modified message to a third party a "redirect". Simple redirection is what this feature needs to accomplish. Forwarding as an attachment accomplishes the annotation task and should be used for that purpose.
Feature request: Could you please make sure this feature works with email messages attached as enclosures to bounce notifications, and to make sure that the To:, Cc: and Bcc: lists are modifiable? I'd like to be able to resend a message that I misaddressed without re- composing it or forwarding it.
GUI: As in good ol' pine, the "redirect" button or menu item should simply prompt you for a new "To:" destination. Either mailnews's multiple-line entry box from the Compose window, or just one line, where it's up to the user to just write a comma-separated list of users.
The patch pops up a box you can key addresses into, but it means you can't pick anyone out of your address book. Really the GUI needs to look like the top of the compose pane, so you can enter addresses or pick from the address book, and have autocompletion.
I wonder if it makes sense to allow CC: and Bcc: addresses too - most otehr clients including evolution seem to support that. Would that be fine with the backend?
Resent-Cc and Bcc wouldn't be a problem to add.
>Feature request: Could you please make sure this feature works with email >messages attached as enclosures to bounce notifications, and to make sure that >the To:, Cc: and Bcc: lists are modifiable? >I'd like to be able to resend a message that I misaddressed without re- >composing it or forwarding it. Michael S. Fischer: for that intention you have the option (already implemented on Mozilla) "Edit as New", on the contextual menu of a message (in your case, you should select a message in your "Sent" folder).
knocte: Your solution depends on the user having the message in his Sent folder - an assumption that is not always true. My solution is better because it would work whether or not the sent message was at hand. My solution is also more convenient, because it's faster to re-send a bounced message in the context of examining a bounce notification than it is to dig through a potentially large Sent message folder, looking for the original.
>Your solution depends on the user having the message in his Sent folder No, you can "Edit As New" a message that is on your Inbox folder (I mean, any folder). >an assumption that is not always true. On my last comment, I said "on your Sent folder" because I was trying to apply your needs to the solution. You said you could misaddress a message (you realize that the address was wrong, or received a bounce notification), that's because you had already sent the message, so I told you to look on your Sent folder. >My solution is better because it would work whether or not the sent message >was at hand. My solution is also more convenient, because it's faster to >re-send a bounced message in the context of examining a bounce notification >than it is to dig through a potentially large Sent message folder, looking >for the original. Sorry but I don't think this RFE focuses to that particular solution.
knocte: Sorry, but you're wrong. I appreciate your help, but in order for the UI to work as I and many others expect it to work, fixing this bug is a dependency.
> knocte: Your solution depends on the user having the message in his Sent > folder - an assumption that is not always true. My solution is better because > it would work whether or not the sent message was at hand. My solution is > also more convenient, because it's faster to re-send a bounced message in the > context of examining a bounce notification than it is to dig through a > potentially large Sent message folder, looking for the original. Michael, maybe i am not following you, but you cannot resend a message that you don't "have at hand" ... How do you really see this? In any case, whether you will be using "redirect/bounce" or "edit as new" you must have found an original message for that purpose.
Konstantin: The message will be at hand because in many cases it will be attached as-is to the bounce notification. Try it yourself: Send a message to an invalid user, and then open the bounce notification. The message will be attached. Open the attachment. From there you should be able to choose an option to re-send it (but as of now you cannot).
So really that's another bug. In Mozilla talk, the "Edit As New" option should be enabled for messages that are attachments of other messages, but isn't (bug 218912). "Edit As New" is cleaner, as it would mean that the To: field is correct, whilst if you bounce it the To: field will be wrong (as the Resent-To: field is filled in instead). From a technical perspective, I would have thought that the fix of them would be similar - in both cases you need to get an input stream on the correct sub parts of the message. However I suspect it would be slightly easier to have "Edit As New" enabled for sub-messages as if you want to permit it to be bounced you somehow have to stop it MIME-processing the subparts. I haven't really got the time to investigate how to open the sub-part as a stream myself, although in a week or two I'll try to rehash the functionality of the current patch into something cleaner and more extenstion-y.
Regarding Comment 127, that is definitely another bug and not related to this one.
I agree with comment 128. I think that the RFE which Michael Fischer describes should be opened as a new bug, called something like "Resend message from attachment in bounce notification". I can't figure a shorter form to describe the bug proposed.
*** Bug 222113 has been marked as a duplicate of this bug. ***
> Really the GUI needs to look like the top of the compose pane, so you can > enter addresses or pick from the address book, and have autocompletion. This may be trivial (I havn't tried it). Look into the XUL autocomplete widget, see <http://www.xulplanet.com/references/elemref/ref_textbox_autocomplete.html>, "searchSessions".
*** Bug 225522 has been marked as a duplicate of this bug. ***
4.5 years have passed since this enhancement has been suggested, Mozilla 1.6 is about, but still no bounce/redirect :-( <sigh>.
@ #133 From Stephan Petersen: Sorry but this isn't an enhancement. It's a standard feature! I don't know any mail client but Mozilla/Thunderbird/Netscape that does not have this feature. For those who don't understand that some people are missing this: If you are working in large projects or for customer care, you'll often get emails that you sent further to the person in charge. In those cases you can either forward the message or redirect it. If you formward a message, the final recipient cannot reply to the original sender using the reply button. If you manually amend the email adress to reply, the message still says "The person who forwarded this message wrote:". It is all a big mess. Thanks to all of you who tried to push this issue a little bit further. René PS: Does anyone of the Mozilla core team really care about this or are we entertaining ourselves here?
In Mozilla lot of the new features come about because a non-core developer sticks the effort in, either because someone wants it enough and has the skills, or because a group of people club together and buy programmer time (eg. the roaming profiles feature). It is increasingly common across many open source projects for features to be included as and when patches become available, with core developers concentrating on keeping the codebase bug-free and compiling as that takes most of their time in itself. After all, it isn't like there's a menu item for bounce that crashes when clicked or something.
*** Bug 231777 has been marked as a duplicate of this bug. ***
Just wanted to add my voice to the throng that need "redirect" as they have come to know it in, for example, Eudora. --MM
This is a very needed feature! I hate having to fire up another email client just to redirect a message.
Although I'm sure the last few messages were well intentioned, we all know this feature would be very useful; the number of votes makes it clear lots of people want it. When bugs fill up with "me too"s, they just become unwieldy. The issue isn't "do we need it?", but "who will code it?". I no longer have the time to do further work on this.
A previous comment alluded to the possibility that placing a bounty or reward of monetary value on this feature request would allow it to actually get done. What kind of $$$ are we talking about? If everyone here chucked a buck, would that be enough? Is that what it will take to get this much-requested feature added?
I'm not really sure, but looking at bug 124026 I suspect it took 4000-5000$ to get roaming profiles done. Bounce is much less complex than roaming profiles, but I'd guesstimate you'd still need about a quarter of the time. Of course it all depends on how well they know Mozilla and how much their time costs :-)
Thomas: in comment 73 you say that you had prepared a UI for this. Do you still have it? If you have some JS to handle this I may be able to graft it onto the JS menu functions. I'd be grateful as the UI is one of the two things about this bug I'd least like to spend time on (the other being multi-platform testing, which besides being a really tedious way to spend my evenings is limited to Linux and open-source Win2k compilers - hardly ideal). mailnews team: I've been looking at pulling this out as an extension as has been suggested. A probably-silly question, but how do you generate the binary contract IDs? The text ones are explained on mozilla.org but the binary ones weren't immediately obvious. Also I note that quite a fair percentage of the MDN stuff leaks out into the general mailnews UI JS (menu items etc) - is this considered acceptable for an extension?
*** Bug 125026 has been marked as a duplicate of this bug. ***
I've built a trunk-mozilla with the above patch and it works for me. So I understand that only some cleanup is needed here to get it in? Is some mailnews developer here who can look at it to get it done. Most of the work should be done and ready.
Attached patch v0.02 — — Splinter Review
this patch is renewed against 1.7b and there is a small fix in JS to break the action if more than one message is selected.
I understand that the UI is not ready because the addressbook-hook is missing. But there is no need for a UI for CC or BCC and such things. Bouncing is only a redirection to one other address. But autocompletion and address-book access would be cool. But for me it's not as important as the base functionality. So I really would like to have it in mozilla builds.
in addition to the `redirect` feature request, i can also add a `mass redirect` request. where multiple selected messages can be sent to another person as they were received. each as a separate message. `THE BAT` mailer has this. --> * select messages with CRTL * right click and select `mass redirect` for example * a small window pops up - enter the address to which you want to send the messages * all messages are sent sepatately - all of them are in the outbox this would mak the `secretary` case even better - in case there are 5 emails that need to be redirected to another person - no problem
in addition to the `redirect` feature request, i can also add a `mass redirect` request. where multiple selected messages can be sent to another person as they were received. each as a separate message. `THE BAT` mailer has this. --> * select messages with CRTL * right click and select `mass redirect` for example * a small window pops up - enter the address to which you want to send the messages * all messages are sent sepatately - all of them are in the outbox this would mak the `secretary` case even better - in case there are 5 emails that need to be redirected to another person - no problem
in addition to the `redirect` feature request, i can also add a `mass redirect` request. where multiple selected messages can be sent to another person as they were received. each as a separate message. `THE BAT` mailer has this. --> * select messages with CRTL * right click and select `mass redirect` for example * a small window pops up - enter the address to which you want to send the messages * all messages are sent sepatately - all of them are in the outbox this would mak the `secretary` case even better - in case there are 5 emails that need to be redirected to another person - no problem
I belive the "don't bounce more than one email" limitation is a bug onto itself, because I tend to bounce four or five emails on my own system per week to other computers in my network. However, we should limit how many addresses those bounces go to.
Why should we limit how many addresses those bounces go to? That makes no sense to me. I ought to be able to redirect the email to as many people as it should go to. The software should not implement some artificial limitation.
OK, it's all a problem of manpower. The limit that only one message can be bounced at a time was in the first patch also but the UI didn't catch it correctly. I agree that there should be no limit in the recipient list but CC or BCC doesn't make sense, do it? I know of pine and mutt on Linux and both do only bounce to "normal" recipients. In fact I didn't add a limit but catch the limit correctly. If I have time and know how to do, I will check if it is possible to bounce more than one message to a list of recipients. But note, that I'm not able to do the UI thing.
It's trivial to make it bounce more than one message. Just edit the JavaScript in mailWindowOverlay.js. Remove where it says 'if (messageArray.length != 1) alert("Only one message at a time can be bounced."); else {' and then replace 'BounceMessage(loadedFolder, messageArray, recips);}' with something like 'for (var i = 0; i < messageArray.length; ++i) { var a = new Array(1); a[0] = messageArray[i]; BounceMessage(loadedFolder, a, recips); }' I doubt this patch will get anywhere near Mozilla until it has a proper addressbook UI. That's probably the major stalling point.
Back in 1998, University of Maryland at College Park's email servers were brought down when someone left an account open on a lab computer, and another person adjusted the .forward to spam everyone. Two days later, it happened again. Immedately afterwards, the admins slapped in a "It won't work if you go over X people" limit. I was a tech aid with the college's computer services office, and was in the college newspaper's offices in the latter "Attack". Lets just say they got first hand knowledge of the problem. :) I do say, limiting bouncing to X amount of addresses may cut down on some inadvertant spamming. Of course, if a person's that brave/ignorant/etc, it shouldn't be hard coded (aka adjustable via hidden pref).
*** Bug 240976 has been marked as a duplicate of this bug. ***
I'm not sure I'm crazy about implementing this in the compose service - the compose service is a singleton, for one thing, a service, so it shouldn't have state like this. If you get multiple simultaneous calls to the bounce method, all hell will break loose. It needs to move somewhere else. I'll think about it a little - I suspect it could simply be implemented in js. Re picking addresses, we have an address picker - why can't that be used? If you're in the compose window, and click the Address button, a window comes up that allows you to pick addresses. Seems to me that same widget could be used for this...
As has been commented before, this really should be a mailnews extension, and making it an extension shouldn't be too difficult. I just put it in there initially because that's where I found the forwarding code :-) I did start picking apart a copy of the mdn mailnews extension as the starting point of a bounce one. Can JS both open the stream of the raw IMAP message and also use the SMTP send service? If so it could be JS only and everything gets a lot easier. I was sort of hoping someone could have a look round and find the appropriate address book chooser to use and come up with some JS to call it. I still don't really have the time (or the knowledge) to finish this.
IMHO this shouldn't be an extension. Bounce functionality is a rfc base functionality. Otherwise we could move the forwarding functions to extensions as well.
js can definitely stream the message and use the smtp service. And if there's something preventing this from working from js, then we can fix it. abSelectAddressesDialog.xul is what I was referring to. Here's a usage example. http://lxr.mozilla.org/seamonkey/source/mail/components/compose/content/MsgComposeCommands.js#1941
Cheers, I'll see if I can do a 100% JS version tonight.
Hmmm nsMsgCreateTempFileSpec is a C++-only call; it's not part of the public interface for nsMsgCompUtils :-(
you can write its equivalent in js, I believe. You can create a file spec and then set the path...you could create an nsILocalFile to create the path. Something like this...there's probably an easier way to do this. And eventually, we'll be getting rid of nsFileSpec and replacing it with nsIFile... something like this: var dirServiceClass = Components.classes["@mozilla.org/file/directory_service;1"] var dirService = dirServiceClass.getService(Components.interfaces.nsIProperties) var tmpDir = dirService.get("TmpD", Components.interfaces.nsIFile) var filespec = Components.classes["@mozilla.org/filespec;1"].createInstance(Components.interfaces.nsIFileSpec); filespec.nativePath = tmpDir.path; filespec.leafname = "nsmail.tmp" filespec.makeUnique()
*** Bug 245492 has been marked as a duplicate of this bug. ***
*** Bug 230928 has been marked as a duplicate of this bug. ***
*** Bug 242311 has been marked as a duplicate of this bug. ***
*** Bug 236859 has been marked as a duplicate of this bug. ***
Regarding patch v0.02 - it seems to me what's necessary is a generalization of the forwarding code rather than a seemingly separate implementation of. Now, the following: prompt("Please enter a recipient to bounce the message to."); is quite a bad idea as David has mentioned above. But instead of using the widget from the compose window - why should Bounce not use _the_actual_compose_window_, just like Forward does? As though the user had done an 'Edit as New', only with the 'From' rubrique grayed-out, a 'Forwarded From' rubrique similiar to the 'From' rubrique added to the compose window, and the address picker as usual. The message composition could be made read-only. Or not (maybe people would like being able to bounce edited version of messages). Just think of the oh-so-sweet consistency this would maintain.
I think using the actual window is equally as bad as just the prompt itself. Not only would you have to disable most of the widgets itself, but folks may confuse it as to being a forward window. BOUNCE DOES NOT MEAN EDIT! Pine doesn't have a "Edit and bounce" feature. It never had it! Creating a "Bounce to" window would be best.
(In reply to comment #168) > BOUNCE DOES NOT MEAN EDIT! In this case, it becomes mostly useless to me, and I should remove my vote. I require a redirect feature that allows me to add a passphrase at the top of a message for approval to an email list; also (but less important) when mailing list messages are rejected for being too large and bounced to me as administrator or moderator of the list, I often strip attachments, put them on the web site, and add a link to them in the body of the message (with a note identifying this as a list administrator action) - but I need the original sender to stay the same. There are legitimate reasons for editing redirects!!! Anne
> > BOUNCE DOES NOT MEAN EDIT! > In this case, it becomes mostly useless to me, and I should remove my vote. Yes, you should. The existing inline forward feature already covers the case where you want to edit. A redirect is specifically for the case where you want to send the message along exactly as it stands.
(In reply to comment #170) > > > BOUNCE DOES NOT MEAN EDIT! > > In this case, it becomes mostly useless to me, and I should remove my vote. > > Yes, you should. The existing inline forward feature already covers the > case where you want to edit. A redirect is specifically for the case where > you want to send the message along exactly as it stands. Recall that redirect retains the From: headers, while forwarding doesn't. So, there's a good reason to redirect rather than inline forward. There is no good reason to disallow editing, since it's a feature that people will actually use. If you think that editing is generally a bad idea, you can always require an additional click to enable it.
My thinking is that editing of bounced email should not be allowed at all. The reasoning behind it is this. Bounced emails are seen by many folks as having a clear, sealed envelope sent on to them. The content is assumed to be unedited from it's original state. Allowing a user to edit the data before a bounce can create misinformation about what was really said by the original sender of the bounced message.
again, *please* drop "bounce" from the lexicon of this bug - "redirect" carries all of the meaning and none of the potential confusion.
Well, there's Apple's Mail solution, where "(Modified by [name])" is added to the subject line of a modified redirected message. For the reason mentioned (modified "from"), forward does not do what I need. I can NOT use that to moderate my mailing lists. I MUST use redirect, as offered by Mail or Eudora. Anne
> For the reason mentioned (modified "from"), forward does not do what I need. > I can NOT use that to moderate my mailing lists. If you're not modifying the From: field, then you shouldn't be modifying the body either. Ever. Approval for moderated lists or newsgroups is normally done by adding an approval header, but I would consider any modification of the body to be wrong (at best a misrepresentation, very likely fraud, and possibly even identity theft) if the From header is not also modified to indicate the author of the revised message. I understand that's not your intention, but for moderation you really should be using a header, not making changes to the body. That is the normal way of doing it. And yes, I know that people who want to forge headers and misrepresent what other people said will find ways to do so, but I don't think Mozilla should be going out of its way to make this an easier thing to do. Adding a header (for approval, or to indicate who forwarded the message, or cetera) is acceptable, since a header is metainformation. Mail servers add headers automatically all the time (and in fact would be remiss if they did not do so.)
(In reply to comment #175) > If you're not modifying the From: field, then you shouldn't be modifying the > body either. Ever. It's the user who choses how to use the application, not application itself! Please do not introduce unneccessary limitations. > ... I would consider any modification of > the body to be wrong (at best a misrepresentation, very likely fraud, and > possibly even identity theft) if the From header is not also modified to > indicate the author of the revised message. Do you really consider email FROM header as something truthworthy? So funny! One can freely adjust the mail account settings to any arbitrary name and FROM address in 2 minutes. Prohibiting to change the message body affects only usability, not possibility. > I know that people who want to forge headers and misrepresent what other > people said will find ways to do so, but I don't think Mozilla should be > going out of its way to make this an easier thing to do. This is kind of security through obscurity. Changing the FROM field is so easy! If people will see the possibility to edit message without changing FROM address, they possibly would realise that the letter from bill@microsoft.com could have been actually sent by random@user.com
I agree with Steve's Comment #172: > My thinking is that editing of bounced email should not be allowed at all. The > reasoning behind it is this. Bounced emails are seen by many folks as having a > clear, sealed envelope sent on to them. The content is assumed to be unedited > from it's original state. Allowing a user to edit the data before a bounce can > create misinformation about what was really said by the original sender of the > bounced message. A "redirect" should be the original message, as it was originally sent, from the final viewer's perspective. If you want to modify things along the way, great - then it isn't a redirect, its a forward, and you should claim credit for it with new From and Date fields. Comment #174: > Well, there's Apple's Mail solution, where "(Modified by [name])" is added to > the subject line of a modified redirected message. That sounds better - if you modify the message, then it modifies the subject line. > For the reason mentioned (modified "from"), forward does not do what I need. > I can NOT use that to moderate my mailing lists. I MUST use redirect, as > offered by Mail or Eudora. Perhaps its just me, but I don't think that the central thrust of this feature was to help people moderate their mailing lists. I've always seen it as a end-user (non-admin) function for people to redirect messages to others without editing the body. I trust you when you describe what you need in such a feature, however I don't think its worth breaking the "bounce/redirect" paradigm for it in Mozilla. If you "MUST use redirect, as offered by Mail or Eudora" then I'd prefer that you do indeed keep using redirect as offered by Mail or Eudora. (In reply to comment #176) > It's the user who choses how to use the application, not application itself! > Please do not introduce unneccessary limitations. Well, on one level I agree with you. But, where do you stop? I mean, if you think that way, would you want the "From" and "Date" fields to be always modifiable in every message? And if not, why not? I mean, isn't that an "unnecessary limitation"? Perhaps the difference between "necessary" and "unnecessary" is if it breaks the expected end-user experience. Significantly increasing the ability to have false/incorrect/misleading "From" and "Date" headers in an outgoing message probably counts as breaking the expected end-user experience - and therefore we have a "necessary limitation" on "From" and "Date". Making it very easy to modify the body content of a message while retaining all the same headers (From, Date) that a typical end-user sees/uses for identifying the source of the message would count as breaking the end-user experience as well (IMHO) - and therefore we should have the "necessary limitation" on modifying the body of a redirected message. > Do you really consider email FROM header as something truthworthy? So funny! > One can freely adjust the mail account settings to any arbitrary name and FROM > address in 2 minutes. Prohibiting to change the message body affects only > usability, not possibility. I'm sure he doesn't consider it trustworthy any more than you or I do. You're missing the point - he's not saying that you *can't* modify the body field without adding new From/Date fields...its that you *shouldn't*. And what the "proper" behavior for a given action is what Mozilla tries to implement when adding features. > This is kind of security through obscurity. Changing the FROM field is so > easy! Again, we all know this already. > If people will see the possibility to edit message without changing FROM > address, they possibly would realise that the letter from bill@microsoft.com > could have been actually sent by random@user.com So, if I understand you correctly, you're advocating that we should put this feature in so that many more people would realize that you can modify messages and have them appear to the end user (unless they're displaying the "Resent-From" fields)? In other words, since we know the global email system is broken in some ways, let's just break it a bit more? Are you serious? Jonadab's Comment #175 lays out a pretty good solution to Anne's primary need: > Adding a header (for approval, or to indicate who forwarded the message, or > cetera) is acceptable, since a header is metainformation. Mail servers add > headers automatically all the time (and in fact would be remiss if they did > not do so.) Based on Eyal's Comment #167 - which is brilliant. I agree - "oh-so-sweet consistency:. :-)
Well, folks are expressing the security concerns with allowing folks to edit a bounce. Very much the traditional way was to send it whole to another email address, as-is. Pine does it that way. I'm not sure if there's an IETF RFC which says it has to be that way. Anyone know if RFC 2822 covers this? And yes, I'm using "bounce" which implies a user action instead of "redirect" which implies a filter action (which I also would like, BTW, but that's another bug).
Comment 177: > > It's the user who choses how to use the application, not application itself! > > Please do not introduce unneccessary limitations. > > Well, on one level I agree with you. But, where do you stop? I mean, if you > think that way, would you want the "From" and "Date" fields to be always > modifiable in every message? They are, actually! One can create multiple mail accounts in the same Mozilla profile with different email addresses and names and choose the arbitrary identity when sending the mail even with the current Mozilla. Mozilla still does *not* check that name is actually the same throughout the profile. Neither checks it that the sender's name is the same as the one stored in the system registry (on Windows) or in /etc/passwd (on *nix). ;-) And the typical OS does not disallow changing the system date (which is used for outgoing mail). Mozilla doesn't track /suspicious/ date/time changes. > Perhaps the difference between "necessary" and "unnecessary" is if it > breaks the expected end-user experience. ... and seeing no possibility to edit the message gives the false expierence that this could not be done. > I'm sure he doesn't consider it trustworthy any more than you or I do. You're > missing the point - he's not saying that you *can't* modify the body field > without adding new From/Date fields...its that you *shouldn't*. What does this mean - shouldn't? Sending email is not a binding treaty. For the morally "legitimate" usage see the initial bug report. > In other words, since we know the global email system is broken in some > ways, let's just break it a bit more? Are you serious? Indeed, here I see two aspects. First, I do not propose something hacking of the system or abusing it: the possibility is already in the system, can be (and is) used by people, so the only issue is the interface. Second, the system is not actually broken: the rule that the user-information is sent by the sender's software and no checks are performned clearly means that this information is completely under sender's control. This is the feature of the (current) email system, which I personally appreciate very much (looking from the position of abstract freedom). The solution on the bug I would prefer is adding a string like "(forwarded by ...)" to the Subject. (Of course the subject must remain editable!)
Vlad from Comment #179 > They are, actually! One can create multiple mail accounts in the same Mozilla > profile with different email addresses and names and choose the arbitrary > identity when sending the mail even with the current Mozilla. Yes, we know this already. We knew it in Comment #176 as well. I would expect that many or most of the people here have even gone to the level of telnetting to port 25 and writing a message raw at some point. > And the typical OS does not disallow changing the system date (which is used > for outgoing mail). Mozilla doesn't track /suspicious/ date/time changes. Yes, Mozilla does the right thing and uses the system date. Thanks for stating the obvious yet again. It is interesting that you seem to think that your description of how to change the From and Date of any given message somehow supports your case. Indeed, my take on it is the opposite - you've shown how one of Mozilla's central activities, sending a new message, does not make it easy to change the outgoing From and Date in its *design*. Yes, as we all know, you can create bogus mail profiles to change the From address - however, the support of profiles isn't *designed* to support changing your From address to whatever you want on the fly, it is instead intended to support the use of multiple mail accounts. In this case, we're talking about putting the modification of the From/Date in the *design* of the redirect functionality. There's a difference. >> Perhaps the difference between "necessary" and "unnecessary" is if it >> breaks the expected end-user experience. > > ... and seeing no possibility to edit the message gives the false expierence > that this could not be done. Yes! And certainly, we all know how crucial the "Mozilla Email ReDirect" functionality is to educating people around the world about spoofed headers. That being not crucial in the least bit. >> I'm sure he doesn't consider it trustworthy any more than you or I do. You're >> missing the point - he's not saying that you *can't* modify the body field >> without adding new From/Date fields...its that you *shouldn't*. > > What does this mean - shouldn't? Sending email is not a binding treaty. Shouldn't means "should not". As in, the point many people are making here is that while any given email application *could* modify the body (the data) of the message, it *should not* do so in our opinion - the only changes should just be additions the headers (the meta-data). Also, I'm in agreement with you - "sending email is not a binding treaty". Along those lines, I would add that "sending email is not swimming" and "sending email is not a chocolate cupcake". (Wait, wasn't this a Saturday Night Live skit? Yeah, it was: <a href="http://www.rangelmd.com/2003/01/update-mcdonalds-made-me-fat-lawsuit.html">SNL Big N Tasty</a> So, yes, its not a binding treaty per se. Unless, of course, two countries exchange the text of a treaty back and forth over email, in which case it may very well be a binding treaty. And before you go off ad nauseam on how you can fake email, how it is not secure, etc., just remember - you can fake many things in the non-electronic world as well. Signatures, contracts, money...whatever. That it is possible to have forgeries doesn't preclude any given communication/documentation method from being a legal document. Note that I'm not making claims on how wise(or secure or valid) it is to use a particular medium - I'm just saying that we (as in, overall technical people associated with Mozilla in some way (at least, in that we're reading this bug #12916)) would be mistaken to think that legal(ly binding) documents aren't sent all the time right now (for better or worse) via email. > For the morally "legitimate" usage see the initial bug report. No, I believe you're wrong about this. A five year old initial message doesn't give absolute determination on the focus and scope of this issue/feature. Instead, it is a starting point. As are all of the other bug reports that were made about "bounce/redirect" and were marked as duplicates (do a search on this page for "has been marked as a duplicate of this bug"). Indeed, we are (in part) debating the "legitimate" usage of the redirect function right at this very moment. > First, I do not propose something hacking of the system or abusing it: the > possibility is already in the system, can be (and is) used by people, so the > only issue is the interface. Yes, the issue is the interface. Specifically, what the Mozilla developers/community/whatever as a whole believes is legitimate in terms of functionality offered in the Mozilla user interface. In fact, at some macro level, Mozilla in many ways is just a user interface to SMTP, IMAP, POP, etc. > Second, the system is not actually broken: the rule that the user-information is > sent by the sender's software and no checks are performned clearly means that > this information is completely under sender's control. This is the feature of > the (current) email system, which I personally appreciate very much (looking > from the position of abstract freedom). Rule? What rule? Again, it seems that you're trying to claim that Mozilla should do something simply because it can. You are correct in saying that, as the "sender's software", Mozilla sends the user information - but you're making the wrong leap from the "sender's software" to the "sender". Indeed, Mozilla (the "sender's software") *could* do many things: - Add new meta-data(i.e. Headers) to the top of the message, perhaps "Resent-From:" and "Resent-To:" headers, while keeping the original headers (including Date and From) and original body the same - Modify the Date and From - Modify the Body - Add attachments, sending them with the new message - Add a big Mozilla logo, and link to http://www.mozilla.org - Send a copy of the message to the redirecting user's email address - Send a copy of the message to the original user's email address - Send a copy of the message to alt.stupid.mozilla.tricks - Send a copy of the message to the government - Send a Treaty to the U.N. ...however, it *shouldn't* do most of these things. Just because the sender's software can do all these things for the sender, doesn't mean it should do all these things for the sender. For instance, I don't think we need to include Treaty sending in Mozilla. I know, I know, perhaps that (as you've pointed out) "gives the false expierence that this could not be done." - but, that's just the type of sacrifice (leaving out a "Treaty Sending" option for the user) I'm willing to make. As far as abstract freedom, whenever I need to do that, "telnet smtp.server.name 25". Type away. > The solution on the bug I would prefer is adding a string like "(forwarded by > ...)" to the Subject. (Of course the subject must remain editable!) If it isn't obvious by now, that solution (to me) would be wrong. The solution I'd like to see would be as follows: - On a UI level, open up the same send/forward message window, except somehow tagged "Redirect" and without the possibility to add/edit anything except the "Redirect-To:" fields (replacing the normal "To:/CC:/BCC:" options) and the "Redirect-From:" field (the normal "From:" picklist of configured accounts). - On a protocol level, it would take the original message (with all of the headers intact), add "Redirect-To:" "Redirect-Date:" and "Redirect-From:" headers to the top, then hand it off to the outgoing SMTP server - which would then append the normal in-transit mailserver meta-data to the top of the message (ie. Received: from..etc.).
(In reply to comment #180) It's obvious that we have different opinions on what kind of software Mozilla would be if it were within our powers: a high-level system that implements secure/trustworthy message exchange (your opinion), or a swiss-army application, that implements a handy interface to "telnet smtp 25" (my opinion). Further details seem to be not so interesting for others. Perhaps we can continue flaming by email?
I'd agree that its obvious that we have different opinions, but I would disagree with your characterization of my opinion. I have no illusions that disallowing editing makes anything truly secure/trustworthy (hence my comments on how we already know how to spoof mail, dates, etc). However, I do think your "swiss-army" characterization of your opinion is right on the mark, which highlights the differences. The availability of such a swiss-army application would be great - I know I'd probably use it at least some, and I can see why you prefer it as well. However, the core question is if Mozilla is supposed to be this type of application. I would submit that it is not. That all being said, I agree, I think we have laid out our positions by this point.
Maybe instead of arguing what extra functionality to add to this feature (over next 3-4 major releases), we'd better push it through in its simplest and most desired by most voters form (redirect without editing) ASAP and then either file another bug for the extended functionality or write an optional extension that does all the swiss army style stuff and get the most basic thing done? I'd personally very gladly welcome an extra menu item "advanced edit" which would allow me to add/remove/edit any header or any part of any email and then save or send it like that, but it's not what I'd squeeze under the "bounce/redirect" bug.
(In reply to comment #178) > And yes, I'm using "bounce" which implies a user action instead of "redirect" > which implies a filter action (which I also would like, BTW, but that's another > bug). Kelly, I feel differently aobut the implications of 'bounce' vs. 'redirect' in terms of user actions - if I send an email to someone and their server rejects it (e.g. their mailbox is full), I say that it 'bounced' - the *server*, not the user, did that. Also, I don't read an exclusively non-user action from the word 'redirect'. However, maybe the disagreement we have indicates a need to think some more about other possibilities for the nomenclature of this feature? A one-word solution is nice (personally, I'd still vote for 'redirect'), but what about something like "forward original" or "forward unedited"? After all, this is probably best presented to the average user as a variation on forwarding. In terms of Anne's needs, perhaps the default could be that editing is disabled, and a menu options somewhere could be used to enable editing (with the accompanying addition of an "Edited by:" header), or perhaps a different version of forwarding could be added later as was also suggested, "forward original and edit" which would have the "Edited by:" header and maybe also a "modified by" appended to the subject, which Anne could easily remove if she wants. Shi.
any one have compiled thunderbird with the patch 0.02 and have binary for 386 or have made debian package ?
It is almost impossible to comprehend that a bit of *basic* and long-standing email client functionality like Redirect (or Bounce) is *still* not here after FIVE YEARS of talking about it. Now that Thunderbird takes plugins for this sort of thing, I'm starting to think it is completely impossible.
Attached file Bounce extension 0.0.3 —
it's REALLY development phase code. Only people who wants to help me with development should download and install.
(In reply to comment #184) > (personally, I'd still vote for 'redirect'), but what about > something like "forward original" or "forward unedited"? After all, this is > probably best presented to the average user as a variation on forwarding. Redirect is very different from forwarding, so if it is implememented, its name and its UI should be kept separate. When you forward a message, the "From" header is set to your address, so when the recipient replies, the reply is addressed to *you*. When you redirect a message, the "From" header remains the original "From" address, so when the recipient replies, the reply is addressed to the *original sender*. When people do not understand this distinction, it can cause serious problems for others. As one list author explains: <quote> Why do you insist that RRE subscribers not use the Eudora "redirect" command to pass messages along to others? The Eudora "redirect" command causes me endless headaches, and I do indeed insist that RRE subscribers not redirect my messages. Here is what happens. You redirect an RRE message to person X. Person X then wants to reply to you, thanking you for passing the message along. Their reply, however, goes to me, not you, and I have to respond and explain what the problem is. This happens all the time, and it is a major nuisance. It is true that, by using "redirect", you are protecting yourself against the risk of misdirected replies -- that is, replies that were intended for me. At the same time, however, you are also exposing me to the symmetric version of the same risk -- the risk that I will get replies that were intended for you. That is why I often say that "redirect" is literally immoral. Many non-Eudora-users do not understand the "From: ... (by way of ...)" header fields that "redirect" creates, and experience shows that no amount of explaining will suffice to get the concept across to them. Indeed, many Eudora users themselves do not understand these From: fields; they use "redirect" because they think it's just like "forward" but without those unsightly ">" intendations. And that's not all. When people redirect RRE messages to other mailing lists, I frequently get messages saying, "who are you and why are you posting to our mailing list?". I don't like having to respond to these messages, explaining that I had never heard of their mailing list and never sent anything to it, when as far as they can tell they have incontrovertible proof to the contrary sitting right in front of them. I also frequently get error messages that are automatically generated when someone redirects a message of mine to a mailing list that includes some bad addresses. I have taken these issues up with Qualcomm, which markets Eudora. They were completely unresponsive. Their approach was that it was unthinkable that any functionality should be removed from a program, and they asserted that any misuse of the command was the fault of its users. I disagree. Putting the "redirect" command where beginners can find it is like leaving a loaded handgun lying around, disguised as a coffee mug. It's bad design. "Redirect" should be understood as a type of forgery. (from http://polaris.gseis.ucla.edu/pagre/rre-faq.html) </quote> The need for redirect in the instances I've heard would be reduced if Mozilla allowed the recipient reply to a forwarded attachment message. Currently Moz1.8a2 lets you open the attached message, but in the opened view the reply buttons are disabled. (Anyone know why?) If redirect is implemented, the default UI should be designed so it is significantly easier to do a 'forward-attachment' than to do a 'redirect', so people will not use 'redirect' when a 'forward-attachment' would do. (Customization may allow people who know they really want a 'redirect' to change this.) If redirect is implemented, there could be some safeguards against mistakes like above. One idea is a whitelist of email addresses which can be redirected. The whitelist would be initialized with the user's email account address(es). The idea is to allow the user to redirect messages addressed personally to the user's account(s), but not messages directed to a mailing list (at least not without the user doing some extra work to add it to the whitelist).
Enabling reply from a forward-attached message is in bug 204350
I agree with the whiteboard. This should be an extension, so people who need it (mostly secretaries, administrative assistants, and the like) can have it installed and the rest of the population who have no real valid use for it won't be confused by it.
(In reply to comment #187) > it's REALLY development phase code. Only people who wants to help me with > development should download and install. hi everybody, few days ago, I've created an attachement to the bug -- it is extension to thunderbird, which allows to bounce emails. (bouncing like mutt or pine does). There was almost no responses to my post (exception is Warren Ernst -- thanks). And my question is: are you going to deliberate next 5 years on redirect/bounce dis- and advantages or maybe somebody wants to help me in extension development? "Core part" of bouncing mechanism works -- you can bounce messages. But I need help in work on the code - it's not perfect. I'm asking you to help me. Take a look in bounce.xpi:/BUGS file and try to write some patches. With no help this code will die. thanks, -- Pawel
Dear Pawel, Thanks very much for writing the redirect extension we've all been waiting for. You might try getting some code from Luke Ross, to compare, as he did some work as well on this in the recent past. You'll notice I call it redirect and not bounce - if you've read through the discussion on this bug you'll know why, otherwise I'll give a brief recap. A name is a simple thing to change before release, but once it's set it affects a lot about how a feature is understood. Why do I spend so much effort on such a seemingly trivial 'window dressing'? Because I have a strong interest in user interfaces and ergonomics. Redirect says exactly what it does. Bounce can be misinterpreted as sending it back to the originator. The fact that some people know the feature from other programs as 'bounce' should not hamstring us here. The connection (to the 'wrong' terminology, for those who need it in order to find the feature) can be made by adding keywords to the extension's blurb on the website, and in the helpfiles (e.g. "also known as bounce from other programs"), but I strongly feel we should call it only "Redirect" in the interface. I'd like to take a look also, but I'm in the midst of migrating from Mozilla Mail to Thunderbird - will it work as an extension for Thunderbird as well? Thanks for making it an extension, I think that addresses many of the concerns voiced above that it should not be available by default, only for those who know to look for it (and thus what it is that they want).
Pawel, thx for trying this - if you can attach the source in source form (e.g., zip up your source files and attach that), then it's a lot easier for people to look at them, w/o installing the xpi
Just rename attachment.xpi to attachment.zip and unzip it. Same about "chrome/bounce.jar", rename to "bounce.zip" and unzip.
I'm not an expert on the code, just an average user. I'm unable to install this latest extension. Not in Mozilla nor Thunderbird (both latest nightly). Do I forget something or should I use a stable release to test this new patch test?
(In reply to comment #195) > I'm not an expert on the code, just an average user. I'm unable to install this > latest extension. Not in Mozilla nor Thunderbird (both latest nightly). Do I > forget something or should I use a stable release to test this new patch test? please send me more detailed info about error/problems. extension was tested with thunderbird 0.7.2 but should work with all 0.7+ versions. I really don't know if with mozilla will be ok.
I don't know f it's the same problem, but this happens to me. When the browser downloads the extension, i got a warning "Do you wish to install Bounce Messages to your profile? This will mean it does not need reinstalling when you update your application. (Click Cancel if you want Bounce Messages installing to the application directory)" And then, even with "Ok" or "Cancel", it throws the error: "Failed to create bounce.jar You probably don't have appropriate permissions (write access to your profile or chrome directory). Error code:-214 " The browser is Mozilla 1.4 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/2003062) on Redhat Linux 9 I'ts the same error with Firefox 0.8. Hugo (In reply to comment #196) > (In reply to comment #195) > > I'm not an expert on the code, just an average user. I'm unable to install this > > latest extension. Not in Mozilla nor Thunderbird (both latest nightly). Do I > > forget something or should I use a stable release to test this new patch test? > > please send me more detailed info about error/problems. > extension was tested with thunderbird 0.7.2 but should work with all 0.7+ > versions. I really don't know if with mozilla will be ok.
I downloaded the extension. I tested with several HTML, OpenPGP encrypted/signed, plain text emails. Works for me! Some suggestions: - I also think this should not be called forward. But Redirect makes me think of URL redirection... Perhaps "Forward as original author" extension would be much clearer. Several extensions have very long names and I don't have a problem with that. - The CTRL-B shortcut didn't always work. I would prefer "CTRL-SHIFT-L" as this would be "kind of forwarding" the email (CTRL-L being the current shortcut for Forward) - When it has succeded it should follow the same behavior as sending a message (close the window). - Maybe also make a new button available in the toolbar - Provide an option to reset the time stamp of the forwarded message, permanently (from the options dialog) and per-message. - Provide a way to add a prefix to the subject OR the message (such as FW: or "Originally for: ---") that would indicate this message is being forwarded as the author.
Ref comment #198: Ugh, no. It shouldn't be called forward, but I'm find with bounce. I disagree wholly with your "make it more like forward" (CTRL+SHIFT+L) logic. And it should not, under *no* circumstances, allow you to change a darned thing about the message. Be that date or subject. Perhaps calling it resend? I like bounce just fine as a name, tho, since that's what I expect that to mean...
If a message timestamp can not be changed, it could be lost among the dozens of emails some people receive in their inbox (too "old" to show up). Digital signatures provide a way to preserve the original content time of creation. Content of the "BUGS" file: - bounce command should be unavailable when in offline mode (i suppose, what SendLater code won't handle this (it modifies Messaged-Id, etc..)) - ctrl-B combination doesn't work - add item to forwardAsMenu - if item in threadTree right-clicked and tried to be bounced, bounce-extension refers to selected mails instead right-clicked - complete DTDs (use bundle_composeMsgs) - add mail-icons before subject in bounceTree - [XUL] bad ?reflowing? when moving splitter bounce-toolbar-sizer - bounce xul overlays are too wide (bounce cmd available from too many places) - make progress-bar working; add counter "which mail is currently sending" (e.g. 2/4) - for 1 recipient it works; for more doesn't - investigate - files aren't deleted after sending (or failure) - bad non-iso8859-1 characters encoding in resent-to and resent-from - vk_return in listbox AddressingWidget adds new rows - VK_ESCAPE should close window - bounceWindow title is wrong (refered emails count, if one->subject || nothing || ??) - fcc or not message regards of prefs settings (?always do not fcc?) - create nice icon to show in extension window - add <em:updateURL> and <em:iconURL> in install.rdf - ... - bounce-pref.xul doesn't work [about] author: Pawel Krzesniak <email available in the original file> based on MsgComposeComands.js and addressingWidgetOverlay.js from mail.jar:messenger/messangercompose
Thanks for this great extension. Here's a few things that I found using TB 0.7 (20040616) under WinXP (no service packs. 1 - ctrl B will not work. The bounce interface does not come up. Could only bounce using right click/bounce. 2 - I have 3 accounts set up. No matter which account I use to bounce an email, the bounced email will allways get stored in the 1st accounts "sent" mail box. 3 - any chance on adding this into the filters? please please please :-)(In reply to comment #188) > (In reply to comment #184) > > (personally, I'd still vote for 'redirect'), but what about > > something like "forward original" or "forward unedited"? After all, this is > > probably best presented to the average user as a variation on forwarding. > > Redirect is very different from forwarding, so if it is implememented, > its name and its UI should be kept separate. > When you forward a message, the "From" header is set to your address, > so when the recipient replies, the reply is addressed to *you*. > When you redirect a message, the "From" header remains the original > "From" address, so when the recipient replies, the reply is > addressed to the *original sender*. > When people do not understand this distinction, it can cause serious > problems for others. > > As one list author explains: > <quote> > Why do you insist that RRE subscribers not use the Eudora > "redirect" command to pass messages along to others? > > The Eudora "redirect" command causes me endless headaches, and I > do indeed insist that RRE subscribers not redirect my > messages. Here is what happens. You redirect an RRE message to > person X. Person X then wants to reply to you, thanking you for > passing the message along. Their reply, however, goes to me, not > you, and I have to respond and explain what the problem is. This > happens all the time, and it is a major nuisance. > > It is true that, by using "redirect", you are protecting yourself > against the risk of misdirected replies -- that is, replies that > were intended for me. At the same time, however, you are also > exposing me to the symmetric version of the same risk -- the risk > that I will get replies that were intended for you. That is why I > often say that "redirect" is literally immoral. Many > non-Eudora-users do not understand the "From: ... (by way of ...)" > header fields that "redirect" creates, and experience shows that > no amount of explaining will suffice to get the concept across to > them. Indeed, many Eudora users themselves do not understand these > From: fields; they use "redirect" because they think it's just > like "forward" but without those unsightly ">" intendations. > > And that's not all. When people redirect RRE messages to other > mailing lists, I frequently get messages saying, "who are you and > why are you posting to our mailing list?". I don't like having to > respond to these messages, explaining that I had never heard of > their mailing list and never sent anything to it, when as far as > they can tell they have incontrovertible proof to the contrary > sitting right in front of them. I also frequently get error > messages that are automatically generated when someone redirects a > message of mine to a mailing list that includes some bad > addresses. > > I have taken these issues up with Qualcomm, which markets > Eudora. They were completely unresponsive. Their approach was that > it was unthinkable that any functionality should be removed from a > program, and they asserted that any misuse of the command was the > fault of its users. I disagree. Putting the "redirect" command > where beginners can find it is like leaving a loaded handgun lying > around, disguised as a coffee mug. It's bad design. "Redirect" > should be understood as a type of forgery. > (from http://polaris.gseis.ucla.edu/pagre/rre-faq.html) > </quote> > > The need for redirect in the instances I've heard would be > reduced if Mozilla allowed the recipient reply to a forwarded attachment > message. Currently Moz1.8a2 lets you open the attached message, but in the > opened view the reply buttons are disabled. (Anyone know why?) > > If redirect is implemented, the default UI should be designed so it is > significantly easier to do a 'forward-attachment' than to do a 'redirect', so > people will not use 'redirect' when a 'forward-attachment' would do. > (Customization may allow people who know they really want a 'redirect' to change > this.) > > If redirect is implemented, there could be some safeguards against mistakes like > above. One idea is a whitelist of email addresses which can be redirected. The > whitelist would be initialized with the user's email account address(es). The > idea is to allow the user to redirect messages addressed personally to the > user's account(s), but not messages directed to a mailing list (at least not > without the user doing some extra work to add it to the whitelist). > > >
Thanks for this great extension. Here's a few things that I found using TB 0.7 (20040616) under WinXP (no service packs. 1 - ctrl B will not work. The bounce interface does not come up. Could only bounce using right click/bounce. 2 - I have 3 accounts set up. No matter which account I use to bounce an email, the bounced email will allways get stored in the 1st accounts "sent" mail box. 3 - any chance on adding this into the filters? please please please :-)
Me again. Disregard item #2. It works fine. I just tried yoru extension in Mandrake 10.0 and also 10.1 beta with TB 0.7+ (20040818). Installation went fine but it doesn't do anything. The bounce GUI comes up fine but when I click on the4 send button, it's not sending. The status bar at this point remains empty. Also ctrl-B doesn't work. Have to right click and select bounce.
hi all, 1. after suggestions, the name of extension evolved. now it's "mailredirect" 2. i made project home page at http://mailredirect.mozdev.org 3. there is mailing list for the project 4. 0.0.5 version released -- some bugs killed (but not all critical) -- Pawel
Thank you sir!!!! ctrl-B works fine under XP. I'll try Mandrake tonite when I Get home. Another suggestion if possible. RIght now, re-directing to multiple users does work for me under XP but each user does not see who else got the email. Just wondering if it's possible to re-direct an email to many recipients and all recipients actually see the entire 'To' list. Another feature that would be nice but not a big deal is if we are able to 'CC' or 'Bcc' a recipient when I re-direct. Regarding those 3 new headers (Resent-From:, Resent-To: and Resent-Date:), where am I supposed to see them?
Just tried it in Mandrake 10.0 and the behaviour is the same as what I previously reported.
Nicely done. When listing the extensions under Tools|Extensions, the URL still points to this bug. It should be changed to http://mailredirect.mozdev.org/ , no ?
I've just released 0.0.6 version of mailredirect extension http://downloads.mozdev.org/mailredirect/mailredirect.xpi I need some help on following problem: Resent-{to,from} headers must be quoted-printable encoded. I have not found javascript method which can do it. There is nsIMimeConverter.encodeMimePartIIStr() but Components.classes["@mozilla.org/messenger/mimeconverter;1"] has no nsIMimeConverter interface. Is this a bug or I missed something? code: http://lxr.mozilla.org/mozilla/source/mail/extensions/newsblog/content/FeedItem.js#289 uses MimeConverter as I would like to. How can I encode Resent-*: headers? thx
As the "/mail/" in the path to FeedItem.js suggests, the interface nsIMimeConverter is not (yet) available in MailNews, only in Thunderbird.
I downloaded 0.0.6 and it works just fine for me. The only suggestion I'd make is capitalizing the other word components of the Resent-* headers. I see "Resent-from:" and "Resent-date:", and am used to seeing "Resent-From:" and "Resent-To:" etc. Doesn't hurt, but seems more consistant that way. Also, when I hit the "redirect" button, it sent the redirect, and left the redirect message window open. Is this a known bug?
>As the "/mail/" in the path to FeedItem.js suggests, the interface >nsIMimeConverter is not (yet) available in MailNews, only in Thunderbird. That just means that rss feed reading code is part of thunderbird. It doesn't say anything about whether nsIMimeConverter is available in Seamonkey vs. Thunderbird, since they share the same backend code, where nsIMimeConverter is implemented.
>>As the "/mail/" in the path to FeedItem.js suggests, the interface >>nsIMimeConverter is not (yet) available in MailNews, only in Thunderbird. > > That just means that rss feed reading code is part of thunderbird. It doesn't > say anything about whether nsIMimeConverter is available in Seamonkey vs. > Thunderbird, since they share the same backend code, where nsIMimeConverter is > implemented. Mmh, I just feared that my sentence was ambiguous as soon as I had sent it. ;-) Of course, the usage of the interface in TB doesn't say anything about the availability in SM. But the JS Components.interfaces object does not know about nsIMimeConverter in SM... (At least my two(?) weeks old debug version does not.)
I've tried version 0.5 & 0.6, on ThunderBird 0.7.3, installed on linux, and have few problems: 1. I cannot use CTRL+B to bounce, just the menue entry. 2. In no mail is selected, and I press the right button on an email, I can open the bounce window, but with no mail listed to be bounced. 3. When trying to bounce an email, the status line of the bounce window shows: "Delivering mail..." and the window stay open for few minutes, after which I get an error message about a timeout, and the mail was not bounced. Any idea?
(In reply to comment #212) nsIMimeConverter works in thunderbird 0.7+ (20040830). In stable 0.7.3 doesn't. Neil Parkway enlightened me.
(In reply to comment #210) > The only suggestion I'd make > is capitalizing the other word components of the Resent-* headers. I see > "Resent-from:" and "Resent-date:", and am used to seeing "Resent-From:" and > "Resent-To:" etc. Doesn't hurt, but seems more consistant that way. it is capitalized. > Also, when I hit the "redirect" button, it sent the redirect, and left the > redirect message window open. Is this a known bug? yep.
version 0.1 of mailredirect extension available on http://mailredirect.mozdev.org/ in my opinion it works stable. please try it -- maybe we could close bug #12916 after five years.. waiting for comments on mailing list http://mailredirect.mozdev.org/list.html or newsgroup news://news.mozdev.org/public.mozdev.mailredirect (mozdev/maduser)
A couple of points on the 0.1 extension: * Extension window should close after bounce is sent (maybe??) * Nothing is saved to the sent items folder * There is no indication from the mail icon that it has been bounced Other than that, it's a top extension! Thanks very much!
(In reply to comment #217) > A couple of points on the 0.1 extension: > > * Extension window should close after bounce is sent (maybe??) > * Nothing is saved to the sent items folder > * There is no indication from the mail icon that it has been bounced > > Other than that, it's a top extension! Thanks very much! It doesn't work on messages saved on local folders. Previous version did. 0.7.3 (20040803)
I've installed version 0.1, and still, no re-directing is possible. I select a message, redirect it, and after a long time get an error that it was not sent, and to check my account setting. I'm using TB 0.7.3 on linux. Any idea?
if there are any problems PLEASE open JavaScript Console and tell me what are the error messages. (In reply to comment #219) > Any idea? any messages on console? (In reply to comment #218) > It doesn't work on messages saved on local folders. Previous version did. > 0.7.3 (20040803) since version 0.1.3 works again (In reply to comment #217) > * Extension window should close after bounce is sent (maybe??) it is. but there was a little bug with closing - in 0.1.4 it will be better. > * Nothing is saved to the sent items folder is checkbox in preferences windows checked? > * There is no indication from the mail icon that it has been bounced do you think it should? what do the others think?
> > * Extension window should close after bounce is sent (maybe??) > it is. but there was a little bug with closing - in 0.1.4 it will be better. I'll watch out for this then, > > * Nothing is saved to the sent items folder > is checkbox in preferences windows checked? No extension preferences under TBird 0.7.x. Have it now under 0.8. Thanks > > * There is no indication from the mail icon that it has been bounced > do you think it should? Well, Reply and Forward both set icon overlays. It would be consistent for Redirect to do the same. It would mean that you could see at a glance whether emails had been Redirected. It would obviously have to work graphically with both the other overlays and match their appearance stylictically. I'm no graphic designer though I may be able to knock up something rough if required (I do know my way around photoshop).
Excellent. Just tested 0.1.5 on my Thunderbird 0.7.1 (Solaris). I look forward to getting a SPARC/Solaris 0.8 build and using it there. One comment, tho. It just has a "name" field in the window. Should it put a "Resent-To:" label in front of it? No reason for a drop-list, but just indicating what that field is might be a good thing... Thanks again!!! Any chance of this getting committed to the core functionality? Or is it considered too limited desireability?
(In reply to comment #222) > Any chance of this getting committed to the core functionality? i doubt, but last word is not mine. ask ducarroz, maybe. if he agree i'll happy :) sspitzer said "[should be a mailnews extension]".. btw: version 0.1.6 is available
*** Bug 262564 has been marked as a duplicate of this bug. ***
Blocks: 11034
*** Bug 267758 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
It seems that it's not possible to install mailredirect.xpi (0.5) in TB 1.0 nor in 1.0 RC 1 (german). There is a message that says "...couldn't install ... because it's not compatible to this version of TB (..only compatible to Thunderbird Versions 0.7 - 0.9+[!!]) This seems to be a bug in the way the version information is calculated; so I guess it shouldn't be a big deal to correct it. I also noticed this at another extension (http://forums.mozillazine.org/viewtopic.php?t=153392) so it really should be thought about this version information thing... Greetings, Jan
OK, so the Extension now works with 1.0: http://www.mozdev.org/pipermail/mailredirect/2004-December/000127.html If installed correctly: http://mailredirect.mozdev.org/installation.html Now that we're post-1.0, is there any chance of this key feature making it into the core? F
*** Bug 274411 has been marked as a duplicate of this bug. ***
*** Bug 277096 has been marked as a duplicate of this bug. ***
*** Bug 278622 has been marked as a duplicate of this bug. ***
(In reply to comment #227) > Now that we're post-1.0, is there any chance of this key feature making it into > the core? Anyone? I would also like to see this common feature make it into the core, still.
While I find this feature indispensible, what's wrong with having it as a separate extension? Not everyone needs or wants it.
(In reply to comment #232) > While I find this feature indispensible, what's wrong with having it as a > separate extension? Not everyone needs or wants it. ...and how does one install it into Mozilla? I only see Thunderbird instructions.
While extensions are great, it would be nice to have it built into the core. After a while, to install the mail client on another computer or reinstall, you'll need to have to install a dozen entensions to get everything you want. With computers getting more powerful and hard drives holding more and internet speeds making large files easy to download, it would be nice to incorporate the more requested features directly into the core. Anyone else agree? (In reply to comment #232) > While I find this feature indispensible, what's wrong with having it as a > separate extension? Not everyone needs or wants it.
I suppose if you're talking about the Mozilla Suite, then sure - as long as it's left as an extension for Thunderbird, whose philosophy is more along the lines of "keep everything that doesn't NEED to be core" in extensions"
> "keep everything that doesn't NEED to be core" in extensions" IMO, this functionality should not be considered peripheral to a modern mailreader. Failure to implement what is a standard feature of most other email applications could continue to impact on the broader adoption of Thunderbird and Mozilla. If the mantra really is "keep everything that doesn't NEED to be core in extensions" then how did Junk controls and RSS make it in? I would argue that redirect is much more necessary than these 2 items (and more!) currently in the core. We have some code, we have lots of noise and 168 votes, what is the problem here?
This is a standard email function like Reply or Forward; the bug has been filed against "Core." I suspect that the majority of the 168 voters for this bug would like to see it implemented in the core Mozilla code, but it is not necessary for everyone to spam the bug with their vote on whether or not it should be in the core. If someone is prepared to code the patch to implement it in the core, then post to the bug. Otherwise, unless someone tries to close the bug prematurely, this is not the proper forum to discuss advocacy of the bug.
(In reply to comment #233) > ...and how does one install it into Mozilla? I only see Thunderbird instructions. cite from project homepage: "The mailredirect extension for Mozilla Thunderbird (version 0.7 and above) and Mozilla Mail client adds..." (In reply to comment #235) > I suppose if you're talking about the Mozilla Suite, then sure - as long as it's > left as an extension for Thunderbird... it isn't. if mailredirect doesn't work with mozilla suite let me know. (In reply to comment #237) > If someone is prepared to code the patch to implement it in the core, then post to the bug. will this job appreciated? for me Whiteboard Status is clear.
See comment #188 for some ways redirect can cause more grief to the original sender and the recipient than the person using it. If implemented, several safeguards should be added to guard against inappropriate use. Safeguard ideas include: * Make it an extension so mostly only users that understand it and need it will install it and use it (what we have now). * Make it hidden by default, so mostly only users that understand it and need it will change the preference or customize the menu/tool bar and use it. * Use an originally-to whitelist by default, so users can only redirect messages sent to their email address(es), and cannot easily redirect by mistake a message originally sent to a wide mailing list. * Use a redirect-to whitelist by default, so users can only redirect messages to specific addresses (such as people in their organization, initially empty), and cannot easily redirect by mistake to a wide mailing list. * Make it harder to use by default than forwarding as attachment. One way is to add a confirm box that explains how redirect is different from forwarding and how it can cause grief to others). Maybe something like -------------------- Are you sure you want to redirect this message? Redirect should generally be used only when the receiver expects to receive redirected mails. The redirected message will be From: <sender's-email>, not from you, so all replies and complaints will go to <sender's-email>, not to you. To avoid this, forward the message as an attachment instead. [[Forward as attachment]] [Redirect] [Cancel] --------------------
> * Make it harder to use by default than forwarding as attachment. Forward is a toolbar button. I assume Redirect would not be, so this is already fulfilled. People who use redirect frequently can use a keyborad shurtcut, which is probably faster than a toobar button anyways, given that you have to enter or select the redirect address anyways.
I would like to have the possibility to get it like it is now, i.e. a separate button in the toolbar. We are all experienced people here and we need this feature for some "switchboard" functionality for mails from customers that are directed to the wrong person. A redirected mail can be answered much more easily than a forwarded mail. With a forwarded mail I have to edit the recipient, so that the mail goes to the customer and not to my co-worker. Then I have to edit the subject to remove the "Fwd:". Then I have to remove the body to get rid of the headers. Altogether a real pain in the ass.
No longer blocks: majorbugs
*** Bug 296068 has been marked as a duplicate of this bug. ***
So whats the current status on this?
(In reply to comment #243) > So whats the current status on this? > There will probably will be no change to the mailclient to get this in. The requested features are (partly) covered by the mailredirect extension available at http://mailredirect.mozdev.org/.
As I do really think that this feature is a basic feature of a MUA, what can be done to get this small addition in the base of Thunderbird?
Keywords: helpwanted
Please dont forget the good old Mozilla Suite aka Seamonkey. The extension is working with it, but you can see that it is designed for TB.
I think it's an important core feature too, but whether it's ultimately included within Thunderbird depends on the decisions of the developers. The rest of us can't do much more than cast a vote (above) in support of it. :) As for better Seamonkey support in the plugin... you should contact the plugin owners and ask. They won't necessarily read this bug report. cheers
I also think it's a essential (core) feature, but having it as an extension is also good! But there is one thing to the extension: It would be nice, if an email that you redirected would be only in the send folder, not in incoming anymore. Or at least that the message's status would be "replied" or "forwarded".
i think also this is a major feature needed in the core of TB ... But, by waiting, i whish to have this extension compatible with TB 1.5 beta 1 !!! It is not working with this version and i miss it :-)
(In reply to comment #249) > But, by waiting, i whish to have this extension compatible with TB 1.5 beta 1 !!! it will. just a little patience.
Shouldn't this bug be closed since the functionality is available as an extension?
This bug is about having the functionality as build-in part, not as extension. It is one of the standard mail functionalities you will find in *every* mail client by default, except Thunderbird.
> one of the standard mail functionalities you will find in *every* mail > client by default I know of a couple mail clients off the top of my head that don't have filter redirect functionality - Outlook Express and Outlook.
Actually, Outlook (2003) does have Resend functionality AFAIK. Look for it when viewing an individual message - in the "Actions" menu - "Resend This Message..." When you select it, you are presented with a Yes/No dialog stating "You do not appear to be the original sender of this message. Are you sure you want to resend it?" Isn't it interesting that this feature is now in Outlook of all places, but after six years of this bug being open in Bugzilla we still can't seem to agree to just put it in?
I said filter redirect, not UI redirect. If you want to resend an e-mail message in tb w/o filters, edit | message as new and change the to: field...It will be a new message, of course. I looked at my Outlook 2003 and it doesn't offer a resend ui action, though perhaps that feature's only available with the exchange server? Or my version of 2003 is missing something...
If you can't find the Resend feature in Outlook, try opening the message first (not just selecting it) and go to the Actions menu. FYI, Outlook's "Resend" feature is not the equivalent of a bounce or redirect. Although it preserves the original From header (which is good), it discards just about everything that is not immediately visible, including any custom X-headers. So it's useless for SPAM reporting/training, one of the major functions of a bounce feature. It sure would be nice if we could get a stable version of the Redirect extension (http://mailredirect.mozdev.org/) in the core code. That extension is apparently unmaintained, and it's also unstable when redirecting large numbers of messages.
I think it is very important to have a possibility to really forward the original message. Not resend it, and not bounce spam in this way, as some people fear. I need this a lot for sending mails to other people, especially when checking signatures in enigmail or similar. And I think it is not that far out, so there is (from my view) no problem to put it in. But Im glad if the extension/addon works.
In 1.5, you can forward it as a filter action, and of course, you can forward it manually withe ui.
Surely you are not suggesting that we should follow Microsoft's lead and leave important features out of Thunderbird just because they did. Such a policy would have prevented many other great features that have been added already. The previous poster was obviously overstating by saying this feature is built-in to every e-mail client by default. Nevertheless, it is built-in to many/most other clients, and it is certainly a desired feature to have in Thunderbird, judging by the duration of this bug and number of comments. Personally, I don't mind having to add the extension, since it has worked well so far. But I would certainly prefer to have it integrated into the core program, even if it is considered an "advanced" feature that is not easily-accessed. P. S. -- I just realized how difficult it is to post a comment when other people are adding comments at the same time!
Obviously that's not the policy - we have a lot of features that aren't in Outlook or OE! But I couldn't let that statement go unchallenged since it made me LOL :-)
> I said filter redirect, not UI redirect. If you want to resend an e-mail > message in tb w/o filters, edit | message as new and change the to: field... David, it sounds like you are misunderstanding the request in this bug. As stated by the poster way back in comment #6 on 4/4/2000, "I don't believe this blocks Bug 11769. This is entirely different and not filter based." To clarify my own position, I agree that having this feature as a filter action is NOT a good idea, but having it as a manual action to redirect individual or a group of selected messages IS desired.
There is a great summary on the SpamAssassin wiki explaining why this feature is necessary and what e-mail clients have implemented it already. Sadly, aside from AOL, Thunderbird and Outlook Express (NOT Outlook) are two of the only clients that are missing this capability. http://wiki.apache.org/spamassassin/ResendingMailWithHeaders?highlight=%28redirect%29 Please note that reporting spam is not the only purpose for this feature. It is also used in LISTSERV administration and many other instances, but this web page is one popular example.
I said every mail client has a redirect function, at least every serious one (leaving aside some mini freeware or shareware clients, that miss pretty much 80% functionality of a serios mail client anyway). It is like saying every browser has a bookmark funcition, which certainly does not hold true for some browsers, but these are not considered serious, productive software. Who would want to use a browser without bookmark functions and what for? That's the same with redirect in a mail client. And yes, Outlook has redirect, for ages. Does it keep all the headers? Who cares? Where is written that a redirect means you must keep all the headers? Who defines that term in such a way? Who said it may not be a "new" message? I don't care for any of these features. A redirect is a mail that I got and resend to a different address in such a way, that the *body* of the mail stays completely untouched and the mail *appears* to come from the original sender and not from me. _That_ is what I expect of a redirect, nothing less, nothing more. If it also keeps all headers, okay, fine, but I don't expect that. Nor do I know if that is a good idea (as my mail server may refuse that I send mails with certain headers in it, while the mail server of the original sender did not and my mail server did not care as receiver). As long as this will never block me from redirecting a mail, keep all headers if you like. The point is, I often get mails in my personal mailbox, that should have gone to a ticket system in our company or that should have gone to a different person in my company. If I forward these, the ticket system will get confused and make me the ticket owner and all replies go back to me and not to the *real* sender of the ticket. Same happens if I forward it to other people and they just hit reply. The only way working around that is creating a new mail, setting the original senders address into the reply-to header and copy/paste his text to the new mail; and that all manually. Still, I will be the ticket owner in the ticket system, as it's still my from line in the header and that's what the ticket system cares for. So the original sender gets a reply, but the salutation contains my name. That's why I can't use Thunderbird at work and still have to use Apple Mail instead (or I could use MS Entourage, pretty much Outlook for Mac).
I'd say that the average home or office user doesn't need/use this feature. The main people who use this feature are power-users who bother to report spam and some office people who user it as comment #1 describes. Judging by how most people won't use this, I think this is fine as an extension. Just place a link to it on some FAQ page and add an explanatory comment here.
"I'd say that the average home or office user doesn't need/use this feature." The average home or office user does not need 50% of all other feature TB has, too. Still we are not throwing them all out because of that, are we? And who are you to actually define what the average home or office user needs and what not? I wouldn't dare to define that for the rest of the world. This bug has 200 votes, looks like there are in fact some average users who care for it. How many other bugs (which you would call much more important for the average home or office user) have not even 100 votes? So not everyone needs it, okay, don't put into the toolbar by default. Make people first customize their toolbar if they need it. Or don't offer it as toolbar item at all, make it a menu entry. This bug is only about the fact that it should always be there by default (without installing any extension, that will not work together with your versions... I have only made very bad experiences with extensions in Firefox), not about the fact that it must directly hit the eye in blinking neon when you open TB for the first time as average home or office user. So what do you weed to have people take this bug seriously if 200 votes are not enough? Add a bounty to it? Okay, I throw $5 into the bowl for the person who gets the patch into the tree or for the Mozilla foundation if the programmer wants to donate it for the well of the project.
(In reply to comment #264) > I'd say that the average home or office user doesn't need/use this feature. OK for power user which uses this for Spam report or redistribution of mails going to adress like support@xxx.yy But i'm an office user, and i use the extension for this: some html mails i need to forward (with embedded images, etc...) are not well forwarded, and the final received mail is really unreadable. With a "resend" and not a "forward", i can make follow the mail without destroy it. This extension is really integrated into TB: an icon which is completly integrated with other originals icons, a menu entry, etc ... it is working well, and i don't know why it is not yet integrated into the core ... All the major job is already done, but, as it is an extension, it is not yet available for 1.5 RC1 or RC2 as max version is 1.4 and not 1.5.0.* --> so, without nightly tester tools, lambda user which use RC1 and want to use the extension cannot do.
> The average home or office user does not need 50% of all other feature TB has, > too. Still we are not throwing them all out because of that, are we? And who > are you to actually define what the average home or office user needs and what > not? I wouldn't dare to define that for the rest of the world. This bug has 200 > votes, looks like there are in fact some average users who care for it. How > many other bugs (which you would call much more important for the average home > or office user) have not even 100 votes? I agree with this. And we have to say also that perhaps the reason of this feature not being necessary for most of the people is its unavailability! If more people find it out in the TB core perhaps it becomes more used and more demanded. Just my 2 cents.
(In reply to comment #263) > And yes, Outlook has redirect, for ages. Does it keep all the headers? Who > cares? Where is written that a redirect means you must keep all the headers? RFC2822 section 3.6.6: Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system. A separate set of resent fields SHOULD be added each time this is done. All of the resent fields corresponding to a particular resending of the message SHOULD be together. Each new set of resent fields is prepended to the message; that is, the most recent set of resent fields appear earlier in the message. No other fields in the message are changed when resent fields are added.
As Pawel and others here indicated, this feature has been clearly defined in the e-mail standard RFC 822 (section 4.2) since August 1982 (23 years ago!) and updated in RFC 2822 (section 3.6.6) in April 2001 (4 years ago). They both state that the existing headers must remain intact. In addition, this feature is well documented in many other places, such as the SpamAssassin wiki I referred to in comment #262, as well as the home page of the extension that has been created to address this bug, http://MailRedirect.MozDev.org/ , not to mention in many of the comments above. I also discovered that there is an About.com article (URL below) explaining why this feature is useful for any average home or office user. I would argue that the mere existance of this article indicates that it is a mainstream action, as the whole purpose of About.com is to "offer practical advice and solutions for every day life." http://email.about.com/cs/usingemail/a/redirect.htm For all of these reasons, especially the fact that this functionality has been part of the standard e-mail specification for over 20 years, I think there is a valid and strong case why a redirect option should be built-in to the Thunderbird core program.
(In reply to comment #262) > There is a great summary on the SpamAssassin wiki explaining why this feature > is necessary and what e-mail clients have implemented it already. Sadly, aside > from AOL, Thunderbird and Outlook Express (NOT Outlook) are two of the only > clients that are missing this capability. > > http://wiki.apache.org/spamassassin/ResendingMailWithHeaders?highlight=%28redirect%29 > IMHO the above page is simply wrong - "Forward as Attachment" does forward messages with all the headers intact and a procmail recipee very similar (if not identical) to the one they give for Novell GroupWise would work. Message bounce is a useful feature, but let's not give wrong/misleading reasons for wanting it. P.S. Sorry for adding to noise level - I wish bug 225751 (special area for non-technical/political comments) was implemented...
(In reply to comment #270) > > http://wiki.apache.org/spamassassin/ResendingMailWithHeaders > > > IMHO the above page is simply wrong - "Forward as Attachment" > does forward messages with all the headers intact Then you are misunderstanding how this works. "Forward as Attachment" creates an entirely *new* message with *your* e-mail address, server, etc. in the headers. Yes, it preserves the headers of the original message in the attachment, but the message itself (which is what is processed by the spam reporting engines, etc.) is now coming from you, and your address becomes the one registered as the spam source in this example. > and a procmail recipee very similar (if not identical) to the one they > give for Novell GroupWise would work. Procmail is a wonderful and very powerful tool, but it is no substitute for redirect functionality built-in to a mail client. For one, it is not universally available, since it requires a shell account (which most people don't have) and knowledge how to use it. Secondly, this is obviously a last resort hack in the Groupwise example because it has been converted to an internal format that is otherwise unusable. > Message bounce is a useful feature, but let's not give > wrong/misleading reasons for wanting it. No offense, but apparently you don't fully understand the reasons (and there are many) why it is a necessary feature. After reading though most of the comments in this very long bug report, I haven't seen anyone pose a single reason why this *shouldn't* be implemented, especially since Pawel has already developed it as an extension. Someone just has to step up to the plate and commit to adding this feature into the core program.
The extension does not work with Thunderbird 1.5 as version <= 1.4. Any plans in this direction?
The extension works if you force compatibility with Nightly tester tools (http://users.blueprintit.co.uk/~dave/web/firefox/buildid/nightly.html) ... I'm using it since 1.5 beta2 without problem But this is not really for end user, this is why I find that it shouldn't be an extension but a component of TB ...
(In reply to comment #272) > The extension does not work with Thunderbird 1.5 as version <= 1.4. Any plans > in this direction? CVS snapshot is compatible, but I haven't tested it heavy. http://downloads.mozdev.org/mailredirect/mailredirect-cvs.xpi
*** Bug 323249 has been marked as a duplicate of this bug. ***
This should be in consideration for Thunderbird 2, so requesting a block. Can anyone produce an updated patch? Even if it's not a final version, it'd be useful. That should make it much more likely to get in. Otherwise, as the deadline approaches it'll be summarily denied because of a lack of patch if for no other reason. Like any feature request with no specific developer focusing on it.
Component: MailNews: Composition → Build Config
Whiteboard: [should be a mailnews extension]
Ugh. I really didn't mean to change the component. Sorry for bug spam.
Component: Build Config → MailNews: Composition
Flags: blocking-thunderbird2?
Bug 204350 appears to be fixed in TB2.0a (it prevented replying to a message forwarded-as-attachment). So users can forward-as-attachment and recipients using TB2.0a can now reply to the attachment (open the attachment and then reply), addressing the issues raised in the about.com article (comment 269). For casual users, forward-as-attachment avoids the "forgery"-like grief that redirect can cause for the original sender and the recipients more than the user (comment 188). If redirect is implemented, using a confirm dialog to suggest/recommend forward-as-attachment as an alternative (comment 239) is now more realistic.
(In reply to comment #278) > If redirect is implemented, using a confirm dialog to suggest/recommend > forward-as-attachment as an alternative (comment 239) is now more realistic. There are lots of reasons for using a redirect that still make redirecting a desireable feature. This has become even more true now that so many people use GMail as either their primary or backup mail provider. The easiest way to get old mail onto GMail is via a massive redirect. Other quality e-mail clients support redirecting (or "bouncing"). Thunderbird needs to include this feature to keep up with them.
(In reply to comment #279) > Other quality e-mail clients support redirecting (or "bouncing"). Thunderbird > needs to include this feature to keep up with them. I really really think this should only be available as an extension. No "normal" user would ever use this feature. I really like the simpleness of Firefox and I think that's what made Firefox what it is today. Dont clutter Thunderbird with features that should only be available as an extension.
(In reply to comment #280) > I really really think this should only be available as an extension. No > "normal" user would ever use this feature. This is not a large and cumbersome new feature. I don't see how adding it to Thunderbird bloats Thunderbird. And more importantly, extensions are used to extend Thunderbird's functionality to do things that are not very common in e-mail clients. Redirecting IS common and is a very simple feature. It doesn't make sense to me to have it only as an extension. Imagine the one time you need to redirect a message. Does it make sense to seek out, download, install an extension (and restart Thunderbird) just to perform this one redirect? I think lots of users use redirecting. I think redirecting is a main-line feature. When I think of extensions, I think of something that will render LaTeX in-line (which I think still has not been built; very disappointing). That to me is distinct from implementing a simple redirect (a feature that is one keypress away in, for example, PINE).
(In reply to comment #281) > > I think lots of users use redirecting. I think redirecting is a main-line > feature. > It would be interesting to actually get some numbers of this. I have no clue on how many uses redirecting. I personally never heard about anybody requesting it and I have used it myself.
I agree with Ted Pavlic. Redirecting email IS a common operation and it does belong in every email client as a built-in feature. While I'm at it, I just want to add that I'd like this feature to be added to Seamonkey. I don't use Thunderbird / Firefox because of all the extensions one needs to install.
(In reply to comment #280) > (In reply to comment #279) > > Other quality e-mail clients support redirecting (or "bouncing"). Thunderbird > > needs to include this feature to keep up with them. > > I really really think this should only be available as an extension. No > "normal" user would ever use this feature. We must have very different concepts of "normal". I use redirecting at least once per week. I agree that it's a must-have feature for Thunderbird.
Some people use it, some people don't. I think we need it, either as standard functionality or as an extension. But I don't think this is the place to have endless discussions about that.
(In reply to comment #282) > It would be interesting to actually get some numbers of this. I have no clue on > how many uses redirecting. > I personally never heard about anybody requesting it and I have used it myself. > 1) it is really helpful for little enterprise which have no large ICT resource or imap emails : just one adress like sales@blabla.com, support@blabla.com, etc... with only one guy reading the mail and redirecting the mail to the good recipients john.doe@blabla.com --> with redirect, John Doe can easily make a reply to the mail, exactly like he has directly received the mail. I'm using this sometimes ... and need it
(In reply to comment #286) > (In reply to comment #282) > > It would be interesting to actually get some numbers of this. I have no clue on > > how many uses redirecting. > > I personally never heard about anybody requesting it and I have used it myself. > > 1) it is really helpful for little enterprise which have no large ICT resource > or imap emails : just one adress like sales@blabla.com, support@blabla.com, > etc... with only one guy reading the mail and redirecting the mail to the good > recipients john.doe@blabla.com --> with redirect, John Doe can easily make a > reply to the mail, exactly like he has directly received the mail. > > I'm using this sometimes ... and need it Same for me: I forward mail to our ticket system quite often. A lot of our customers send mail directly to me as the key account manager and I have to redirect it to technical support, accouting etc. Especially with the ticket system, forward-as-attachment is not an option.
(In reply to comment #287) > > 1) it is really helpful for little enterprise which have no large ICT resource > or imap emails : just one adress like sales@blabla.com, support@blabla.com, > etc... with only one guy reading the mail and redirecting the mail to the good > recipients john.doe@blabla.com --> with redirect, John Doe can easily make a > reply to the mail, exactly like he has directly received the mail. > > I'm using this sometimes ... and need it > I use redirect every day for this very reason. Even people we do business with regularly will send stuff to our "generic" mail@ address. Redirect gets it to the appropriate party easily. I'm using the extension, but it doesn't mark which messages have been redirected, the way TB does with forwarding. This function really should be a part of TB 2.0. It's an email standard, and TB should support. Do what Apple Mail does... hide it so regular users won't see it, but have a way for advanced users to turn it on.
> (In reply to comment #280) > > I really really think this should only be available as an extension. No > > "normal" user would ever use this feature. I really, really think this is a basic feature (I use it normally, very handy) and should be part of integrated feature, not an extension.
(In reply to comment #282) > (In reply to comment #281) > > > > I think lots of users use redirecting. I think redirecting is a main-line > > feature. > > > > It would be interesting to actually get some numbers of this. I have no clue on > how many uses redirecting. > I personally never heard about anybody requesting it and I have used it myself. As the person who originally requested it, I can only say I need it, and use it. It's essential for me, and I don't care if it's embedded in Thunderbird or available as an extension, so long as it can be installed as a toolbar icon I can click on, and not some menu entry 15 clicks deep. It's HEAVILY used in tech support, for the reasons given by others.
This conversation has happened many times before on this bug page, so it's not really the place for repeating it. Nothing new is being added, so it's just spamming everyone.... We're all aware of how redirect and forward work, the philosophy behind extensions and the real-world problems with keeping them updated. If you have a strong desire that this feature not be added, please take it to the forums. If you want to evangelize this feature even more than it has been already, also please take it to the forums. Other than that, if someone has the skill to turn the extension into a patch, please do so! The developers will decide if it should be included or not. There are 210 votes for this bug, which is an exceptionally high number. But if there's no patch, then it'll likely just be ignored for deadline reasons. If they decide it shouldn't be a core feature anyway, then that'll be their decision.
(In reply to comment #291) I agree with everything you said except: > Other than that, if someone has the skill to turn the extension into a patch, > please do so! The developers will decide if it should be included or not. This is absurd. At least for significant features there should be a decision *before* anyone invests his time to provide a patch. If this is really for the developers to decide then what keeps them to decide *now* if a patch that implementes this will eventually go into the tree? That at least would be the normal way of software development: have a plan before you start to program.
(In reply to comment #291) > If you want to evangelize this feature even more than it > has been already, also please take it to the forums. Here's a link to the Redirect thread on Mozillazine: http://forums.mozillazine.org/viewtopic.php?t=109276 Let's take it over there, folks.
(In reply to comment #292) > This is absurd. At least for significant features there should be a decision > *before* anyone invests his time to provide a patch. > If this is really for the developers to decide then what keeps them to decide > *now* if a patch that implementes this will eventually go into the tree? Yeah, I know it sounds kind of absurd, but the mail/news module owners and peers have been fairly quiet on this feature. Nobody has said outright yay or nay, and none of them have taken it over. Which means the best chance currently is to just produce the patch and request a review. It's just the way things seem to work around here. If I knew how to code for Mozilla, I'd do it myself, but I'm only a lay coder at best. If nobody with the skills will do it (and fair enough if they don't want to risk wasting their time), then it'll just have to stay idle for now.
if a patch showed up that did redirect, I would work to get it into Thunderbird/SM. I just don't have time right now to do one myself.
(In reply to comment #291) > Other than that, if someone has the skill to turn the extension into a patch, > please do so! The developers will decide if it should be included or not. There > are 210 votes for this bug, which is an exceptionally high number. But if > there's no patch, then it'll likely just be ignored for deadline reasons. If > they decide it shouldn't be a core feature anyway, then that'll be their > decision. Why can't the currently available extension just be bundled with the normal Thunderbird distribution?
(In reply to comment #278) > So users can forward-as-attachment and recipients using TB2.0a can now > reply to the attachment (open the attachment and then reply), addressing > the issues raised in the about.com article (comment 269). This is a good point, but it still doesn't eliminate the need for a proper redirect function. For one thing, it doesn't address the recipients who don't use TB 2.x (or TB at all). As much as we'd all like to push TB, we can't expect every recipient of our forwarded e-mail to use it. And it doesn't help with the many other uses of redirect, especially when sending to an automated address, such as for spam reporting or moderating a mailing list. I've already posted the SpamAssassin example in Comment #262, and here is the LISTSERV example from the L-Soft List Owner's Manual: http://www.LSoft.com/manuals/1.8e/owner/owner.html#_Toc128536969 To approve postings with the above configuration, the editor simply forwards (or "resends", or "bounces"--the terminology is unclear between various mail programs) the posting back to the list address after making any desired changes to the content. This should be done with a mail program that supports "Resent-" fields; if "Resent-" fields are not found by LISTSERV in the headers of the approved posting, the posting will appear as coming from the editor's address rather than from the original poster. > If redirect is implemented, using a confirm dialog to suggest/recommend > forward-as-attachment as an alternative (comment 239) is now more realistic. This seems like a reasonable warning for first-time users, but it would certainly have to have an option to never be displayed again. Users who know what they are doing would hate to see this dialog every time they redirect a message. (In reply to comment #295) > if a patch showed up that did redirect, I would work to get it into > Thunderbird/SM. I just don't have time right now to do one myself. This is very encouraging to hear! Pawel, now that David has pledged his support, would you be willing/able to resubmit your extension as a core patch? Or, is there someone else here who can take this on? It seems that Pawel has done most of the hard work already: http://MailRedirect.MozDev.org/source.html
(In reply to comment #296) > Why can't the currently available extension just be bundled with the normal > Thunderbird distribution? The current extension isn't solid. It needs to be fixed itself before it's of the quality required to be distributed. For example, on the OS X version of Thunderbird, not only is the redirect icon in the main toolbar incorrect, but the icon that links to the address book within the "Mail Redirect" dialog is the spell check icon.
*** Bug 333583 has been marked as a duplicate of this bug. ***
Looks like we're still looking for a patch for this.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Keywords: helpwanted
(In reply to comment #300) > Looks like we're still looking for a patch for this. I'm working on the patch, but it doesn't go as smooth as I thought it will. Besides I suffer from permanent lack of time :(
*** Bug 339791 has been marked as a duplicate of this bug. ***
(In reply to comment #302) > *** Bug 339791 has been marked as a duplicate of this bug. *** Copy&paste for last comment from bug 339791: > That's not a forward, but a redirect. > *** This bug has been marked as a duplicate of 12916 *** Yes, long (6 years) discussed bug 12916 is what I need. And, I myself, don't see differences between "forward", "redirect", "bounce" and "resend", except that "bounce" suggests some automatization. Also, in TB there are menus Message / Forward Message / Forward as / Part of message and I not see differences here [because they work currently identically].
(In reply to comment #303) > Yes, long (6 years) discussed bug 12916 is what I need. And, I myself, > don't see differences between "forward", "redirect", "bounce" and "resend", > except that "bounce" suggests some automatization. A forward comes from you. A redirect (otherwise known as a "bounce" or perhaps a "resend") looks (at least with respect to the main headers) comes from whoever it originally came from. If I send you a message, it will be From me and To you. You can then "bounce" or "redirect" (a better word, perhaps) it to someone else, and it will show up in that someone else's mailbox; however, it will still be From me and To you. It'll almost I Bcc'd it to the third person. (however, there will probably be a "Resent-To" and possibly a "Recent-From" tag buried in the headers of the message) > Also, in TB there are menus > > Message / Forward > Message / Forward as / Part of message > > and I not see differences here [because they work currently identically]. Message / Forward has a hot key attached to it (Apple+L on the machine I'm using now). It is SUPPOSED to be identical to Message / Forward as / Part of Message. I think your point here is that "Part of message" could be removed and a simple "Forward as attachment" (Shift+Apple+L, maybe?) would be used instead. That's maybe a valid point. (it's just not very Mozilla; I think things are done this way for historical reasons)
> > don't see differences between "forward", "redirect", "bounce" and "resend", > > except that "bounce" suggests some automatization. > A forward comes from you. A redirect (otherwise known as a "bounce" or perhaps > a "resend") looks (at least with respect to the main headers) comes from > whoever it originally came from. All of this right, except, that "forward" is wrong word here. What you describe as "Forward", in reality is a deviation of "Reply to other recipient". But further I silent about this - how to _name_ isn't important for me here, here for me matter possibility itself. > > Also, in TB there are menus > > Message / Forward > > Message / Forward as / Part of message > > and I not see differences here [because they work currently identically]. > Message / Forward has a hot key attached to it (Apple+L on the machine I'm > using now). ^L (Ctrl-L) on PC. > It is SUPPOSED to be identical to Message / Forward as / Part of Message. Then this is bug in design. > I think your point here is that "Part of message" could be removed and a simple > "Forward as attachment" (Shift+Apple+L, maybe?) would be used instead. That's > maybe a valid point. (it's just not very Mozilla; I think things are done this > way for historical reasons) My previous mailer allows: 1. Forward letter - letter remains intact, only added some Resent-* fields. 2. Forward "from me" - in this case, original letter is included ("Content-Type: message/rfc822") into new letter with new header (with Subject field, equal to original Subject). In both cases, I may add prefix (like "(fwd)") to Subject field. And, this mailer allows to edit original letter _source_ (in Mozilla, you may do so by exporting to .eml, edit file, to import back), so in reality I may forward anything. In Thunderbird, all what it allows, is CREATE NEW letter and (1) include _source_ (with header) of original letter into attachment or (2) insert _body_ of original letter into body of new letter. There is *NO* possibility to FORWARD (resend/bounce/redirect) _original_ letter, so menu name currenly completely misleads users.
(In reply to comment #304) > (In reply to comment #303) > > Yes, long (6 years) discussed bug 12916 is what I need. And, I myself, > > don't see differences between "forward", "redirect", "bounce" and "resend", > > except that "bounce" suggests some automatization. > > A forward comes from you. A redirect (otherwise known as a "bounce" or perhaps > a "resend") looks (at least with respect to the main headers) comes from > whoever it originally came from. As the originator of this request, I should apologise for using the word "bounce", which I used because that's what Elm calls it (the "b" key). There was NEVER any intention that this request shoulod in any way whatsoever refer to any kind of automation. Nowadays "Redirect" is the accepted term. It is unusually disappointing that it is taking so long for such a simple, obvious, and necessary feature to be added. Its absence currently renders TB useless as an office mail user agent. ///Peter
This would be so useful to fight spam using dspam!
Blocks: 359226
I just installed TB 2.0, it *still* doesn't have a bounce/redirect function! This is really pathetic. Plus, the "Mail Redirect" extension is not (yet) compatible with 2.0. Almost 8 years (!) down the line and this important feature is still missing. Stephan
Hi I can live with the extension - version 0.7.4 works with Thunderbird 2.0 (new GUID: (un)install manually!!) To the discussion integrade or not I only can say: the idea of Firefox/Thunderbird was (AFAIK) to have a fast and tiny application with the possibility to install extensions at you own gusto. So: an extension is ok. But: if every user has to install the extension (and update manually) then some admins wish to have it integrated... There should be a way to integrate extensions for every user on the same machine... /ch
Flags: blocking-thunderbird3?
Assignee: thomas.swan → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: esther → composition
No longer blocks: 359226
Product: Core → MailNews Core
We're not blocking on this feature. AFAIK the backend code is in now, so making an extension for tb3 to enable the UI should be quite simple.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Hm, if the code is there already, why can't we have a toolbar button, that would be disabled by default?
FYI the non-rfc compliant version backend was implemented in bug 359226. The RFC-compliant version is not yet implemented yet. Bryan: any suggestions for where this should be added?
The [ other actions | v ] widget on the new headers is supposed to be the place for adding extra message actions that aren't part of the normal routine.
So, could we have the „Redirect“ option in "other actions" drop-down, like Bryan suggested?
(In reply to comment #315) > The [ other actions | v ] widget on the new headers is supposed to be the place > for adding extra message actions that aren't part of the normal routine. I don't think this would be the right primary location for this. Unless there has been a change in paradigm, the headerpane additions introduce a redundancy of features accessible through the main menus and/or the toolbar icons, for those users who like the buttons closer to the message. Thus, the primary spot for a "Redirect" function should be in the "Messages" menu. If wanted, an optional toolbar button could be added to the palette (after all, the toolbar customization was introduced to allow easy access to a feature, but don't have it visible unless it's wanted by a specific user). Only then, if considered important enough, it should show up in the header-pane menu. So, I agree with comment #313 as far as the placement is concerned.
I just want to draw attention to the fact that TB3-compatible version of the extension has been available since September. Perhaps it could be integrated into 3.1 at least?
It's been over 10 years for this bug/feature. I don't care where the button goes, or what it looks like. I want to be able to redirect (bounce) mail. I bounce mail 10 times more often than I forward it. I've bounced mail since the days of elm (I now use mutt as my main mail program). Bouncing is so old that it cannot be so difficult. It should be an integral part of the main code, not just an add-on. The redirect add-on worked fine in Thunderbird-2 but I have been without it ever since I upgraded to Fedora-11 with THunderbird-3.0b4. I use Thunderbird infrequently on my computer but my wife uses it full-time on her machine. If I had the skills I could try to fix the problem myself but I can at least do my bit by participating in the debugging. Regarding comment #318: Where can I find the TB3 compatible version of the redirect extension?
http://mailredirect.mozdev.org/ Having this in TB by default would be nice, though.
> It's been over 10 years for this bug/feature. It certainly has, and if I'd known it would take so long, I'd never have started it. The Mail-Redirect 0.7.4 add-in for Thunderbird works fine in TB 2.0.0.23 which is why I haven't upgraded to TB3 yet. Redirecting is an essential tool for any professional use of email, and it is regrettable that it is relegated to an add-in instead of being core.
(In reply to comment #321) > The Mail-Redirect 0.7.4 add-in for Thunderbird works fine in TB 2.0.0.23 which > is why I haven't upgraded to TB3 yet. As noted by Jonathan Vanherpe in comment #320 (!), the version hosted on mozdev.org works just fine with TB3.0 -- I just tried it with RC3 (yes, I know the final is out; I'm just a bit lazy suddenly), and didn't have any problems. I don't know why AMO doesn't have the proper version, but someone should probably ping the maintainer of the addon. One note on the addon UX: at present, it does not integrate quite as well with Thunderbird as would be necessary for a core feature, so it would take some additional work to polish this up, as well as the inevitable squeezing and shimming of code necessary to integrate extensions into the trunk. If someone is willing to take on that work, I (and doubtless several hundred others CC'd to this bug) would be more than happy to help test, debug, and comment on design choices. I suspect that's really what this bug is waiting for -- someone willing to put the effort of moving code into the trunk for this important niche feature. Any volunteers?
Thanks to everyone who pointed me to mozdev.org to get the add-on mail-redirect-0.7.4. I downloaded this from mailredirect.mozdev.org and the redirect works fine now using TB 3.0b4. Thanks again
I can't believe TB3 still doesn't have a built-in redirection function on board. What are the developers thinking???
Perhaps they think either or both of: - The feature is available as an extension. - If someone needs it in trunk he or she sure would be submitting a patch which does that, right? Bugzilla is for technical discussions, not for whining. Michael
Is there a possibility of making this an Official Addon? Meaning, an addon that MozMessaging will commit to keeping up to date? It doesn't have to be included by default. Being able to rely on an addon removes, in my mind at least, much of the need for a feature to be in trunk.
Do I understand the following correctly: the add-on does not work with Thunderbird 3.03? Anyway, in my case I cannot see any result. And can I conclude that if it does work, it does not leave the info line as it was originally. It's only about hidden info in the header. My co-worker on her computer receives a lot of email which are actually directed to me. If thy are forwarded normally I can't see in the info line who send it originally. And the reply goes to the wrong person (but I believe this add-on should solve that problem). So: what I need is an unchanged "from" in the info line of the message. The common way in Outlook to solve this problem is to send an email as a file. Thunderbird has the strange way of not seeing an .eml file as a file, but as a part of a message. This way you cannot move the file to it's folder. Does this problem belong here? Sorry if it isn't. But where can I ask it elsewhere?
(In reply to comment #327) > Do I understand the following correctly: > the add-on does not work with Thunderbird 3.03? > Anyway, in my case I cannot see any result. The add-on "Mail Redirect v0.7.4" works correctly with TB 3.03. > And can I conclude that if it does work, it does not leave the info line as it > was originally. It leaves all information in the header as it was. For the person you redirect it to it looks as if he has received a BCC. However in the headers is some data is added about resending. > It's only about hidden info in the header. From this you can see that the message has been bounced instead of sent as a BCC. > My co-worker on her computer receives a lot of email which are actually > directed to me. [ -- deleted -- ] Then this is the add-on for you. But still the question remains whether this functionality should be built-in directly or not.
Maybe I'm stupid how I try and how I look I see no difference at all with the normal forwarding. Not even the reply function works (to the original sender). May I conclude that it's not working on my computer? Or is there an easy check? Anyway, I doubt if the add-on is useful, because BCC has the same problem: it looks as if the forwarder is the sender....
More confused: Discovered that maybe the add-on I pickid op from the main site was the old version. So I downloaded the file mentioned above and with the link above, and got the warning: Mail Redirect 0.7.4 kon niet worden geïnstalleerd omdat het niet compatibel is met Thunderbird 3.0.3. Which of course is Dutch - it could not be installed because it was not compatible. But it was this file: mailredirect extension working in TB 2.0 (mailredirect_patched_fo_TB2.xpi) The file mailredirect-0.7.4-tb3-20091118.xpi gave no problems, but, again, doesn't do anything... as far as I can tell.
Rein - I think your question is more suited for http://www.mozilla.org/support/ .
Rein: http://mailredirect.mozdev.org/, see section "Thunderbird 3 support". Note: after you install this extension, make sure there's a "Redirect" button in the toolbar. This extension does not alter any functions of the default buttons.
Perhaps the single most important reason for adding this to the TB core is that since I updated to the 3.0.6 that comes with Ubuntu 10.4, the Redirect add-on has been unavailable because it hasn't been updated. Redirect is core functionality for professional use of email: its absence is a basic reason for TB being rejected.
(In reply to comment #334) > Perhaps the single most important reason for adding this to the TB core is that > since I updated to the 3.0.6 that comes with Ubuntu 10.4, the Redirect add-on > has been unavailable because it hasn't been updated. Redirect is core > functionality for professional use of email: its absence is a basic reason for > TB being rejected. Make sure you are using the latest Mail Redirect addon from http://mailredirect.mozdev.org/ which works with Thunderbird 3.1.2.
(In reply to comment #334) > Perhaps the single most important reason for adding this to the TB core is that > since I updated to the 3.0.6 that comes with Ubuntu 10.4, the Redirect add-on > has been unavailable because it hasn't been updated. I did not test the current mailredirect-Add-On (0.7.6.1 from 2010-09-04) with TB 3.0.x but according to the changelog it should work from version 0.7.4 on <http://mailredirect.mozdev.org/source.html#changelog>. If not, the current main developer Ronald Wahl is quite responsive in adding supported version numbers if that is all that's needed. > Redirect is core > functionality for professional use of email: its absence is a basic reason for > TB being rejected. I still like this feature to be part of the TB/Seamonkey core.
Quite sad that there is no warning what so ever that there IS a version for 3.1.2. When you get the message that redirect will be lost with installing 3.1.2 you believe it. I even looked here and found no comment on that issue. Is there a way to communicate to users that an update IS available? Or even better, make it a official ad-on of Thunderbird? I agree that this feature is ESSENTIAL for Thunderbird!
After posting this mail I got all the email adresses where the post is send to. Even the ones which are excluded. That is a real bug .... I hope
(In reply to comment #337) > Quite sad that there is no warning what so ever that there IS a version for > 3.1.2. > When you get the message that redirect will be lost with installing 3.1.2 you > believe it. > I even looked here and found no comment on that issue. > > Is there a way to communicate to users that an update IS available? Well, I believe that with the latest version (if it is installed in TB) the automatic add-on update is enabled for mailredirect. So in the future TB either check at update time if there is a newer version or if not available might check in the future if a version has become available at some later time. Of course that does not help with all the older version of mailredirect installed.
Thank you all very much, that works fine. It certainly would be more sensible if this was automated. Better still if it was added to the core...
The addon is working, but there is a big flaw with the latest versions of TB. The redirected emails are not marked with an icon. Anyway, make this a core functionality. It's a pity that something basic like this isn't included after sitting in the bug tracker for 10 years, although someone managed to hack it into an extension long ago. But i gave up hope long ago. It's not worth to talk about enhancements.
I 'm agree with other people here that said this feature have to be implement in the core program. LGDN.
Any plugin similar to https://addons.mozilla.org/en-US/thunderbird/addon/550/ that would be compatible with TB3 ? and, coming TB4 ?
Discussion about addons is offtopic here. Please discuss on addons.mozilla.org, the mozilla.support.* groups, or mozillazine.
It appears that existing extensions are no longer valid workarounds for this RFE. Thus, attention should be given to implementing the changes in the basic, "vanilla" Thunderbird.
What the "add-on supporter" don't understand here is that to many people bouncing and redirecting mails is CORE FUNCTIONALITY of a mail client and you don't implement core functionality via an add-on that may break with any new release. By that argumentation, why does Thunderbird even support forwarding of e-mails. We could implement forwarding via an add-on, too, but nobody would ever even consider doing so, because forwarding is also core functionality.
So - why we have to discuss or beg over 10 years, that mail redirect get a core part as in other mail programs, too?
Not enough votes? Not enough priority? (And there is an add-on, so the people who want to do it are able to.) For me this enhancement is more important than the change in GUI of TB5... How can it's priority be boosted?
Herre, after money, there is only "private services" left :) TB5 on rails already ? but TB3 still have bugs, and features broken compared to TB 1.5 ... why the hell do they make new release and just break what used to work, instead of improving things and fixing bugs ? Let's go back to bed, and dream about TB 1.6 ...
(In reply to comment #350) and also most of the other recent comments: [...] > Let's go back to bed, and dream about TB 1.6 ... Maybe that's the best you can do: whining here won't get the bug fixed — if anything, it will move developers *away* from fixing it. (Y'know anyone with deep knowledge of the Mozilla code who's willing to read 350 comments before even starting work? I don't.) If some bug (including, but not limited to, this one) isn't moving as fast as you want it to, get your hands into the grease and help fixing it yourself, or at least (by commenting elsewhere, e.g. in newsgroups), find someone who is willing and able to do it. Complaining from the side rails in the bug itself will get you nowhere.
There is nothing to do, no hands to put in grease, no dirty work any left. Code is already written, plugins are available. All Moz team have to do is to merge existing source code for plugins into main trunk. No need to enrole us and reinvent the wheel. Nothing to develop. Just merge existing code !!! It's virtually already fixed ! We just need the fix to be merged ! Grab one of the many plugins that does (or used to do it in close or far past), grab sources, and merge to trunk. We don't need developers to fix anything. We need admins to merge code. 350 coms in 12 years, that's less than one message every 12 days; I have seen Gentoo bugs fixed in 8 comms in 12 minutes (from bug appearance, to merge of fix to public server). You are whining about 350 comms. We are whining about 12 years to merge existing fix. Hope i can quit this bug without removing vote ...
How long has it needed to integrate Firefox Sync (Weave) into Seamonkey core code?
How long has it needed to integrate Firefox Sync (Weave) into Seamonkey core code (for comparison)?
Hi guys. When redirecting the letter, the headers Resent-To, Resent-Date etc. make duplicated. If one more time redirecting the letter, more headers are added.
Redirecting doesn't work at both notebooks no more ... it seem to send the mails and save the typical redirect symbol, but no emails arrive since hours. I have tested three email addresses at both devices with several emails. The emails stays somewhere in the nowhereland ...
Redirecting doesn't work at both notebooks no more ... it seems to send the mails and save the typical redirect symbol in the email folder, but no emails have arrived since hours. I have tested three email addresses at both devices with several emails. The emails stays somewhere in the nowhereland ...
Glutton.Vidal, there is no redirect in base Thunderbird, that's what this bug is about. If you are talking about an addon/extension, please reach the forum or author of that extension.
tl:dr... Is this the same as bug 492179??
No, it's not quite the same. That bug is about resending an already sent message to the same recipients again, while this bug is about redirecting a received message to other recipients. You could use redirect to resend a sent message to the same recipients too, but that would result in a slightly different mail with differen headers.
Ok Onno, got it. Thanx for taking the time to reply.
So ... it takes more than 13 years to implement a bounce, while it's a basic feature of Pine and mutt, and an add-on was available for 1.5 ? Rally looks to me like ... what are basic features for all other MUA are ... so complex for the Moz team that they are faster and quicker to implement tabs, transparency, multi-threading, locks, handle CSS, and support theme management ? HELL, WE ARE TALKING ABOUT BOUNCE !!! TAKE THE DAMN MESSAGE, AND SEND IT AS IS TO THE SMTP !!! cat message.msg | sed '[add a for: rule here]' | mail
The add-on is still available (see URL field in the bug description), but it should be core functionality. Is there a way to push this bug/whish higher up the "todo-list"? Or is the only way voting and are the almost 300 votes not enough to accomplish that?
(In reply to Herre de Jonge from comment #364) > Is there a way to push this bug/whish higher up the "todo-list"? Or is the > only way voting and are the almost 300 votes not enough to accomplish that? I think many of the commenters here are making the invalid assumption that there is some sort of Thunderbird Team who is explicitly ignoring this bug in favour of working on other things. Let me assure you that there is no team. There is no todo-list. There are only volunteers who will work on whatever they feel like working on. And that set of volunteers includes all of you reading this comment. So, having hopefully cleared that up, the only ways I see for anyone to push this bug forward are to: a) convince a developer that they should try to fix it (which will be made harder by the tone of the previous 364 comments), or b) decide that it's enough of an annoyance for one of you to attempt to fix it yourself (in which case I would be more than happy to help any of you get started). If any of the people reading this do want to take a stab at fixing this bug, please feel free to email me (at my bugzilla address), and I will help however I can. Thanks, Blake.
Blake, I feel deeply concerned by your message. Yes I really think that the team is ignoring some bugs. For two reasons: - there is a Moz team, who have been set up to contribute to the product quality - 2 years ago I had read that the team was composed of 99% volunteers, and a few core permanent paid developpers: the Moz Fundation collects money in order to be able to pay full time dev and ensure a minimal quality of service and product. Quality is more important to me than the number of claimed features. I don't mind about changelogs and adding (broken) features if the base product just does not work. I did not bookmark the page that was telling about paid dev, but it was an official message from the Moz fundation. So, your message is right about the 99% volunteers, but that's not what you seem to say: you seem to say that there are only volunteers: 100%. Whole != most. So to me, your comment 365 is wrong from the second line.
The extension moved from mozdev to sourceforge a while ago, so I'm updating the URL…
URL: http://mailredirect.mozdev.org → http://mailredirect.sourceforge.net
Onno, RFC http://www.ietf.org/rfc/rfc2822.txt and the original request at the top of this message seems to imply that the person who is doing the resending should know to whom the resent has been done. Currenty a green arrow (similar to forward) is added, but there seems to be no annotation in the original email (owned by the first recipient) that will recall to whom the resent was done. Any comments?
Sorry, but this bug is not the right place to discuss my add-on. Please see my address on the website, send to the mailing list or file a bug on my project's bug tracking system... You can configure Mail Redirect to save a copy of each redirected mail in your sent folder (which only works when you have setup your account to save messages in the sent folder). So you see your redirected messages in your sent folder and you can view the source to see who you have redirected the message to0, or you can add resent-to to the pref mailnews.headers.extraExpandedHeaders to view the headers in the header pane.

Since there is a critical security-issue with the last thunderbird-version that is supported by the add-on "Mail Redirect" and it seems there is a lot of interest in this feature it would seem appropriate to finally get this functionality integrated in thunderbird.

At the moment users depending on this feature are in a big dilemma that they just can't solve by themselves. Having to choose between not beeing able to work or knowingly putting your computer/network at risk is just beyond frustrating.

Regarding Mail Redirect:

At the moment Mail Redirect is not yet compatible with Thunderbird 78.. I'm still working on a new version that works with Thunderbird 78.. If you depend on this functionality, please don't upgrade to Thunderbird 68, but stay on version 68 and disable updates, until a compatible version of Mail Redirect is released.

Possible workarounds:

  • I can create a filter in Thunderbird with action "Redirect to". I haven't tested it, but it seems to be at least a workaround for some use cases.
  • It could be done on the server, depending on the server capabilities.

I agree that a proper bounce should be a feature of core Thunderbird.

Having lost this feature (via the Mail Redirect addon) in TB also is a serious regression to me. It would be really awesome to have it as a core feature indeed!

FWIW, there is a new add-on named "Simple Mail Redirection", that's a fork of "Mail Redirect", and that works with TB 78.

Thanks, that's good to know; a simple search on "bounce" in the addon page did not showed this one!

Enables Redirect, NOT re-sending in the sense it's discussed in the RFC.
Redirect is more of a fancy forwared that lets the original get out of the loop, e.g. sending it on to the right person and then making the reply from that right person go to the original sender instead.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
status-thunderbird_esr78: --- → wontfix
Target Milestone: --- → 90 Branch
Attached image redirect.svg (obsolete) —

Created a redirect icon.

Attachment #9218799 - Flags: feedback?(richard.marti)
Attachment #9218799 - Flags: feedback?(mkmelin+mozilla)
Attachment #9218766 - Attachment description: WIP: Bug 12916 - enable Redirect of messages. r=aleca → Bug 12916 - enable Redirect of messages. r=aleca

Comment on attachment 9218799 [details]
redirect.svg

LGTM, I've updated phab to have this icon, and fixed a few other issues - so it should now be ready for review.

Attachment #9218799 - Flags: feedback?(mkmelin+mozilla) → feedback+

Comment on attachment 9218799 [details]
redirect.svg

Looks good. This icon isn't pixel perfect. I'll tried to do one.

Attachment #9218799 - Flags: feedback?(richard.marti) → feedback+
Attached image redirect.svg (obsolete) —

What do you think about this version? With this the horizontal lines aren't blurred.

Attachment #9218912 - Flags: feedback?(alessandro)

Comment on attachment 9218912 [details]
redirect.svg

Yup, that's good.
I had the arrows aligned tot he grid instead of the lines. This is better and sharper.

Attachment #9218912 - Flags: feedback?(alessandro) → feedback+
Attachment #9218799 - Attachment is obsolete: true
Attachment #9218912 - Attachment description: redirect.svg that should be better aligned on pixels → redirect.svg

For my add-on Mail Redirect I had also designed SVG-icons that can both be used for the menuitem and the subjectCol icon. Only for (un)selected messages that have been forwarded, replied and resent, I have made two separate versions, because (to my knowledge limited knowledge of SVG) it isn't possible to use three colors with the fill and stroke attributes.

I'll add a zip with the icons and css for reference.

Thanks Onno for sharing these.
Richard, would you be able to adapt those SVG variations for the subject column for all the various scenarios?

  • Redirected
  • Redirected + Replied
  • Redirected + Forwarded
  • Redirected + Forwarded + Replied (this one is gonna be interesting)
Flags: needinfo?(richard.marti)

Shouldn't it be sufficient to show this as forwarded in the thread pane? If this detail matters, the user can just click on the mail and should see it there.

As Magnus wrote correctly:

Redirect is more of a fancy forward

(In reply to Ben Bucksch (:BenB) from comment #384)

Shouldn't it be sufficient to show this as forwarded in the thread pane? If this detail matters, the user can just click on the mail and should see it there.
As Magnus wrote correctly:

Redirect is more of a fancy forward
I agree. No need for yet another icon here. From the redirectors point of view, what matters is that the mail message has been passed on to someone else, and it no longer matters whether they are in the loop ("forward") or not ("redirect").

I disagree with comment 384 and comment 385.
Redirect and Forward are completely different and they should be represented differently in the thread pane.

A redirect "it is" like a fancy forward, but it excludes the sender from any reply, unlike the forward.
Having a distinctive icon that quickly allow users to identify the difference between multiple messages that have been forwarded or redirected is extremely helpful and increase readability of a long list of messages at a quick glance.

The icon looks like reload to me. Also, the direction of flow is the same, so the arrow should point in the same direction as forward. (to left: back to the sender, to the right: to somebody else)
How about a sgiggly line, like an S with an arrow at the top end? This way, the arrow goes in the right direction (to somebody else).

I think these are valid point, and as Richard suggested on Matrix, we need to simplify it a bit.
Maybe we could use something similar to the reply-all icon, using the forward icon but with doubled arrow head.
It should be "easier" to add with the other icons in the thread pane.

(In reply to Alessandro Castellani [:aleca] from comment #386)

I disagree with comment 384 and comment 385.
Redirect and Forward are completely different and they should be represented differently in the thread pane.

+1. While the proposed icon isn't exactly correct, there needs to be an easily identified icon(s) with this information, immediately viewable in threadpane without opening a message. Comment 383 is more on the right track than not.

Attached image redirect.svg —

This should be the final version. Approved by aleca through Matrix.

Attachment #9218912 - Attachment is obsolete: true
Flags: needinfo?(richard.marti)

This one is a bit stuffed but this scenario shouldn't happen that often.

This code in the shared messageIcons.css should do the needed display in the thread pane:

treechildren::-moz-tree-image(subjectCol, redirected) {
  list-style-image: url("chrome://messenger/skin/icons/redirect.svg");
  fill: #f68a16;
}

treechildren::-moz-tree-image(subjectCol, redirected, forwarded) {
  list-style-image: url("chrome://messenger/skin/icons/redirect-forward.svg");
  fill: #268be0;
  stroke: #f68a16;
}

treechildren::-moz-tree-image(subjectCol, redirected, replied) {
  list-style-image: url("chrome://messenger/skin/icons/redirect-reply.svg");
  fill: #f68a16;
  stroke: #9c5ccc;
}

treechildren::-moz-tree-image(subjectCol, redirected, replied, forwarded) {
  list-style-image: url("chrome://messenger/skin/icons/redirect-reply-forward.svg");
  fill: #268be0;
  stroke: #9c5ccc;
}

using the forward icon but with doubled arrow head

+1
Thank you!

Attachment #9218766 - Attachment description: Bug 12916 - enable Redirect of messages. r=aleca → Bug 12916 - enable Redirect of messages. r=aleca!,benc!

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/6bcb964278e1
enable Redirect of messages. r=aleca,benc

Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 3 years ago
Resolution: --- → FIXED

For the redirect function that has been introduced to version 90.0b1, the redirect window does not make it clear that the email is being redirected. Instead, it looks pretty much like the forward or write window - see the screenshot.

Could it be changed so that it is clear that the email is being redirected.

Thanks

I'm not sure what you're suggesting. It's no different from other modes: we don't say were replying, we don't say we're forwarding either. It's just that the addressing and other headers change as appropriate.

The from address in the window that opens is incorrect.

Seems correct to me. The from address will be the address it's originally addressed to. The Reply-To will be set to the address of the original sender.

If you find bugs, better file them separately.

Oh, then I'm not understanding what this ticket was trying to create. I had previously been using this plugin https://addons.thunderbird.net/en-US/thunderbird/addon/mailredirect/ which performed a redirect as I understood the concept. That is, the original from is preserved. This was useful in some circumstances (like redirecting mail into a bug tracker).

What you've built looks more like forwarding without the quoting of the body.

Ari is correct.

When redirecting an email, the From address is never changed, but uses the original From instead of that of the person "in the middle." Nobody who receives a redirected email should ever know from the visible headers themselves that it wasn't sent to them directly from the original sender.

Replacing the original header is no different than a forward, which is not what this bug should be about.

What you've built looks more like forwarding without the quoting of the body.

which looks weird to me, because what this ticket is about a true/simple bounce (which is described in the RFC, well known and have been existing for decades in many MUA), not an hybrid of bounce and forward. I expected this to be just a bounce... It's unclear to me why this have been done that way, I don't really see the rationale behind this choice (but I may have missed it, I am following this quite loosely).

I mean it's nice to have something, but I don't understand why it went that way.

This is the way it was implemented in Eudora and some others. The backend was mostly in there already, and I would imagine it's filling a more common use case.

With the RFC resend, you could not add your note to whoever you redirect to. It's a bit unclear to me how working it is with servers in general nowadays: apparently not allowed at all by Microsoft servers, and probably prevented by many other configurations as well due to policies not to send with wrong from domain and such...

Anyway, it's a different beast, and would require significant amounts of new UI. Might be most useful to implement as a filter action... bug 11034.

apparently not allowed at all by Microsoft servers, and probably prevented by many other configurations as well due to policies not to send with wrong from domain and such...

In that case, it seems to me the correct resolution of this request should have been "won't fix," because you're saying that the original behaviour that used to be possible (see bug 12916 comment 15 from 21 years ago for how the headers used to work, barring the debate over "Message-ID") no longer is, due to changing server and organization policies, and other modern standards. I could completely understand the justification for such a "won't fix" resolution 22 years after the bug was originally filed. But instead of the resolution being that it's no longer possible to implement the request as asked, something unasked for has been provided.

While it could be argued that the original redirect behaviour might be confusing to the original sender who received a reply from somebody they never wrote to (and that being a reason for not liking the original redirect behaviour in the first place), this hybrid behaviour is just as, if not more, confusing to the receiver of the message. ("This message seems to be from Sally, and when I reply, it replies to her—so, why in the world is the From showing Frank instead? Who is this Frank person?")

While that could be acceptable in some cases, it's still not what was originally requested of this bug.

IETF RFC 5322 (which obsoletes RFC 2822) specifies the "resend" action and the headers needed to be added, with no other changes to the message itself. Any such changes would be a "forward" action.

https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.6

So the UI can be simplified to just "resend this message to [field]" and two buttons, Resend and Cancel. That's all that's needed.

Whether or not the MTA/SMTP server allows the redirect is out of scope for Thunderbird, for the simple fact that Thunderbird is not a Mail Transfer Agent. Thunderbird is a Mail User Agent. If the user has a problem with the mail server, they should follow it up with the mail administrator. Thunderbird should not be restricting that on behalf of the administrators. It is not Thunderbird's job to do that.

Jason and Kelly are basically asking to send the mail with the From of another person. Due to spam, and thanks to newer email standards like DKIM and SPF, most email servers no longer accept such emails. And that's a good thing, because it avoids that any random person can forge emails from anybody else. That was a bad idea (or rather lack of foresight) even 30 ideas ago, and it's no longer possible today.

Whether or not the MTA/SMTP server allows the redirect is out of scope for Thunderbird

It is very much in scope. We should worry whether something actually works. If the action fails in most cases, and often fails silently, e.g. by being deleted as spam, then we shouldn't drive users right into that problem.

The original problem, as stated, was: 'When the proper recipient receives the email and the "replies" to it, the "reply" is sent to the secretary.' This problem is fixed now. We are adding a Reply-To header, which means that spec-conforming mail clients will send the reply not to the 'secretary' (the person that forwarded), but to the original sender. This is what the reporter wanted, and this is what was implemented.

The Reply-To solution implemented here is the right one, within today's email specifications.

What Jason and Kelly are explaining is the basic bounce/redirecting functionality that has been around for at least 30 years. Although basic, it is extremely useful and blatently missing from TB.

I agree that it is the task of the MTA to allow redirect or not. The MTA can make this decision, based on the resent-from (etc.) fields explained in the rfc.

The changing of the From and introducing a Reply-To is just something confusing that can be done as well with the regular forward function. The beauty of bounce is that it redirects the message to another person without the message having been changed. I can imagine, however, it would be useful to show the message has been resent in the header part of the interface in TB (e.g., This message has been resent by xx@xx at <date>) to avoid confusion at the new reciever's end, but that should be something for another bug.

There used to be an addon that could manage to do this. Now I have to revert to Apple Mail to redirect a message (and it indeed adds these resent headers).

(In reply to Ben Bucksch (:BenB) from comment #407)

Jason and Kelly are basically asking to send the mail with the From of another person. Due to spam, and thanks to newer email standards like DKIM and SPF, most email servers no longer accept such emails. And that's a good thing, because it avoids that any random person can forge emails from anybody else. That was a bad idea (or rather lack of foresight) even 30 ideas ago, and it's no longer possible today.

Whether or not the MTA/SMTP server allows the redirect is out of scope for Thunderbird

It is very much in scope. We should worry whether something actually works. If the action fails in most cases, and often fails silently, e.g. by being deleted as spam, then we shouldn't drive users right into that problem.

The original problem, as stated, was: 'When the proper recipient receives the email and the "replies" to it, the "reply" is sent to the secretary.' This problem is fixed now. We are adding a Reply-To header, which means that spec-conforming mail clients will send the reply not to the 'secretary' (the person that forwarded), but to the original sender. This is what the reporter wanted, and this is what was implemented.

The Reply-To solution implemented here is the right one, within today's email specifications.

If the way it is implemented right now, that the message is actually forwarded, only with an added reply-to header, I think this bug should be reopened, and I'll reconsider dropping the add-on Mail redirect and try to implement the function after all as a web extension.
This isn't redirecting at all as specified in the RFC's and as long as the RFC's aren't deprecated or decommissioned in favor of newer RFC's that don't specify the redirect functionality, it's just plain wrong to call this redirecting and I very much doubt mutt, PostBox, or even Eudor implemented redirecting as forwarding with an added reply-to header.

RFC 5322 talks about "resending", it never says redirect.
It was the Eudora engineers who re-implemented the feature backend for this in the Penelope project for Eudora compatibility, so rest assured tthis was how redirect worked there.

Like I said, it's different beasts. I'm not opposed to adding the RFC resend as well if someone (Onno?) wants to do the work.

(In reply to Magnus Melin [:mkmelin] from comment #410)

RFC 5322 talks about "resending", it never says redirect.
It was the Eudora engineers who re-implemented the feature backend for this in the Penelope project for Eudora compatibility, so rest assured tthis was how redirect worked there.

Like I said, it's different beasts. I'm not opposed to adding the RFC resend as well if someone (Onno?) wants to do the work.

Well, then the item as it is now should probably be renamed to Resend instead of Redirect. But I really don't understand what is added now, because it was already possible to forward a message inline and add a Reply-to header. Is it only that the Reply-to header is already filled in with the original sender's address? Then this is truly a forward and I wouldn't call it Redirect in the menu (and neither would I use a special icon for it)...

I'll see if I can implement Redirect it in such a way that it can be added to core, but I'll start with trying to get the add-on working again.

You could do a forward + go and copy-paste address into Reply-To + delete the fwd preamble in the msg body + edit the subject so you don't get the "Re: Fwd: Re:" junk. But you can argue the same for why do we need "reply".... Because this is just more convenient! Redirect also gets' the references right so threading works, which it will not necessarily do for the original sender if you forwarded and he gets a reply.

The RFC says Resend, not Redirect, so it seems appropriate that a Resend functionality would be named that, not Redirect.

The redirect functionality, as originaly asked for in this report, is as Magnus describes it. It is what I have always seen as redirect in various mail clients, including Eudora (although it has been a really long time since I've used it).

http://www.bio.unipd.it/local/internet_docs/eudora/eudora13.html

The RFC just describes what should be done "to any message that is reintroduced by a user into the transport system". It doesn't prescribe the name that the action should be called that reintroduces the message. From my past experience this is called redirect or bounce.

I really don't get the mixed up From, To, Reply-to juggling you are proposing.

The key bit here are newer email standards like DKIM, SPF, and authenticated Submission-SMTP / SMTP AUTH. They mean that the demanded solution here does not work. It may happen to work on your particular server, but not for other users. If we build a feature into Thunderbird, it must work for everybody, not just some people. For special needs, indeed an extension / add-on is better. Onno Ekker, if you think that your solution is needed, I think it's indeed best for you to re-surrect the your extension and build it as WebExtension.

Apart from that: What Magnus said in comment 412.

(In reply to Ben Bucksch (:BenB) from comment #414)

The key bit here are newer email standards like DKIM, SPF, and authenticated Submission-SMTP / SMTP AUTH.

Could you please elaborate?

SPF should not apply for the feature in RFC 5322. SPF checks the HELO and MAIL FROM, not the "From" field.
I've been using the "Simple Mail Redirection" addon (a WebExt implementing that RFC) repeatedly, and also mail resent by it pass all SPF checks as expected, since the new "HELO" and "MAIL FROM" are set by the MTA when the mail is reintroduced.

DKIM should also not apply for this feature, since the signed fields are not touched, unless the mail already has "resent" fields before and these have been signed explicitly (or unless a mail server is used which touches mail content on-receive, but then, DKIM is broken on-receive in any case).

I'm not sure how SMTP AUTH should enter here, since this is only used to authenticate the MUA against the SMTP server.

Of course, you are correct that things may still fail if the MTA actually does not accept mail with a "From" field not matching its domain. But I have yet to find any mail server doing that when using SMTP AUTH to reintroduce the mail into the system (I tested some larger common providers). Is there an RFC on this?

Well, I don't think that what is implemented now, is what was requested with this bug, because throughout this bug references are made to RFC822 section 4.2, RFC2822 section 3.6, etc and as a solution the Mail Redirect add-on was developed. You're probably right in saying that what the Mail Redirect extension does, is actually Resending, that's also the term that is used in most of its UI.

Apart from that: I don't think the Redirect menuitem as implemented, is on the right place, because at the moment it is even more prominent than the choice between forward inline/forward as attachment, but it's a less common feature.

(In reply to Ben Bucksch (:BenB) from comment #414)

The key bit here are newer email standards like DKIM, SPF, and authenticated Submission-SMTP / SMTP AUTH. They mean that the demanded solution here does not work.

DKIM, SPF, and authenticated Submission-SMTP / SMTP AUTH are optional features and you can't expect that every MTA in the world use this optional features. You also have to account for differences between company internal and external emails. Often the mentioned features are deactivated for company internal emails.
I used the mentioned extension for years to redirect emails that arrived at my company email address to our ticket systems. This way the ticket creator is the original email sender and not me.

The bug title is "Allow bounce/redirect of mail messages". My vote was given to a functionality similar to

to send a copy to alternative addresses as if they were the message's original recipients.

When redirecting email, body and headers are left untouched, so fields like Received:, From:, To: in redirected message are the same as in original one. However redirected mail differs a bit from original one. A few new headers are added: Resent-From:, Resent-To:, Resent-Date:, Resent-Message-Id: and Resent-User-Agent: which allow to identify redirected mails.

I currently use Simple Mail Redirection add-on for redirecting messages.

Jason and Kelly are basically asking to send the mail with the From of another person.

This is not precisely true as far as I am personally concerned. My comment was from a bug-handling process perspective alone; it wasn't a comment on what I, myself, desire to see implemented in Thunderbird. Those two things are related, but not identical.

Twenty-two years ago I wanted to see what was asked for implemented. (And what was just implemented is not what was asked for.) Now, I'm on the fence about what I want, but that's irrelevant.

What's true is that in order to resolve this bug as fixed, the mail must use "the From of another person." If you decide that's not desirable behaviour (and I'm not saying that's an unreasonable conclusion), and want to implement something different than what was asked for—as seems to be the case here, then you need to back out what was done, resolve this bug as "won't fix," and create a new bug for some different kind of behaviour. The different behaviour that was recently implemented would then need to be associated with the new bug, not with this one.

At the very least, this new behaviour—which, if kept, I still think should be linked to a new bug—should not be called "redirect" or "bounce." It's a behaviour that, as far as I know, has never existed before. As others have said, it's really just a modified form of forwarding. But I can think of no one- or two-word name for it that would make the behaviour self-explanatory.

Without descending even further into painting the bikeshed territory, perhaps it would be useful to step back and question what use cases are solved by the feature as implemented and the original redirect feature.

There appear to be a number of people who would find the original redirect feature useful by the existence of several plugins. For me, the use case was always about sending email into a support ticketing system but having the original author as the creator of the ticket. In that environment, SPF and other spam prevention features aren't a problem.

I'm not really understanding the use-case for the feature as implemented. Forwarding without quoting seems confusing to the recipient. It looks like Bob wrote the email, but it was Alice who actually wrote it. And when you hit reply, you'll reply to Alice by default, so you'll probably cancel and choose reply-all.

Sorry for the "me too" but what with the hassle of core extension changes and related upgrade pain of late, I felt compelled to respond.

We use the "mail redirect" extension on a daily basis to re-direct email from role mailboxes that have either been mis-addressed or need the attention of a specific person or emails that have simply been sent to the wrong person. The "forwarding with a reply-to" method won't work for us as we want replies to behave in exactly the same way as if the email had arrived at the right place in the first place and the person replying should see the sender as the original sender, not the role address or some other intermediary. We're generally doing this in-house via our own mail server.

(In reply to Ari Maniatis from comment #420)

I second the outlined approach — for reference, my use case of the originally requested feature is exactly the same. There may be a better place than this bugtracker to collect the use cases, though.

In any case, SPF, DKIM and SMTP AUTH don't apply to the original use case. SPF looks at the envelope fields, which are outside the MUAs control and not touched by this feature, DKIM signs content fields (which are untouched unless resend-fields are already present and signed, which means the mail was resend already), and SMTP AUTH is not about enforcing rules about the content.

The only spam prevention technique incompatible with this feature to my knowledge is DMARC, which indeed checks the "From:" field instead of the sender, hence being in violation of rfc5322. To my knowledge, only a single public provider enforces DMARC at this day.
Note that the "custom sender address" functionality Thunderbird already offers is also incompatible with DMARC.
Furthermore, checking DMARC in RFC7489, page 15, it explains that DMARC does not state it should be used in all cases.

So unless corrected by somebody with better knowledge, I state that the spam prevention techniques mentioned earlier do not apply to the originally requested feature.

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #409)

If the way it is implemented right now, that the message is actually forwarded, only with an added reply-to header, I think this bug should be reopened, and I'll reconsider dropping the add-on Mail redirect and try to implement the function after all as a web extension.
This isn't redirecting at all as specified in the RFC's and as long as the RFC's aren't deprecated or decommissioned in favor of newer RFC's that don't specify the redirect functionality, it's just plain wrong to call this redirecting and I very much doubt mutt, PostBox, or even Eudor implemented redirecting as forwarding with an added reply-to header.

I think this would be the best solution. If I'm not mistaken the majority of comments would like to have more or less the functionality of Onnos old plugin implemented in thunderbird. So it seems fitting that Onno may be the one to implement it. This would only rise the question if Onno needs support implementing it and if so who would provide the support.

As of the discussion about Magnus new feature I imagine that this kind of "quick forward" would't hurt anyone (at the contrary I may be really useful to save time) as an optional feature for some users. Since in fact it technically seems to be a common forward with an alternative dialog window I personally don't see need for a separate set of icons for it. But here again I don't think they would hurt either - provided that they don't collide with other icons.
It seems fitting to me, that this new "quick forward" function it to get it's own thread, since it is an entirely new feature.

Since there hasn't been any further comments I would like to ask: What would be the proper way to reopen this issue? Is there some kind of voting procedure?

Seems strange to me, that apparently nothing is happening any more. Or am I missing something?

Flags: needinfo?(mkmelin+mozilla)

This issue is closed. You need another bug for implementing Resend (could do it in bug 11034 perhaps).

Flags: needinfo?(mkmelin+mozilla)

Bug 11034 is about a filter action, which could be a follow up for this bug. At the moment it is only possible to choose Forward as filter action, and not to specify how to forward: Inline, As attachment, or "Redirect"...

Since there doesn't seem to be another bug to request Resending, which I think was requested in this bug, I cloned this bug to bug 1718968.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: