Avoiding extra detail in plain text signtures.

When I create a plan text signature Thunderbird takes it upon iyself to add some <cr> and two dashes. I do not want this addition, it looks untidy. How do I avoid them? many thanks.

Sounds like you are describing the signature delimiter.
Tools > Options > Advanced > General tab
or
Menu Icon > Options > Options > Advanced > General tab
click on 'Config Editor' button
it will tell you to be careful :)
In top search type: separator
look for this line
mail.identity.default.suppress_signature_separator
Double click on that line to toggle the value from 'False' to 'True'
close window - top right X
click on OK to save changes to Options.

Similar Messages

  • FTP Adapter - Avoid Password in plain text

    Hi,
    When we configure a FTP adapter in FTP Oubound connection pool we enter password. The password is stored as plain text. It is visible to all users (even to a users who has just monitoring access). Can we have the password in protected mode.
    Thanks,
    Sanjay

    Create credential mapping under the security tab of the FTP adapter in the deployment section of weblogic console.
    Thanks,

  • Number format changed after opening a plain text file in Excel

    Hi,
    I have an urget need to understand about how to open a plain text file in Excel with numbers displayed as is. The text file is tab delimited. Right now, extra digits (0, or 00 ) are added. For example, 31:16 from text file is displayed as 31:16:00,
    15:0 becomes 15:00, 6:5 becomes 6:05. How to display the numbers as they are in the original text file?
    Thank you very much for the help.
    Amy

    This is a annoying problem.
    Excel will try to guess the data type if you leave the cell formatting as general.This happens a lot with specific numerical entries that could be confused as dates.e.g. 12:0,1-5 etc.Unfortunatley We can't tell Excel to stop reading it as a date, but what you
    can do is tell it to display the date how you want it.
    In addtion,in order to avoid confusion and keep track of troubleshooting steps, we usually troubleshoot one issue per thread. So if you need any further help, please create a new post.Thanks for your understanding.

  • How do you add plain text?

    Hi all!
    I have a very simple question, which is just what it says in the subject line of this topic.
    How do I add plain text into iMovie? No fades, no slides, no nothing, just plain text?
    From what I've been searching online, no one has answered this question, but then again, no one has asked it either.
    All I could find was 1 yahoo thread with the question in which the answer was not clear at all.
    I've been trying to find it myself by snooping around in iMovie, but as you might guess, unsuccessfully.
    From snooping around I've come to draw the conclusion that you probably can't add plain text into iMovie via iMovie directly.
    However, and idea I had was, if I create an image in, lets say Paint 2, with whatever plain text I want to add, and then insert it into the project. Will this have the same effect?
    Can anyone please confirm this? I'm going crazy just looking for such a simple feature hehehe.
    Thank you in advance!
    //cez

    hmm, well ... a video isn't meant for reading (resolution, compression, blabla). ...
    so 'text' in a video should be very large in font, avoid tiny details, too much contrasts ... blabla again
    Advice using the Title-feature as 'text' isn't wrong.
    plus, iMovie is no text-processor, you copy/paste larger amounts of letters into it.
    If you need/want 'a page full of text' in iMovie, indeed you have to do the roundtrip by creating a 'picture' of your text-page, and insert that jpg to your Project.
    The good news:
    if your 'picture (=text page) is longer than the video screen, you can apply a nice Ken Burns effect to 'scroll' through the text ... in case, your audience reads as fast as you.
    bad news: max is 5:1 ratio of the 'page' ... so, no 'books' please ...
    Aside Star Wars ("... in a galaxy far, far away from here"), you should avoid 'text' longer than a usual title.
    (this answer/workaround isn't in the 'canned' replies of our hosts, you should forgive'em ... )

  • DECODING MAIL FROM WEB SERVER IN PLAIN TEXT FORMAT(THE MAIL BEING SENT BY LABVIEW APPLICATION)

    Hi All
    I have a labview application that send mail every hour automatically.
    But actually the mail has to be decoded from the web server(by another application).But now when that application decode the data in the mail(that is send by labview application)its getting some funny characters inside that can not be detected by the decoding application
    (When open the mail no problem.)But actually our goal is to decode the mail from the web server.
    Why the extra characters are appearing when decoding from the server?Is it because of the HTML format?
    Is there option to send the mail in plain text format(not like attachment)?
    In outlook we can change the setting (tools->options->send->mail sending format->....here we can set as HTML format/Plain Text format)
    Like that at the sending time can i chenge the sending option as plain text format in my labview application?
    Thanks...

    smercurio_fc wrote:
    Then it sounds to me like this other application is not decoding the attachment correctly, especially if you looked at the attachment yourself after you received it and verified it's correct.
    No, no, smercurio. This is charcter encoding here. In older versions of LabVIEW you could specify what character encoding to use when sending an email through the SMTP VIs. But that gave problems since people in certain locales used certain characters that where not transfered right when the wrong encoding was specified, and that encoding stuff is not understood by most people at all, so the wrong selected encoding was rather the rule than the exception. In newer versions of LabVIEW do the SMTP VIs handle the encoding automatically based on the currently used locale on the system.
    This change is documented in the Upgrade Notes of LabVIEW and probably happened around LabVIEW 7.1 or 8.0.
    A decent mail client will recognize the encoding and convert it back to whatever is necessary before presenting it to the user. The OPs posters server application obviously isn't a smart mail client but probably just some crude text file parser that has no notion of proper mail character encoding and how to deal with it.
    I would suppose that there is a chance to dig into the SMTP VIs itself and try to manipulate or disable that encoding altogether in there but that may open a whole can of worms somewhere else. The proper way would be to process the incoming mail by a character encoding aware mail client before passing it to the text parser. On Unix setting up something like this would be fairly trivial.
    Rolf Kalbermatter
    Message Edited by rolfk on 01-23-2008 10:21 AM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Outlook 2010 "Send Plain text only" not working for individual contacts

    We have a Outlook 2010/Exchange 2007 environment
    If you go to Outlook Properties of a contact and change from "Let Outlook decide the best sending format" to "Send Plain text only", it is supposed to force Outlook to send a Plain text
    email
    to that contact. 
    But it is still sending HTML.  This is happening with any contact I try this with.
    While composing the email I can change it to Plain text manually and that works fine.
    Not sure what gives...

    Hi,
    I recommend that you check the global remote domain setting if set to send plain text.
    If not , the remote domain setting will override the change of the contact's properties when sending email out. 
    More details refer to the following article:
    http://technet.microsoft.com/en-us/library/bb232174(v=exchg.141).aspx
    Remote domain settings   Remote domains define the settings for outgoing message transfers between the Exchange 2010 organization and domains outside the Active Directory forest. Even if you don't create remote domain entries
    for specific domains, there's a predefined remote domain named Default that applies to all remote address spaces (*).
    Hope this helps!
    Thanks.
    Niko Cheng
    TechNet Community Support

  • IPhoto sends emails in Rich format even if the default format is Plain Text

    Detailed Summary (wouldn't fit in the Topic Subject):
    iPhoto will always send emails in Rich Text format even if Mail application is set to send all emails in Plain Text format. In other words, emails initiated from iPhoto ignore the selected Message Format setting in the Mail application.
    Description:
    It is a better practice to email photos in the Plain Text format instead of Rich Text format so recipients using different email clients can easily download attached pictures as regular attached files.
    The workaround is to change the email format to Plain Text before sending it. This wouldn't be such a problem if you could make this a permanent setting however this is not possible. The Mail application has a specific setting for this but iPhoto simply ignores it. This is the issue I am raising here.
    How to reproduce the problem:
    1. Open the Mail application (Assuming you already have an email account configured)
    2. Go to Preferences, Composing tab
    3. Change Message Format to "Plain Text"
    4. Optional step to verify that the Plain Text is now the default format: Start a new email. Click on menu Format and you'll see "Make Rich Text" available, which means the current email is in fact in Text Format. Close this email.
    5. Open iPhoto
    6. Select one or more photos and click on the "Email" icon on the lower right hand side
    7. A details popup will open, click on "Compose Message"
    8. The Mail application will open as well as a New Email window with the Subject field filled out and the selected photos in the email body
    9. Click on the menu Format
    Expected: Th last option should be "Make Rich Text" indicating that the current email is in Plain Text format as determined by the Mail settings (steps 1-5 above)
    Actual: Last option is "Make Plain Text" which means the current email is fact in the Rich Text format which does not match the Mail application settings.
    Can we at least get an acknowledgement from Apple that this is a known issue? Also, is there a fix for this? It is not an acceptable solution to tell users to manually select Plain Text for every email. I am tired of asking people to resend emails that way. That is a workaround, not a solution.
    Test details:
    - Mail Version 4.4 (1082)
    - iPhoto Version 8.1.2 (424)
    - OSX Version 10.6.5

    iPhoto menu -> Provide iPhoto Feedback to report a bug.
    Can we at least get an acknowledgement from Apple that this is a known issue?
    Need to ask Apple that one.
    Regards
    TD

  • Attachments converted to plain-text when using redirect rule

    When I redirect emails using a Mail rule, any attachments (as well as the entire message) are converted to plain text with extra control character, rendering the attachment unviewable. This does not happen when I manually redirect an email. Any help you can provide would be welcome.

    When I redirect emails using a Mail rule, any attachments (as well as the entire message) are converted to plain text with extra control character, rendering the attachment unviewable. This does not happen when I manually redirect an email. Any help you can provide would be welcome.

  • How do you verify the size of a large ( 32K) plain text body

    Hello All,
    I am running GW 8.0.2 Hot Patch 3, using SOAP schema 1.04.
    When I attempt to process a message, that contains only a plain text body with a size (in bytes) of 64,382 - the following sizes are reported by objects extracted from GroupWise, via SOAP calls:
    Message Size: 71,425 (should be bigger than the plain text body).
    Message Part [0] length: 70,854 - no idea where this value comes from
    In the getAttachmentResponse object, the part has:
    length: 87,772 - Which matches the Base64 encoded length, plus padding, of the plain text.
    The actual size of the plain text (on disk): 64,382
    I am hoping to use the HTTP GET method for extracting the large plain text object, which means that I will not have access to the getAttachmentResponse object.
    So my question is, based on the MessageBody, MessagePart[0] length of 70,854 - is there a formula, or other way to determine the correct expected byte size of the plain text object to enable me to verify that the HTTP GET operation or the SOAP getAttachmentRequest completed correctly?
    Regards,
    Dave Stiller.

    Hey Preston,
    Thanks for the prompt response. Not the answer that I was seeking, but none the less an answer. Thanks.
    Can I suggest an enhancement for a future release, to add an additional structure to the message object that allows you to detail the available formats and byte sizes of the formats that relate to the message body object. This could even be an extension/completion of the MessagePart object array on the Message Body. (One array component for each available format.) There are no issues when dealing with large body texts as attachments, but an accurate byte count is important to me.
    This will enable us to verify that the message body content, downloaded from GroupWise, has not be corrupted during transfer - particularly important when using HTTP requests.
    Have a great day,
    Dave...
    Originally Posted by Preston Stephenson
    You will have to be careful in getting message bodies.
    The plain text message body can come from different
    sources and / or formats.
    The message body can be stored in RTF format.
    You can extract the plain text from the RTF text.
    If there is a text.htm message body attachment, the
    GW Client will extract the text plain text from the
    text.htm attachment and will ignore the text plain
    message body attachment.
    There can be corruptions in the message body
    attachment. The attachment can report a certain
    size, but the actual data may be different.
    You have to assume what is stored / returned is
    correct. If you are bound and determined to read
    the number of bytes recorded, you can cause
    problems. There was one case where the attachment
    was corrupt. The POA returned all the data that
    was available. The application tried to read past
    the end of the valid data and caused the POA to
    crash.
    You get all of the data in one HTTP GET call. In
    that case, the "Content-Length" header will have
    the number of bytes in the message body attachment.
    Preston
    >>> On Sunday, August 12, 2012 at 11:36 PM,
    stillerd<[email protected]> wrote:
    > Hello All,
    >
    > I am running GW 8.0.2 Hot Patch 3, using SOAP schema 1.04.
    >
    > When I attempt to process a message, that contains only a plain text
    > body with a size (in bytes) of 64,382 ‑ the following sizes are
    reported
    > by objects extracted from GroupWise, via SOAP calls:
    >
    > Message Size: 71,425 (should be bigger than the plain text body).
    > Message Part [0] length: 70,854 ‑ no idea where this value comes from
    >
    > In the getAttachmentResponse object, the part has:
    > length: 87,772 ‑ Which matches the Base64 encoded length, plus padding,
    > of the plain text.
    >
    > The actual size of the plain text (on disk): 64,382
    >
    > I am hoping to use the HTTP GET method for extracting the large plain
    > text object, which means that I will not have access to the
    > getAttachmentResponse object.
    >
    > So my question is, based on the MessageBody, MessagePart[0] length of
    > 70,854 ‑ is there a formula, or other way to determine the correct
    > expected byte size of the plain text object to enable me to verify that
    > the HTTP GET operation or the SOAP getAttachmentRequest completed
    > correctly?
    >
    > Regards,
    > Dave Stiller.

  • How to send a plain text and HTML email at once?

    Hi all,
    I'm attempting to use cfmailpart to send a HTML and plain text email all in the same cfmail script.  I'm using Outlook and Gmail to test.  I temporarily changed my Outlook settings to "read all standard mail in plain text," but it does not read the plain text cfmailpart of the email, it just attempts to format the text from the HTML email and display the links.  If I remove the HTML cfmailpart from my cfmail script, the plain text version is delivered, but Outlook removes extra line breaks that I actually want to keep intact, and some of the other formatting is improperly rendered.  Is there a better way to make sure email clients hold the plain text formatting (even though there really isn't any formatting with plain text) and a better way to test?  The HTML version looks great in both Gmail and Outlook.
    Thanks!

    Use the wraptext attribute of the cfmailpart tag to add line breaks.

  • Problem with plain text trailers in rich text email?

    I'm a member of a mail group which adds subscribe and unsubscribe trailers added to the emails. When reading these emails with Mail 2.1.1, text emails appear fine. But sometimes html emails that have the text trailer have problems.
    The text trailer (which is within a pre html tag) often has and equal sign "=" and "return" which brings the links on two lines. The placement of the extra characters is random... The html of the problem emails look fine when downloaded as a file and viewed with a browser (and the code is fine too)
    I see this problem ONLY from group html emails that have a plain text trailer.
    Comments or thoughts?

    -

  • LDAP -- plain text password

    Hi All -
    Does any one know how to retrieve the password from LDAP in plain text form?
    Thanks,
    Giri

    Hi Giri,
    Yes there is a possiblity, you can retrive password using java server side program, we had same problem and then fixed now we can retrieve password as well as Userid.
    Note: we are authenticating against LDAP server and App server is
    IBM WebSphere Application server.
    for using below example:
    public class TestServer
    private void performLoginAndAuthentication()
    // Get the user's ID and password.
    String userid = customGetUserid();
    String password = customGetPassword();
    // Ensure immediate authentication.
    boolean forceAuthentication = true;
    // Create a new security context to hold
    // authentication data.
    ServerSideAuthenticator serverAuth = new ServerSideAuthenticator();
    try
    // Perform authentication based on supplied data.
    org.omg.SecurityLevel2.Credentials credentials =
    serverAuth.login(userid, password, forceAuthentication);
    // Retrieve the user's name from the credentials
    // so we can tell the user that login succeeded.
    String username = serverAuth.getUserName(credentials);
    System.out.println("Authentication successful for user: "+username);
    catch (Exception e)
    // Handle exceptions.
    Just research or give me more details how may I can help you in this case.
    Thanks
    Srinivasa

  • How can I add some help text to a plain text field?

    I would like to put the basics in the plain text (formatted text) field and then some details and clarifications in the help text area.  Seems like this would be easy and useful.

    Thanks for your feedback. I don't think we ever thought of using the help text that way.
    Randy

  • {code} in Plain Text Help

    A lot of the answers are reminding people to use the {noformat}{noformat} tag. The use of that tag could be encouraged by adding {noformat}{noformat} to the "Plain Text Help" section that appears on the right during posting. Has that been tried?

    It was mentioned early on when the forum update was done a couple of years back, but for some reason it either wasn't done or couldn't be done. Not sure why.
    Of course there is always the FAQ page which I think details such things (it's a wiki I believe, so it can be updated by anyone as required).

  • Plain text print speed thru lpr vs. BBEdit

    When I send a plain text file to the Unix lpr command, it prints slowly; when I print with, say, BBEdit, the same text comes out much faster.
    I'm using an iBook G3 600 MHz with USB 1.0, OS X 10.4.11, and
    an Epson Stylus CX6000--a recent, non-Postscript inkjet printer with recent driver from Epson.
    Example: a one-page, 897-byte file. Counting from the time the paper starts to move:
    lpr: 120 sec (7.5 characters per second, slower than a teletype)
    enscript: 90 sec
    BBEdit: 20 sec
    (To top it off lpr uses an awful 14-point narrow font...but I already can print slowly in a better font.)
    It doesn't seem to be simply a matter of communication speed. Printing through lpr, the print head is constantly moving, but the paper advances very slowly, as if by scan lines. Printing from BBEdit, the paper advances like an inch at a time.
    My guess is that BBEdit gives the text to the printer driver which basically sends it on as text to the printer, which has a fast way to print text, while lpr goes through a postscript/bitmap process. In fact lpr is slower than enscript, which explicitly converts to postscript (which has to be rendered in the computer) before printing. (The lpr/enscript speed difference may be because lpr uses a bigger default font.)
    So: how can I access that fast text printing ability from Unix? Is there some sample Unix-style C source code out there that calls the same API that BBEdit is calling, that would be easy to adapt to printing text from a file or stdin?
    Or, an option or utility already in Mac OS X? A third-party utility that's already out there?
    --Steve
    P.S. Camino printing the edit page for this post (multiple fonts, boxes, sidebar, etc.): 28 sec. Also, inch-at-a-time.

    YES!!
    The BBEdit command line tool was apparently introduced in version 6.5, which is the version I have. In the BBEdit folder (the folder BBEdit.app is in) there is a "BBEdit Extras" folder with a "BBEdit Unix Tools Installer.dmg".
    Once installed there's a Unix command "bbedit", and you can do "man bbedit".
    Besides -p for print there's -b for background, so you never even see anything happen on the screen.
    It prints with the defaults set in BBEdit's preferences. I like Courier 10.
    I do appreciate enscript. That's what I meant when I said I already knew how to print nice fonts slowly. Also, 2-up is nice, I have my own script for it!
    Thanks a lot, etresoft!
    --Steve

Maybe you are looking for