(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #329783 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=329783 Imported into Bugzilla on 01/14/99 02:47) It would be very cool if a user could specify a .sig based on whether the outgoing mail was being sent internally within a company or externally. This perhaps could be accomplished by basing the .sig on if the from: domain corresponded to the to: domain. Examples: My internal .sig for Netscape Jim Race - x5410 Netcenter PD Quality Assurance http://webops/qa/ My external .sig for Outsiders Jim Race (650) 937-5410 Netcenter Product Development Quality Assurance http://home.netscape.com In this way, I can provide information which is of use to both audiences, all without changing prefs.

This will be a part of the "Identity" system that we'll have in Mail5.

It has been decided that we will have a pool of signatures to choose from at send time, and that each identity will have a default signature. Implementation is still a ways away.

the nsIMsgSignature interface has been checked in...no implementation yet.

Moving signatures way into the future.

Ugh, I really ought to just accept that this won't make it into M7.

going on vacation, mass-moving these M8 bugs to M9

moving low priority, high risk, and time-intensive bugs to M10

not a beta stopper

*** Bug 16957 has been marked as a duplicate of this bug. ***

So will this actually result in the signature not appearing as normal in the message? If not, will the current signature still show as a read-only section at the bottom. If so, what will happen if you (accidentally) slightly edit the sig and change your profile? Will everything after the -- be trashed (insert issues of accidentally inserting the -- sequence here) ?

The current signature functionality is what will be in the first beta: - in the prefs/accountmanager, you get to enter a path to a sig file - at compose time, the signature will be inserted into the current message as regular text...you can edit it as you please - editing the signature at compose time does not change the signature stored on disk. I don't understand what you mean by "and then change your profile"

Sorry, profile => account. This implied to me that since you can change your account, the sig would change with it. Is this the way things are intended to go post B1? I'm just trying to work out why my bug was marked a dupe of this one.

no, for B1 the sig will not change when you change identities in the compose window. Ah, I think I see what your other bug is, it's not QUITE a dupe I think... Let's move to that bug to discuss it and maybe we'll unmark it a dupe.

P4 per m/n staff mtg today

not on beta2 feature list, so pushing out. Could use some help here.

[FEATURE] bugs past M16 are OUT for this release. Marking M20. If you disagree with this action, please help me explain it to the PDT.

Moving feature bugs to target milestone "Future" for next release consideration.

massive reassign of account manager bugs -> sspitzer please feel free to put me back on the CC if you have any questions/comments

mass re-assign of account manager bugs to racham.

Multiple sigs are now possible with MailNews, depending on the account you write from. Can we close this oldie please? I propose to file a new bug on the "appended sig not changing when changing accounts and compose time" issue.

Cleaning Bugzilla... This bug has been fixed for almost all of Mozilla's existence. Signatures are defined on an account-by-account basis Marking Fixed

Verified Fixed.

Feel free to mark closed -jim (originator when still at NSCP)

This bug doesn't seem fixed. We *don't* have... 1) a sig based on whether the outgoing mail was being sent internally within a company or externally. (it is pretty clear the reporter wanted this to happen automatically). 2) a pool of signatures to choose from at send time. Tying sigs to accounts is just a *hack* (for a real solution, see bug 73567 - need ability to select from multiple signatures (global / per account?)). Therefore, this bug should be either WONTFIXED or REOPENED.

Why has there been no response to comment #24? This bug should be WONTFIXED or REOPENED (and definetely not FIXED)!