Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Russ Allbery)
2. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Russ Allbery)
3. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Grant Taylor)
4. Re: add "Auto-Submitted: auto-generated" to generated EMails?
(Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Sun, 12 Mar 2023 12:01:09 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID: <[email protected]>
Content-Type: text/plain
Grant Taylor <[email protected]> writes:
> Is it not possible to ask moderators to add an additional email account
> that is specifically used for moderation and for that account to be hosted
> on a mail server that is specifically configured ~> tuned to deal with
> such messages?
Good luck finding one of those unless you run your own mail server. A
server without spam filters is basically unusable by ordinary people for
any ordinary purpose, so there's not much of a business model there.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Sun, 12 Mar 2023 12:29:36 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID: <[email protected]>
Content-Type: text/plain
Grant Taylor <[email protected]> writes:
> I question how weird the arriving moderated message looks. Maybe there
> is some nuance to application/news-transmission has compared to
> message/rfc822 (from memory). But I feel like message/rfc822 is quite
> well supported in fat MUAs and some thin web based MUAs are learning how
> to use it too. I strongly suspect that application/news-transmission
> can ride message/rfc822's coat tails.
So, I admit it's been a long time since I've run a large mail server or
had to deal with spam filter tuning directly (I have my own quirky
personal thing that's tuned for only me and that doesn't have any of these
problems because it has an entirely different set of problems), but my
recollection is that spammers *loved* hiding phishing and malware in
various types of unusual attachments, particularly attachments that would
automatically be decoded by a client. And as a result spam filters
frequently added rules to drop or reject any messages that have that sort
of nested structure because they diagnose it as attempting to hide malware
from spam filters.
message/rfc822 is recursively inspectable, so hopefully good spam filters
do that instead of restrict it and given the prevelance of forwarded mail,
you're probably right. application/news-transmission... I dunno. I'm
pessimistic, but possibly unduly.
> Please elaborate on what spam filtering you're talking about? Are you
> referring to the spam filtering in the email path? Or are you referring
> to spam filtering in the moderation stack?
The email path up to the point where the moderator sees the message to do
something with it. That can include local post-delivery spam filtering by
their ISP.
> Any email server worth it's bits should not be silently throwing away
> messages.
This battle was lost years and years ago for most email. The majority of
email addresses used by regular people silently throw away messages.
Sometimes that's in the form of putting them in a spam folder no one looks
at, but that's basically the same thing in practice.
Now, maybe this isn't true of moderators, who are probably odd, unusual
people compared to most email users. But also note that rejecting a
moderated group submission is in practice equivalent to silently dropping
it; the bounce message is unlikely to go anywhere useful unless you have a
particularly obsessive local news administrator.
Out of curiosity, I checked, and only two moderators currently use Gmail
as a submission address (and I suspect those are both dead groups; almost
all moderated gorups are dead).
> I feel like there is another option that I've not yet seen discussion
> about. What if moderated messages are sent through email as
> message/rfc822 or application/news-transmission and then on the
> receiving end, a shim of sorts is put in place between the receiving
> email server and the existing moderation stack that detaches the
> attached / moderated message and feeds just the moderated message into
> the moderation software?
Sure, but in a sense this just moves the problem. If we send
application/news-transmission to such a server, which then removes the
encapsulation and sends the same message as today, we've just made a more
complicated version of today's system. We don't see any benefit until we
can send the encapsulated message directly to the moderator, and
moderators use a wide variety of different email providers.
So one way or the other we have to figure out how to get moderators to
change their software, and since they're not all going to do that at once,
some way to figure out when they have done so and can receive ecapsulated
messages.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Sun, 12 Mar 2023 16:02:16 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 3/12/23 1:01 PM, Russ Allbery wrote:
> Good luck finding one of those unless you run your own mail server.
I had in mind that the news server (organization) might be able to run a
special use case mail server and keep it isolated from the rest of the
Internet email ecosystem.
> A server without spam filters is basically unusable by ordinary
> people for any ordinary purpose, so there's not much of a business
> model there.
I largely agree. But the special / dedicated use case tends to sidestep
your otherwise valid concerns.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20230312/ffd7a7f2/attachment-0001.bin>
------------------------------
Message: 4
Date: Sun, 12 Mar 2023 16:15:22 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: add "Auto-Submitted: auto-generated" to generated EMails?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 3/12/23 1:29 PM, Russ Allbery wrote:
> So, I admit it's been a long time since I've run a large mail server
> or had to deal with spam filter tuning directly (I have my own quirky
> personal thing that's tuned for only me and that doesn't have any of
> these problems because it has an entirely different set of problems),
> but my recollection is that spammers *loved* hiding phishing
> and malware in various types of unusual attachments, particularly
> attachments that would automatically be decoded by a client. And as
> a result spam filters frequently added rules to drop or reject any
> messages that have that sort of nested structure because they diagnose
> it as attempting to hide malware from spam filters.
Ya. There's a slippery slope of servers filtering unknown attachments.
But message/rfc822 is not an unknown attachment.
There's also a slippery slope of filtering -- what are broadly referred
to as -- archives, especially those that contain nesting. But agian,
message/rfc822 is not an unknown archive and it's an archive (of sorts)
that is being parsed. There is some room for detecting and thwarting
recursion.
But I believe the days of blocking all but a specifically curated list
of attachments are largely behind us as it has has too much collateral
damage and is relatively easy to defeat.
> message/rfc822 is recursively inspectable, so hopefully
> good spam filters do that instead of restrict it and given
> the prevelance of forwarded mail, you're probably right.
Ya, deep recursion can be a problem. But it's possible to more
intelligently reject with a message related to deep recursion.
> application/news-transmission... I dunno. I'm pessimistic, but
> possibly unduly.
Fair enough.
Though I think it could be possible to handle it much like
message/rfc822 if someone wanted to. But the current deployment will stand.
> The email path up to the point where the moderator sees the message
> to do something with it. That can include local post-delivery spam
> filtering by their ISP.
Thank you for clarifying what I suspected. That rules out filtering in
moderation software from the part of the discussion that I'm trying to have.
> This battle was lost years and years ago for most email. The majority
> of email addresses used by regular people silently throw away messages.
Let's agree to disagree.
> Sometimes that's in the form of putting them in a spam folder no one
> looks at, but that's basically the same thing in practice.
I don't think so. It may be a similar effect, but it's definitely not
the same thing.
The message is there for the user if they want to get it. The message
was not lost in the email network.
> Now, maybe this isn't true of moderators, who are probably odd, unusual
> people compared to most email users. But also note that rejecting
> a moderated group submission is in practice equivalent to silently
> dropping it; the bounce message is unlikely to go anywhere useful
> unless you have a particularly obsessive local news administrator.
I don't know what the expected norm is for moderated newsgroups. With
my postmaser hat on, I'd somewhat expect a message to go back to the
purported poser indicating that their message had been rejected. Though
this can be a slippery slope for a number of reasons. Rate limiting and
Joe jobs come to mind.
> Out of curiosity, I checked, and only two moderators currently use
> Gmail as a submission address (and I suspect those are both dead
> groups; almost all moderated gorups are dead).
/me winces
Given Gmail's propensity to filter things, I suspect that moderated
messages rarely make it into the moderator's mailboxes.
> Sure, but in a sense this just moves the problem. If we send
> application/news-transmission to such a server, which then removes the
> encapsulation and sends the same message as today, we've just made a
> more complicated version of today's system. We don't see any benefit
> until we can send the encapsulated message directly to the moderator,
> and moderators use a wide variety of different email providers.
To clarify, I was thinking that the encapsulation would happen on the
news server sending the message for moderation and that the
decapsulation would happen after SMTP, likely as part of the LDA, on the
moderator's email system.
> So one way or the other we have to figure out how to get moderators
> to change their software, and since they're not all going to do that
> at once, some way to figure out when they have done so and can receive
> ecapsulated messages.
I feel like moderators are somewhat beholden to keeping their software
relatively current to be able to do their function as a moderator.
I also feel like there is room to do this on a per-moderated-newsgroup
basis.
I don't see the need for a Usenet wide flag day.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20230312/4f77ed12/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 148, Issue 4
*******************************************
