Received from Mark Fletcher at 8/23/2018 05:09 AM UTC:

Ok, so new group option for dealing with spam: either moderate or reject, with reject being the default. Rejected messages will be logged in the activity log. If I reject a message, should it bounce back to the sender, or should I blackhole it?

Don't bounce! REJECT during the SMTP transaction if possible. And if not possible, then just blackhole it.

If a message in the archives is flagged as having a virus or phishing attack, should I put a banner on the page saying so? (and should I go back through the archives doing scans)?

For viruses I'd prefer deletion. Given a settable option I'd choose deletion and take the tiny chance it's a false positive rather then set myself up to second guess the scanner. Scans for phishing based on keywords in message bodies are less reliable so a banner might be the thing for that.

Yes on scanning existing files/images (binaries) for viruses. Not sure scanning archived message text would provide much added benefit, but if you have the CPU horsepower, it can't hurt.

The fact that many/most groups don't accept messages from non-subscribers acts as a natural prevention for a lot of this crap.

That and also some groups don't accept attachments... and are plain text only. I've NEVER seen spam or viruses - or even phishing attempts - in plain text email with no attachments.

I don't accept smtp connections from IP addresses that don't have reverse DNS records. I use a few blocklists as well, for all connections to the site, not just email. I haven't done anything with SPF and DKIM data yet.

This is very good to know.

Jim H

On Thu, Aug 23, 2018 at 11:19 AM, JohnF wrote:

I would lean toward dropping rather than bouncing spam/malware/phishing, just because the system on the other end might misclassify groups.io as the source of the malware.

If you do bounce it for malware, whatever triggered the malware alert (attachment or link to dangerous site) should be stripped from the bounce message to avoid this.

JohnF

I am 100% in favor of reject and not bouncing.

If you want more info - read on here: http://www.dontbouncespam.org/

--
Gerald

I would lean toward dropping rather than bouncing spam/malware/phishing, just because the system on the other end might misclassify groups.io as the source of the malware.

If you do bounce it for malware, whatever triggered the malware alert (attachment or link to dangerous site) should be stripped from the bounce message to avoid this.

JohnF

Rejecting is annoying, but aggressively scrubbing malware from multipliers like groups.io is good policy in my book. Moderators should hesitate and consider carefully a decision to take the "moderate" option. Letting a malevolent email loose on your group could destroy it. Look at the annoyance of automatic rejection as a price a small price paid for the convenience and pleasure you get from membership in a groups.io group.

How likely is it that a clean message will be identified as infected? We aren’t talking about spam which is identified on the basis of words used, etc. Right?

If the messages are being scanned for malware, is it safe to allow attachments? I have a large public list on which we have rejected attachments for years. Since my personal malware software finds viruses in my non-list email regularly, it certainly is still getting through whatever other email systems see it.

Sharon
----
Sharon Villines
TakomaDC@Groups.io
"Neighbors Talking to Neighbors”
Takoma Park DC and MD

Hi Mark,

If I reject a message, should it bounce back to the sender,
or should I blackhole it?

Reject (5xx) during inbound SMTP-session.

If a message in the archives is flagged as having a virus or phishing
attack, should I put a banner on the page saying so? (and should I go back
through the archives doing scans)?

At least give moderators the option to silence false positives which are inevitable, especially about phishing.

--
Lena

Dave,

Will there be an option to disable spam checking?

Keep in mind this isn't about simple spam. This is about content which may be malware-infected or a phishing attempt. Detecting these specific things is likely to be much less prone to false positives than a generic spam filter.

Shal

Mark,

If I reject a message, should it bounce back to the sender, or should
I blackhole it?

Given that the sender passed a reverse-DNS I'd say it is safe to bounce it back. Chances are the message was sent by a compromised account at an otherwise legit service. (And maybe the rejection lets them know they've got a problem user?).

If a message in the archives is flagged as having a virus or phishing
attack, should I put a banner on the page saying so?

On the whole I'd say "yes".

The counter-argument is that if the group's mods accepted the message then they might not appreciate having the (presumed false-positive) marking on the message. But I think that the members deserve to know that there was at least some doubt about this content.

(and should I go back through the archives doing scans)?

Optional, but probably a good idea. The question is what you'd do besides mark them. I think adding entries for them to the Activity log may be sufficient (for mods to go find them if they want).

I haven't done anything with SPF and DKIM data yet.

One step at a time. Though I might have expected these before content scanning. But I may have a skewed view of their relative difficulty and effectiveness (eg: these don't apply to uploads).

Shal

I take it this has not been implemented yet Mark, I see no options for
dealing with spam other than the existing ones under 'spam control' for
which in our case 'restricted membership' is the only relevant one.

Will there be an option to disable spam checking? I strongly feel there
should due to false positives, especially in private groups which
rarely have spam issues. I only look in the activity log rarely and
only if I have issues, 'moderation' of posts is an unwelcome extra
burden which I would really not want to do. Our groups just don't
suffer from spam, I would not really want false positives to get in the
way of an otherwise excellently running service.

Dave

On 22 Aug 2018 at 22:09, Mark Fletcher wrote:

Ok, so new group option for dealing with spam: either moderate or
reject, with reject being the default. Rejected messages will be logged
in the activity log. If I reject a message, should it bounce back to the
sender, or should I blackhole it?

http://davesergeant.com

On Tue, Aug 21, 2018 at 09:42 PM, Shal Farley wrote:

I don't think I would go as far as Lena suggests, and moderate them without that being a group option; I'm concerned that few group moderators would have the knowledge to make a safe decision for their group. A choice between "moderate" or "reject" might be useful, with "reject" the default.

Agree with Shal on this. An email reflector like groups.io, is a multiplier-- it turns a single email into many emails. Cybercriminals love this. Send out a malevolent email to a single address and, depending on the size of the group, the poison goes to hundreds or thousands of potential victims. And those victims are predisposed to swallow the poison because it comes from a familiar source that they intentionally subscribed to. Even better if the email spoofs the name of a prominent member. This is a hacker's dream setup. These criminals are not nice people. Give them a chance and they will hurt you.

Rejecting is annoying, but aggressively scrubbing malware from multipliers like groups.io is good policy in my book. Moderators should hesitate and  consider carefully a decision to take the "moderate" option. Letting a malevolent email loose on your group could destroy it. Look at the annoyance of automatic rejection as a price a small price paid for the convenience and pleasure you get from membership in a groups.io group.

Best, Marv

Mark,

> My default implementation would be to turn it on so that it blocks all
> emails, files and photos that it finds has a virus or phishing
> attempt.
> Do you see any reason to not do it this way?

"Block" = "Drop" or "Reject"?

Drop is a very severe action, and I'm not entirely sure it should be done even with non-subscribers. With subscribers at the least I'd recommend "reject" (and add to the Activity log).

As Jim and some others, I was thinking maybe have a group option to put those from subscribers in the pending queue, prominently marked as containing potentially harmful content. This would serve the small fraction of groups who might be studying such things, or might be sharing harmless executable files that trigger a false positive.

I'm sympathetic because once long ago forwarding a message to abuse@... or spam@... was a common way certain senders requested that non-users (of their service) should report "bad" messages coming from their service. But I had an ISP that blocked suspicious messages outbound by me, so I couldn't send the requested report.

I don't think I would go as far as Lena suggests, and moderate them without that being a group option; I'm concerned that few group moderators would have the knowledge to make a safe decision for their group. A choice between "moderate" or "reject" might be useful, with "reject" the default.

By the way, I assume none of the above applies to the boatloads of absolute junk from invalid sources (malware-infected PCs and the like) that I presume you've been dropping all along. Those deserve the black hole treatment.

Shal

I don't expect scanning to change anything here for me since my groups use plain text and no attachments in the first place.

Actions? Perhaps DROP ALL and DROP ATTACHMENT ONLY should be available... as well as maybe some sort of "Quarantine for Review/Moderation by Group Owner" option.

Notification? Notify Owner, Notify Sender, Notify Both seem like decent options. Notify Owner (or both) seems to go hand in hand with an action of "Quarantine for Review..." (above).

Jim H



Received from Mark Fletcher at 8/21/2018 03:24 AM UTC:

Ellen Moody <ellen.moody@...> wrote:

I just read that Groups.io is down for maintenance. We were informed it
will be back by 11 pm pacific time and 4 am UTC (? -- I don't know what
that is).

UTC - Co-ordinated Universal Time. Pretty much the same as GMT.

West coast USA is GMT-8 (-7 in summer) and East coast is GMT-5 (-4 in
summer).

--
rgds
LAurence
<><

Ellen,
Planned outages are posted as events on the calendar in the Beta/Main forum.  If you have your timezone configured correctly (Account -> Preferences), when you view the calendar and hover over the event, the time of the outage will be displayed in your timezone.  As shown here (I'm in Central (Chicago) timezone):

Information on what is affected by the outage is included in the event.
Thanks
Toby

Pacific time is 3 hours earlier then Eastern time So when it is 11PM Pacific Time it is 2AM Eastern Time   Pacific 11PM Mountain 12Midnight Central 1AM Eastern 2AM