开云体育

LeeAnne wrote:

I did some experimenting on how copied and pasted pictures are viewed by
various ways member's receive their emailed messages. ...

/g/GroupManagersForum/message/747

I suspect GMF's wiki needs an advice article on the subject for Group Members but before delving into the research necessary to write it, I thought I'd set down some background information.

Plain Text messages

A plain text message cannot have an image (or any other formatting) contained within the message body. It can however carry attached files, and files containing photos or other images can be carried that way.

There is some variability in how various email user interfaces treat attached image files. Some will show the image immediately following the message body. Some show a thumbnail of the image with a link to open it to full size. Others will show only the file name and a link to open it.

How an attached image file is treated by a receiving user interface can also be influenced by how the image was encoded by the sending interface. The standard which covers such attachments (MIME - Multipurpose Internet Mail Extensions) allows various ways of describing the file content as well as various transfer encoding methods for carrying the file content. The choices made by the sending user interface may affect the presentation made by the receiving user interface.

HTML (formatted) messages

HTML (Hyper Text Markup Language) adds options for conveying an image to be presented as part of the message body. Within the <img> tag (which defines the position, size, and other characteristics of how the image is to be displayed) the src attribute tells the receiving email user interface where to find the image file. The fundamental choices are known as schemes.

cid: (content ID). This scheme is the default used by most user interfaces when you upload or open an image file from your computer's files. It tells the receiving email user interface that the image is contained in an attached file within this email message, and the ID tells it which attached file is used for this <img> tag.

data: This scheme is newer, and tells the user interface that the image file is encoded right here in the message body (within the <img> tag), not in a separate file.

http: (Hyper Text Transfer Protocol). This scheme tells the receiving mail interface to fetch the image file from a server on the internet. Images conveyed in this fashion are sometimes referred to as "remote" images. Remote images are often used in commercial email to reduce the size of the email message itself and lower transmission costs. However they do represent a privacy concern because the act of fetching the image file can be logged by the remote server and used to track if and when people read the email message. For this reason many email user interfaces will not automatically display a remote image. The user may be asked to click to display the image, or to always display remote images from that particular sender.

Bottom line

There are many reasons an image might not show up in received messages, or might show for some recipients but not others. And the sending user generally has limited ability to control how an image will be conveyed in their message.

Knowledge of these details can be crucial to determining what happened when messages don't display images properly. Fortunately the View Source (or View Original) of the received message will identify how the image was conveyed by the sending user interface. Unfortunately that alone will not tell how various recipient's email user interfaces might treat the image.

Shal

LeeAnne,

I wrote:

Plain Text messages

A plain text message cannot have an image (or any other formatting)
contained within the message body. It can however carry attached files,
and files containing photos or other images can be carried that way.

A factor that can affect delivery of attached image files: if a member has set a Max Attachment Size in the Advanced Preferences section of his/her group Subscription, and the image file exceeds the limit, then the attached file is removed from the message sent to that member, and a link to the site placed at the bottom of the message instead.

HTML (formatted) messages
...
cid: (content ID). ... It tells the receiving email user interface that
the image is contained in an attached file within this email message,
and the ID tells it which attached file is used for this <img> tag.

The member's Max Attachments Size affects this scheme as well, removing the image attachment and instead placing a link to its file on the group's site at the bottom of the message.

data: This scheme is newer, and tells the user interface that the image
file is encoded right here in the message body (within the <img> tag),
not in a separate file.

I'm not sure if that limit is applied to this scheme. I'd test it if I knew of a way to generate test messages that use this scheme, but the user interfaces I've tried (Gmail's web interface, Thunderbird, and Eudora) only generate the cid: scheme. Or if they can generate the data: scheme, I've not figured out how.

One could argue that the Max Attachment Size setting shouldn't affect this scheme, because the data: scheme is technically not an attachment. But the counter argument is that ignoring the data: scheme defeats the purpose of the attachment limit: to reduce the data consumed by the message.

http: (Hyper Text Transfer Protocol). This scheme tells the receiving
mail interface to fetch the image file from a server on the internet.

This one should not be affected: the data representing the image is not in the message.

Shal

On Sun, Sep 4, 2016 at 10:30 pm, Shal Farley wrote:

data: This scheme is newer, and tells the user interface that the image
file is encoded right here in the message body (within the <img> tag),
not in a separate file.

One could argue that the Max Attachment Size setting shouldn't affect this
scheme, because the data: scheme is technically not an attachment. But the
counter argument is that ignoring the data: scheme defeats the purpose of the
attachment limit: to reduce the data consumed by the message.

data: doesn't consume storage where the 1 GB free limit is.

Lena,

data: doesn't consume storage where the 1 GB free limit is.

Interesting point. I wonder if that gives Mark a motive to detect the use of data: and treat it as if it had been cid:, at least for the purpose of storage.

The user's subscription control for max attachment size is about the metering or other download restrictions some users may face, particularly on mobile devices. And for that purpose I think it would be more useful if Mark did detect data: and apply the same restrictions.

Shal

In the message editor, I can paste HTML code to source an image file in the Files folder and it displays fine on the website. However, the email received by my Gmail has the Display image button but the image link is broken. I can email an inline image to the group and it is reflected back to the same account intact. That image gets stored in Photo Albums > Emailed Photos. I can reuse that image in another message by copying its URL from its Download button into an <img> tag but it, too, is broken in the received email.

• It seems that the only ways to ensure images are delivered by email are:
  • to post from email or
  • to upload from within the website message editor.?
• image files in the group's Photo Albums cannot be reused in new posts for delivery by email; they are replicated

I'm trying to migrate a Wikispaces site and have its many pages in exported HTML format with their relative links to image and non-image files in the relative folder "files/" which corresponds very nicely to the root of the Groups.io Files area to which I have batch uploaded them. Although G.io does not support batch upload of messages, I can paste the HTML code from an exported page into the message editor's source code window and the message is done - images display (may need to resize) and file links work on the website. I really don't want to have to upload them to each message.

Am I missing something? Maybe I'm just barking up the wrong platform but I have yet to find the silver bullet.?

On Mon, Jun 25, 2018 at 07:35 am, Tom H wrote:

In the message editor, I can paste HTML code to source an image file in the Files folder and it displays fine on the website. However, the email received by my Gmail has the Display image button but the image link is broken. I can email an inline image to the group and it is reflected back to the same account intact. That image gets stored in Photo Albums > Emailed Photos. I can reuse that image in another message by copying its URL from its Download button into an <img> tag but it, too, is broken in the received email.

I believe this is because you must be logged in to see Files and Photos on the group and an email program won't be logged in.? If you used a link to the image that was stored on an open site, it should work.

Duane
--
Help: /static/help
GMF's Wiki: /g/GroupManagersForum/wiki
Search button at the top of Messages list
A few site FAQs: /static/pricing#frequently-asked-questions

I want the public to view what's in Files and Photos so, at the moment, my only option is to store them outside Groups.io. In that case, it would be easier to build the site outside Groups.io as I already have a set of working HTML files and linked image and non-image files.?

Otherwise, would an optional setting for Files and Photos Permissions be a reasonable request?

1. Public can view
   1. Subscribers can view
   2. Subscribers can upload

On Mon, Jun 25, 2018 at 12:31 pm, Tom H wrote:

would an optional setting for Files and Photos Permissions be a reasonable request?

I have encountered many situations where this would be handy, including the placement of a group photo on the group's home page (using an <img> tag) and being able to insert a link to our membership application in our Pending Subscription notice.

Optimally, I would prefer it to be a security option at the folder level, not a group setting. If you were to I would give it a bump.?

Regards,
Bruce?
--
The system Help is your friend.??/static/help

Thanks. Have posted a request but I see that perhaps I should have tagged it #suggestion. I hope Mark reads them all.

Another Permissions option that is conceivable but really risky is "Public can upload". I can't imagine any owner wanting that.