开云体育

Noel,

Looking at the source of the emails, the faulty one has the picture
as
src="/g/ngauge/draftattachment/442690/0/DSC_3238.JPG"

The https: there means that the image is not contained in the message - the receiving system must go fetch it from the named web site.

While for a previous post that did work it is:
src="cid:[email protected]"

The cid: there means that the image is contained in an attachment to the message. Further down in that view source you'll encounter a (possibly large) block of encoded data which is the image file itself, likely base64 encoded, and delimited by that marker you see after "cid:"

So the claim "done in exactly the same way" is cast in some doubt.

Oddly he says he can see the picture fine in the posting he received,
but nobody else can.

That could be explained if he is a member of the "ngauge" group and the rest of you aren't. Or may be explained by the "draftattachment" part of the URL, implying that the image is in a part of the site (his draft messages) that only he can access.

Is it a bug ?

Maybe.

You didn't say whether he composes his messages using the group's site or via his email user interface.

The "draftattachment" part of the URL suggests to me that he composed the message on the group's site. If that is the case then I'm not sure how or why the site would choose to reference the image file remotely (https) rather than include it as a message attachment (cid). Possibly that is a bug with the Draft mechanism in Groups.io.

If he composed the message in question using an email interface, then he may have inadvertently done a drag-n-drop from the image in a Draft he was composing for the ngauge group, and then failed to override the email interface's default of using https for images dropped from web sites. In this case the difference between this message and his others could be simply that this time the image he used wasn't on his computer, but in Groups.io's servers.

Shal