Email Download Header Only
Hilke Mcnally
Cannot seem to rpint an entire email. Only get the header portion. Read through other solutions to Big Sur issue -- didn't make sense -- and am now running Ventura 13.3.1. Seems to be a consistent problem. PLEASE FIX IT!
Try taking a screen shot of the email and printing that. Use the Key combo Cmd Shift 4 then Spacebar, or the Screenshot app in Applications-Utilities-Screenshot.app for taking the picture of the email.
When you create a structured analytics set, there are two settings that affect whether name normalization will run on the email headers, or on the extracted text. These settings are found in the Email Headers section.
Regardless of settings, if name normalization cannot find a From header and at least one other email header (such as To, CC, BCC, Subject, or Date Sent) in whatever it analyzes, it skips analyzing the document. These documents are assumed to be non-emails.
Usually, if name normalization cannot find a From field and one other email header field (such as To, CC, BCC, Subject, or Date Sent), it analyzes the extracted text to find it. If you want to force name normalization to use only email metadata fields, you can use regular expressions (regex) to filter out all extracted text.
I have just recently started to use Thunderbird and have set it up to use my long held Gmail account. It is all set up and everything appears to be working correctly. My understanding is that when I first double clicked on the the computers icon in the bottom left of the app and choose the "download now" option from the resulting dialogue box is that it would have download all emails from gmails servers onto my computer. Then each time I do this it will keep my computer in sync with the gmail server. However I understand that it only downloads the headers of the emails and therefore if my Gmail account got hacked and sabotaged or something else happened where I lost access to my Gmail account I would not be able to view the bodies of the emails in Thunderbird. Is this correct and if so can Thunderbird be configured so that I receive the bodies and attachments when downloading to my computer. It would be nice to achieve a full back up of my Gmail account in Thunderbird. I have already successfully backed up my contacts using gcontactsync.
If the other documents are working fine, I would suggest using a different browser to access your emails and to print them. For eg. If you are using Internet explorer, then try and use Google chrome and try to print.
Ummm... ok. "Repair" is not a property of folders, though;
it's an action. It doesn't belong on the "Properties" box,
which explains why I never noticed its existence; it belongs
on the folder right-click menu itself, or perhaps even on
a toolbar.Or better yet, every time you open or access a folder,
TB should check for integrity (CRC check or some such thing?),
and if errors are detected, they should be fixed internally,
silently, relentlessly. That's called "robustness".
Requiring the user to magically know-about, find, and click
a "Repair" button is broken.Come on, when was the last time you saw a for-real piece
of software with a dialog box with a button labeled: [REPAIR]
This feature is broken and we're too lazy to find and fix
the root cause. So when it fucks up -- and believe us,
it will -- just click this "REPAIR" button and everything
will be hunky-dory again. For a while. We hope.That software company would be laughed out of the market
and would be forgotten in the sands of time.And to think that the open-source community is forever
hurt and sulking because people don't take their software
seriously. They wonder, "Why??? Why??? *Why* don't we get
the respect we deserve???" Well... there's really something
to be said for 872 angry customers screaming profanities over
the telephone at your customer-service representatives. It
works wonders at lighting a fire under the butts of the
company's developers. Open-source developers, on the other
hand, don't have that. More's the pity. But perhaps I can
help with that. ;-)Anyway, thanks for alerting me to the existence of that
hidden "repair" button. I'll try that the next time my
email headers/bodies get out of sync. Should be faster
than unsub/resub, providing that it actually works.
Can I get the email app to only download email headers -- and get bodies on demand? This is for an MS Exchange based email service. I have a Nexus One. The email app works fine, but the volume of email I get for work is huge and although I need to see all the subject lines, I rarely need to read the full email when I'm not at work. How can I get the email app to just download headers? Alternatively, is there another email app in the Market I could use for this?
My question is simple, why gmail chose to put this email in my inbox? Attached bellow is the full source of the email (from gmail) except my censored email. How is this not a security breach\stopped by spam filters?
You can open a TCP connection to any mail server and type this, and it'll respond to you and deliver your email (I've omitted responses in the example). On Windows, install Telnet from the Windows features menu and type telnet example.com 25 to connect to the server at example.com on port 25.
As you can see, user4 was addressed in the RCPT TO and it will end up in their email inbox, but they are not mentioned in the from, to or cc headers of the email data. The email data, from the DATA command until the . on a line by itself, is the part that you will see when you open "view source" in your email client. So it has little to do with the actual email exchange. Of course it usually matches, but in a malicious case, they don't care what is "usual". And in the case of BCC you'll also not see it.
A server administrator can also lookup BCCs like this, though of course only of their own domain (if it was BCC'd to [email protected] and [email protected], the administrator of a.example.com will not see stefan).
As to why you can send GMail to yourself in the BCC and see a BCC field with yourself listed on the receiving end: the email program/provider can just send separate SMTP messages for each recipient in the BCC, with the BCC header crafted in the nested email header to list only that recipient.
Headers like To, Cc and From are essentially all cosmetic; they don't control the actual receipients or senders of an email according to the SMTP protocol. It's possible to put whatever you like into these fields and still have separate control over who the email goes to at the protocol level.
When you send an email on the internet your sending mail server communicates with the receiving mail server by SMTP. To send an email, the sending server sends a series of commands to the receiving server.
They were designed to be a user focused representation of who the email was from and to. These fields are a feature used by mail client software (MUAs), which is the software the user actually interacts with to send and read mail.
The usual way for a mail client to work is that the user types recepient addresses into three fields within the mail client called "To", "Cc" and "Bcc" which the mail client uses as a basis for who to send the message to. The mail client takes what was written in the "To" and "Cc" fields and places them into mail headers called "To" and "Cc" as an indicator to the recipient of what the sender originally typed in these fields. This is merely a convention; the sending mail client could choose to keep this secret - indeed, that's what happens with its "Bcc" field: the mail client never creates a "Bcc" header in the email it sends, because the point of that feature is that it's not included in the mail.
It is. It makes it trivially easy to put fake information about the sender or recipients into an email. When users trust that this is accurate and it isn't, that's a potential security problem, because false information can be used to deceive recipients.
Email was designed in an age where bad players (scammers, spammers, malware) were not adequately predicted, so it wasn't properly predicted that these could be used to deceive or impersonate. But, fixing this issue now while retaining the decentralized nature of email is difficult.
Mail clients could simply ignore such headers, but then you would miss out on the convenience of knowing who an email was addressed to when this information exists and is genuine, and by the same logic you'd also have to ignore the "From" and envelope sender (MAIL FROM command) as well, leaving no indication of who sent it. So mail clients take the approach that there is more benefit in showing this information even if it can be faked.
A new standard called DMARC, piggy-backing on other standards DKIM and SPF, can allow a receiving mail client to verify the domain/hostname part of the "From" header is genuine. While this only verifies part of the "From" header and does not verify the "To" or "Cc" header, it allows you to know that the mail was genuinely from the system it claims to come from. If this is a trusted system, you can at least infer that the mail and its headers were created by an authorised user of that system.
Besides these options, email simply wasn't designed for all this to be verifiable. If you want more, you have to use some form of cryptographic verification such as PGP on top of your message and have some out-of-band way of verifying authority.
It can be surprising, but this is quite normal in the SMTP protocol. A message is composed of headers and a body. It is send over a chain of Mail Transport Agents. No agent should change the body, but they can change the headers, mainly to add a Received field, a Date field if it is not present and any other field as required by their own processing. But neither the To nor the From field are special, and in particular they are not used to deliver the mail. The MTAs use what is called the envelope, that is what is passed in the MAIL FROM and RCPT TO commands of the SMTP protocol.
08ab062aa8