Ilene,
I don't know what a signature tag request is but it sounds like groups.io may not be a good fit for these offer announcements.  Even email is not a good mechanism as there is no way to ensure that all recipients receive the message at the same time, if that's what's intended.  I know of no way to have the message emailed but not displayed on the web site.  Even locked topics are still visible and the member can then check their email to reply directly to the poster.
A group text message with the email of the poster and info on the offer might be a better approach as that is more "real time".  
Just a thought.
Toby

I don't know if this has been addressed or not. I know that the shortest amount of time that a message can be locked is 1 day if it isn't locked manually sooner.   Is there any way a selection could be added to have messages automatically  locked as soon as they are sent OR another option would be having a way to hide the messages from the members.   The reason behind my question. My groups are Signature Tag Request groups. One group the offers are really short term offers like for the first 10 members who request.   Most members are getting the offer via email as my group is basically an email group and that is what we need it to be. Not a forum where they can read the offers from the group pages.   There are a few members who hang out at the messages waiting for new offers to come through and they are at an advantage to get their requests in quicker then anyone else and end up getting all of the tags that way.   While I am online almost 24/7 I can't lock the messages quick enough.   Thanks. Ilene                               

Mark,

Honestly not sure what, if anything, to do with SPF and DKIM. Seeing
plenty of valid emails with bad DKIM sigs, for example.

I have two goals:

1) Prevent abuse posted to a group such as that I reported to support 8/11. This is where a malcontent or crook uses credentials at an otherwise legit mailbox provider to spoof a group member's address, resulting in junk posted to the group.

2) Eliminate the need for a confirmation email and response for email commands in most cases.

Case (1) is the more important, but I think (2) is easier. Mostly because there is no adverse consequence of a failed authentication in case (2) - you just send the confirmation email as you do now. You could accept the OR of two tests: a valid DKIM, signed by the header-from domain as one test; or a passing SPF but only if the the header-from domain is aligned with the envelope-from domain as the other test. This happens to be the same as the DMARC criteria, I think. So in the case of a "pass" you send a notification of the command's acceptance and effect rather than a request for confirmation.

In case (1) the difficulty arises if both tests fail. That's sure to be true in the case I want to weed out, but I don't know how many legit messages might be affected. I think the case you cited to me on 8/13 would be one such; unless we (you) can figure out something he could tell you by way of account information that would let you make a third test that would pass his messages.

My inclination is to say that it is "good enough" if you force messages that fail both tests into the pending queue, as if sent by a non-subscriber (but with a different marking, of course). That would have allowed the group mod in my support case to discard the abuse before it hit the group.

Yes, that would be a pain for the second fellow, and his group mods. But he's already committed to switching Thunderbird to use the correct SMTP server, so that should solve his case. One down...

Shal

I'm fine with that, too. Our messages are not very long anyway, and all we really need to see is the gist of the message.
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

Hi All,

It's been a couple of days since the unplanned downtime on Tuesday. Here's a summary of what happened and what I've done to address it.

What Happened

• I was paged at approximately 6:50am on Tuesday; the alert indicated that all web servers were down. The page and alert were correct and timely.
• It took me about the next hour to figure out the problem. The web servers were running out of connections to the database and were constantly restarting. It appeared the reason was a change I made to the chat system the previous day.
• I disabled chat, restarted all the webservers, and the site was back up.
• Email delivery was not affected during this time.

Changes Made

• I believe I've addressed the bug of chat taking up all the database connections, although without a stress test (ie. a large group of people using it) I am not positive.
• I have partitioned the chat system so that even if it does in the future have a resource leak like this, it will not take down the webservers. It would only affect chat.
• I have implemented a connection pooling system in front of the main database system and reevaluated all database connection timeouts, to make the overall system more resilient to any sort of database connection leak.

Thanks, Mark

On Thu, Aug 23, 2018 at 12:01 PM, J_Catlady wrote:

Another idea would be to have a dedicated "direct add" page, just like there's now an "invite" page, and log the messages only there in both cases.

I think having everything logged in one place, with the option of the amount of detail displayed, is a better option.

Peace,
Tom

--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

Mark,

If that is true, I BEG you to at least make it an option to include the message in the log,  We use the log daily and send out an extensive direct add message.  This change makes the log just about unusable, at least for us.

PLEASE include an option for a "one line log entries" or "detailed log entries" (maybe at the top of the page).

Thanks for your consideration.

Peace,
Tom

Could be because a few days ago I asked Mark for direct-add messages to be logged, just as invite messages are, for consistency.
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

All of a sudden we have the full email message showing up in the activity log when we do a direct add.  This is what it looks like:



Did the same thing a few days ago and got this one liner:


I don't think I made any changes which would affect this area.

Suggestions?

And now that I have them, is there a way to delete an item from the activity log?

Peace,
Tom Vail

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