Talk:Email attachment

Untitled

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was move for consistency. —Nightstallion (?) 12:15, 20 February 2006 (UTC)

Requested move

Email attachment → E-mail attachment: Spelling per dictionary and other pages in E-mail category. Redirect with multiple edits already exists at destination, so requires administrator.

Add *Support or *Oppose followed by an optional one-sentence explanation, then sign your vote with ~~~~

• Support Barefootguru 20:44, 15 February 2006 (UTC) (proposer)

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Corruption by added dots

I added the section on corruption of email by added dots. This does happen, and is not a one-off occurrence, although hopefully rare.

I have the misfortune of being involvbed with a database which sends out updates via email, using Outlook Express (OE) as MAPI client. After an outbreak of corruption, I find that OE uses quoted-printable (qp) encoding for files which are predominantly ASCII text; this cannot be overriden. When email was sent to users of a particular ISP, a dot was prefixed to every line beginning with the dot. If it just so happened that the database file being sent had a line beginning with a dot, it became corrupted.

This was not a unique problem; there were 4 outbreaks of intermittent corruption on 3 different ISPs. These were simply ISPs we used; this is not the result of a check on a wide selection of ISPs. In two cases the ISP confirmed that there had been an error in software at their end.

Binary encoding protocols don't use the dot character, to avoid just this sort of problem.

I won't go into details, but thsi has to do with the Internet mail system adding temporary dots at one end which are supposed to be stripped off ath the other.

Pol098 17:08, 24 February 2006 (UTC)

Paper clip

A paper clip image is the standard image for an attachment in an email client.

Is that seriously neccessary in the introduction?? --87.122.50.9 (talk) 08:10, 31 May 2013 (UTC)

eParcel affiliate links

Services like [5] eParcel/Attachment-service moves attachments away from email-related systems and timestamp each eParcel to destroy the physical file after downloads. By this method mailbox size and email attachment limits can be circulated for sender and receiver.

To me, the eParcel reference sounds like a big advertisement. See https://en.wikipedia.org/wiki/Wikipedia:Spam#Affiliate_links — Preceding unsigned comment added by LeCrayonVert (talk • contribs) 22:27, 6 November 2013 (UTC)

This looks suspiciously like advertisement. I think a number of alternatives should be mentioned, including Gmail's option to share it via Google Drive, where the recipient gets the option to obtain the file from Drive. I'm rather wary of many attachment links having noticed many virus or phishing attempts spoofing Evernote or MMS sending services. In practice, genuine, non malicious usage of web-based alternatives to attachments seems to be a very small proportion of total attachments or equivalents and a number of non technical users have difficulty when I use Google Drive to share larger files. 94.142.71.46 (talk) 11:15, 24 June 2014 (UTC)

False-positive attachment blocking - dots in filenames look like multiple extensions

I work in a company where many people put a date in a filename on Windows using dots in a format like "Scanned letter from John Doe 10.12.13.pdf" which is allowed by the OS. If these are attached to emails, many servers assume it's a multiple-extension virus attachment, like HappyNewYear.JPG.EXE, even though the true extension PDF is considered safe, and they reject the email, sometimes with a bounce, sometimes without a bounce, but with usually no explanation as to what rule caused its rejection. This is frustrating for users and although email software ought to suggest replacing dots with underscores or similar it usually doesn't, so it would be helpful to explain what might have caused their problems.

Does anyone have a Reliable Source to cite for this phenomenon - especially that it can be a false positive? We could add a False Positive or Rejected Attachment section where we detail typical reasons that attachments get rejected. Wikipedia is often people's first-stop when searching and we could provide a service to the public by paraphrasing and referencing sources of good information, but we must not contribute original research and thus cause Wikimedia Foundation to be liable for consequential damages if the information is.

Certainly, a brief list of commonly-rejected file types could be included (and references are easy to find), including extensions denoting executable or macro-containing files. A brief list of common tactics for malware and would also be helpful (e.g. Invoice.zip and links to files purporting to be from a reputable company using a similar-looking domain like invoices-amazon.com for example or linking text that looks like a legitimate URL to a download link that is not legitimate.) Dynamicimanyd (talk) 09:54, 3 July 2014 (UTC)

Dangerous file types

The structure of the this sentence is weird.

However, in practice this advice is not enough – "known trusted sources" were the senders of executable programs creating mischief and mayhem as early as 1987 (with the mainframe-based Christmas Tree EXEC), so since the ILOVEYOU and Anna Kournikova worms of 2000 and 2001 email systems have increasingly added layers of protection to prevent potential malware – and now many block certain types of attachments.

Especially the senders of executable programs creating (created?) mischeif

I would also cut the sentence in two after early as 1987 (with the mainframe-based Christmas Tree EXEC) and start the second sentence with Since the ILOVEYOU... — Preceding unsigned comment added by 76.69.153.52 (talk) 20:31, 1 December 2014 (UTC)

size limits

On the surface this article is not specifically about size limits -- yet that is actually the main content, and the reason many readers will come here, as an important Internet resource. To adequately inform about that, it should clarify the issue of sizes of individual attachments vs the total size of a group. My impression is that most email services impose a limit on the total in one email, rather than a smaller limit on each attachment. To educate the general reader, it might be worth mentioning that if an email cannot be sent due to the total size, if there is more than one attachment it may be possible to send them individually in separate emails. And to further that aspect, for the sake of completeness it might even be worth mentioning that it is possible to break up a large file into pieces, send them in separate emails, and then re-assemble them...-71.174.188.32 (talk) 16:57, 15 December 2015 (UTC)

embedded vs. attached

Image files can either be "attached" in the old way, or "embedded" inline in a new way. The article should mention this, and at least link to info about embedding. I think the content encoding is the same in either case, just the contextual format of the email framework differs? Some email access (eg gmail online) can make it difficult to obtain embedded objects as separate files.-71.174.188.32 (talk) 17:02, 15 December 2015 (UTC)

An embedded image is actually a regular attachment, the same as before, except the HTML version of the email (which is usually an attachment, itself, separate from the plain text proper message body) has an img tag that references the attached image file. Nothing is really different about the email itself, what is different is how the client program for reading emails processes that email which allows an attached image to be able to be displayed inline in the HTML version of the message. It's kind of like having a TV that can display one channel within another channel at the same time (picture in picture), there is nothing different in the video signal of either channel, the TV itself just has new bells-and-whistles that make it possible (you can bring that TV back to 1966 and it would work just the same). — al-Shimoni (talk) 09:16, 2 January 2016 (UTC)

10MB size limit equals 7MB of attachments

• luxsci.com/blog/raw-vs-encoded-email-message-size-whats-the-difference.html

Raw vs. Encoded Email Message Size — What’s the Difference?

This encoded size is the actual size of the message as it travels over the Internet and is always larger than the raw size because of the MIME overhead and because binary attachments are generally encoded using base64 encoding. Base64-encoded files are usually about 137% the size of the original files.

7.3MB times 1.37 inflation due to encoding equals 10MB. So a 10MB email size limit (still somewhat common in 2016) means that the size of the attachments is actually limited to about 7MB.-71.174.190.122 (talk) 16:02, 20 December 2016 (UTC)

Trim/Tidy changes meaning

The recent Trim/Tidy edit moved the section on shar/bundle from text-only into the realm of binary attachments. Shar/bundle can only handle text files included in the message body, and implies they came before uuencode. Shar and bundle date from 1984 and uuencode was written in 1980. You do a nice job of wordsmithing, perhaps you can find an elegant way to word this while remaining historically accurate? — Preceding unsigned comment added by Gazotz (talk • contribs) 18:46, 26 March 2017 (UTC)

Happy for the correction. Shell archives *are* text, and the 'shar' can be (now) be used to encode binary files to text. However, it seems 'shar' couldn't originally handle binaries, and when it did get this ability,[1] it was via uuencoding them. So, I'm sure you're right, and will reword to say so - but I'm struggling to find good refs for the sequence. Got any? Snori (talk) 20:25, 26 March 2017 (UTC)

Thanks! Happily, there is a shar entry in Wikipedia that documents (and gives the code for!) a 1983 version that was text only.Gazotz (talk) 23:16, 27 March 2017 (UTC)