On 15/11/2014 12:35, Ian Gillis wrote:

So any future mobile app. for Groups IO shouldn't demand a password to see a photo.

Will attachments be sent with the outgoing emails? Yahoo has taken to
removing them and adding a link (which isn't always visible!), which is
unhelpful if you want to keep them - as well as adding an extra stage of
work for the recipient.

--
rgds
LAurence
<><

Mark,

I personally _hate_ this "feature" of Y! Groups. All attachments sent
through groups.io are sent along to the subscribers.

The "Store on site" option for attachments is actually quite useful - when it works (or worked).

As originally designed and implemented the link provided in lieu of each attachment is a permalink which allows access regardless of whether the user has a Yahoo account or is signed in. A part of the URL is random-generated so that a link to one attachment cannot be used to infer a link to other attachments; nor can the links be used to access other parts of the group's web site without sign-in.

The key advantage is that allows members who read the group's archive or digest (rather than individual messages) to have access to the attachments. With the other option (include in emails) the attachments are sent to members on individual messages, but no other members could access them.

Groups.io appears to implement the long-sought (but never implemented) "both" option - an attachment is both forwarded in individual messages and a copy kept on site for the archive. I haven't investigated what happens for members on digest (pending tonight's digest of my test group).

Another touted advantage was a reduction in the download burden for members on slow, limited or metered email connections; those members could decide if and when to download the attachments. But with the supremacy of Webmail and mobil apps these days this seems a very niche benefit. To be a real benefit this would need to be a membership option, rather than a group option, and perhaps tied to a size threshold for attachments to be included or linked.

-- Shal

Ian,

Now I find that setting Yahoo to "no html" means that mails *with* html
are bounced...

That shouldn't happen, unless the message has no text/plain part.

I just re-tested this in my test group and verified that a message with both text/plain and text/HTML parts is accepted by a group set to "Plain Text" - the text/plain part posts and the text/HTML part is discarded. The bottom of the message has appended the notation:

[Non-text portions of this message have been removed]

A message with no text/plain part is bounced in such a group, but this has always been true.

I'll agree that " HTML - Include Attachments as links" is the worst of
both worlds.

Not me. It is still my preferred setting for Yahoo Groups.

Specifically because it means the attachments are available in the archives. Seeing today that Yahoo has broken the stored attachment feature, and now requires sign-in for access to photo attachments, I might have to re-think that.

-- Shal

On 16/11/2014 01:27, Shal Farley wrote:

The key advantage is that allows members who read the group's archive
or digest (rather than individual messages) to have access to the
attachments.

Would it be possible to have an option to include attachments in a
digest? Another (now defunct) list operator used to do this, but I think
if it is to be done it should be an option for the subscriber.

There are groups where I take the digest because I am interested in the
conversations but not in the attachments.

--
rgds
LAurence
<><

Mark,

It's easy enough to include links back to the website to view the
attachments, and that's on the todo list.

Is it feasible to make those links work, regardless of whether the user is signed in? That's valuable for email-only members.

The only "trick" to this I'm aware of is to include a randomly generated value in the URL so that having one such link in hand doesn't allow one to discover others.

-- Shal

Mark,

My concern with this comes back to abuse. I don't want groups.io
<http://groups.io> to become an image serving company.

Or general file serving. I understand that concern, and realize that abuse detection and mitigation impacts what's feasible.

I would want to come up with a system to throttle image serving in
case a URL gets out in the wild and becomes popular.. I can do it,
but it'll be some work and I'm not sure about where this would rank
in terms of priorities.

Maybe "trust but verify" first. That is, come up with a way to measure and report the usage in a way that would alert you to abuse. Then figure out how to throttle it if and when the alarm goes off. Then you'd be able to see the use and abuse patterns before deciding on a mechanism. Of course, that assumes that the onset of trouble is mild rather than DOS-inducing.

-- Shal