* Spam, bounces and gcc list removal
@ 2020-03-15 12:24 Thomas Koenig
2020-03-21 19:39 ` Thomas Koenig
0 siblings, 1 reply; 13+ messages in thread
From: Thomas Koenig @ 2020-03-15 12:24 UTC (permalink / raw)
To: gcc mailing list, overseers
Hi,
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list unless I
confirmed it (which I then did).
So, a request: Could the overseers either install more effective
spam protection for the list as a whole (preferred) or relax the
limit on bounces?
Regards
Thomas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-15 12:24 Spam, bounces and gcc list removal Thomas Koenig
@ 2020-03-21 19:39 ` Thomas Koenig
2020-03-21 20:08 ` H.J. Lu
2020-03-21 20:29 ` Frank Ch. Eigler
0 siblings, 2 replies; 13+ messages in thread
From: Thomas Koenig @ 2020-03-21 19:39 UTC (permalink / raw)
To: gcc mailing list, overseers
Hi,
> since the change to the new list management, there has been
> an uptick of spam getting through. Spam is bounced by my ISP,
> and this just resulted in a warning that there were too many
> bounces and that I would get removed from the list unless I
> confirmed it (which I then did).
This has now happened a second time, and this question
> So, a request: Could the overseers either install more effective
> spam protection for the list as a whole (preferred) or relax the
> limit on bounces?
is still valid.
Some kind of reaction would be appreciated.
Regards
Thomas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 19:39 ` Thomas Koenig
@ 2020-03-21 20:08 ` H.J. Lu
2020-03-22 2:39 ` Oleg Endo
2020-03-21 20:29 ` Frank Ch. Eigler
1 sibling, 1 reply; 13+ messages in thread
From: H.J. Lu @ 2020-03-21 20:08 UTC (permalink / raw)
To: Thomas Koenig; +Cc: gcc mailing list, overseers
On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> > since the change to the new list management, there has been
> > an uptick of spam getting through. Spam is bounced by my ISP,
> > and this just resulted in a warning that there were too many
> > bounces and that I would get removed from the list unless I
> > confirmed it (which I then did).
> This has now happened a second time, and this question
Same here.
> > So, a request: Could the overseers either install more effective
> > spam protection for the list as a whole (preferred) or relax the
> > limit on bounces?
>
> is still valid.
>
> Some kind of reaction would be appreciated.
>
> Regards
>
> Thomas
>
>
--
H.J.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 19:39 ` Thomas Koenig
2020-03-21 20:08 ` H.J. Lu
@ 2020-03-21 20:29 ` Frank Ch. Eigler
2020-03-21 21:22 ` Maciej W. Rozycki
2020-03-22 9:54 ` Thomas Koenig
1 sibling, 2 replies; 13+ messages in thread
From: Frank Ch. Eigler @ 2020-03-21 20:29 UTC (permalink / raw)
To: Overseers mailing list; +Cc: gcc mailing list, overseers, Thomas Koenig
Hi -
> > since the change to the new list management, there has been
> > an uptick of spam getting through. Spam is bounced by my ISP,
> > and this just resulted in a warning that there were too many
> > bounces and that I would get removed from the list unless I
> > confirmed it (which I then did).
> This has now happened a second time, and this question
For my reference, could you forward one of these spams & bounces to me?
> > So, a request: Could the overseers either install more effective
> > spam protection for the list as a whole (preferred)
Heh, if only it were that easy! Spam filtering was and is distinct
from mailing list processing, and as you know it's a constant arms
race. We're working hard to make the new installation of spamassassin
as discriminating as possible. We're also working on the workflow to
clean the web archives of spam that got through.
> > or relax the limit on bounces?
OK, there are a couple of settings over at:
https://gcc.gnu.org/mailman/admin/gcc/bounce
that law and we can think about, but I'd like
to see the messages in question to figure out what happened.
- FChE
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 20:29 ` Frank Ch. Eigler
@ 2020-03-21 21:22 ` Maciej W. Rozycki
2020-03-22 8:01 ` Winfried Magerl
2020-03-22 9:05 ` Florian Weimer
2020-03-22 9:54 ` Thomas Koenig
1 sibling, 2 replies; 13+ messages in thread
From: Maciej W. Rozycki @ 2020-03-21 21:22 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Overseers mailing list, overseers, gcc mailing list, Thomas Koenig
On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > So, a request: Could the overseers either install more effective
> > > spam protection for the list as a whole (preferred)
>
> Heh, if only it were that easy! Spam filtering was and is distinct
> from mailing list processing, and as you know it's a constant arms
> race. We're working hard to make the new installation of spamassassin
> as discriminating as possible. We're also working on the workflow to
> clean the web archives of spam that got through.
Spam bouncing is evil and often hits an innocent person whose address has
been faked by the sender of spam, making the source of bounces not better
than the originator. I have been hit myself like that in the past when
someone chose to use my address; fortunately I only received a mere 1000
of bounces or so. If caught and chosen not to be quarantined or stored in
a spambox, spam is best silently dropped on the floor aka /dev/null.
I would certainly recommend anyone making use of services provided by an
ISP who bounces spam to contact their e-mail system administrator and
enquire as to why they chose to do so. At worst I would change the ISP
for their bad practices, and I think the decision to unsubscribe people
whose ISP chose to bounce spam received through the mailing list is a
reasonable one.
Maciej
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 20:08 ` H.J. Lu
@ 2020-03-22 2:39 ` Oleg Endo
0 siblings, 0 replies; 13+ messages in thread
From: Oleg Endo @ 2020-03-22 2:39 UTC (permalink / raw)
To: H.J. Lu, Thomas Koenig; +Cc: overseers, gcc mailing list
On Sat, 2020-03-21 at 13:08 -0700, H.J. Lu via Gcc wrote:
> On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc <
> gcc@gcc.gnu.org> wrote:
> >
> > Hi,
> >
> > > since the change to the new list management, there has been
> > > an uptick of spam getting through. Spam is bounced by my ISP,
> > > and this just resulted in a warning that there were too many
> > > bounces and that I would get removed from the list unless I
> > > confirmed it (which I then did).
> >
> > This has now happened a second time, and this question
>
> Same here.
>
Same here.
Cheers,
Oleg
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 21:22 ` Maciej W. Rozycki
@ 2020-03-22 8:01 ` Winfried Magerl
2020-03-22 16:35 ` Maciej W. Rozycki
2020-03-22 9:05 ` Florian Weimer
1 sibling, 1 reply; 13+ messages in thread
From: Winfried Magerl @ 2020-03-22 8:01 UTC (permalink / raw)
To: gcc; +Cc: overseers
Hello Maciej,
On Sat, Mar 21, 2020 at 09:22:31PM +0000, Maciej W. Rozycki wrote:
[......]
> Spam bouncing is evil and often hits an innocent person
[......]
others like me might see it different:
Spam discarding is evil and often hits an innocent person.
Silently discarding a legal mail because of false spam-detection is
the worst case for the sender. But this is OffTopic.
regards
winfried
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 21:22 ` Maciej W. Rozycki
2020-03-22 8:01 ` Winfried Magerl
@ 2020-03-22 9:05 ` Florian Weimer
2020-03-22 13:24 ` Maciej W. Rozycki
1 sibling, 1 reply; 13+ messages in thread
From: Florian Weimer @ 2020-03-22 9:05 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Frank Ch. Eigler, overseers, gcc mailing list,
Overseers mailing list, Thomas Koenig
* Maciej W. Rozycki:
> On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote:
>
>> > > So, a request: Could the overseers either install more effective
>> > > spam protection for the list as a whole (preferred)
>>
>> Heh, if only it were that easy! Spam filtering was and is distinct
>> from mailing list processing, and as you know it's a constant arms
>> race. We're working hard to make the new installation of spamassassin
>> as discriminating as possible. We're also working on the workflow to
>> clean the web archives of spam that got through.
>
> Spam bouncing is evil and often hits an innocent person whose address has
> been faked by the sender of spam, making the source of bounces not better
> than the originator.
I expect this to be an SMTP-level rejection, not a bounce. sourceware
generates a bounce from that, and Mailman reacts to that. But the
target mail server does not generate a bounce. So your concern about
bad ISP behavior does not apply here.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-21 20:29 ` Frank Ch. Eigler
2020-03-21 21:22 ` Maciej W. Rozycki
@ 2020-03-22 9:54 ` Thomas Koenig
1 sibling, 0 replies; 13+ messages in thread
From: Thomas Koenig @ 2020-03-22 9:54 UTC (permalink / raw)
To: Frank Ch. Eigler, Overseers mailing list; +Cc: overseers, gcc mailing list
Am 21.03.20 um 21:29 schrieb Frank Ch. Eigler via Gcc:
> Hi -
>
>>> since the change to the new list management, there has been
>>> an uptick of spam getting through. Spam is bounced by my ISP,
>>> and this just resulted in a warning that there were too many
>>> bounces and that I would get removed from the list unless I
>>> confirmed it (which I then did).
>> This has now happened a second time, and this question
>
> For my reference, could you forward one of these spams & bounces to me?
I never got to see them, because they never made it past my ISP.
>>> So, a request: Could the overseers either install more effective
>>> spam protection for the list as a whole (preferred)
>
> Heh, if only it were that easy! Spam filtering was and is distinct
> from mailing list processing, and as you know it's a constant arms
> race. We're working hard to make the new installation of spamassassin
> as discriminating as possible. We're also working on the workflow to
> clean the web archives of spam that got through.
That makes it even less likely that I will be able to provide you with
a sample, unfortunately.
Maybe it would be better just to look at the logfiles? You will
probably see a
550 5.7.1 Refused by local policy. No SPAM please!
or similar there.
>>> or relax the limit on bounces?
>
> OK, there are a couple of settings over at:
> https://gcc.gnu.org/mailman/admin/gcc/bounce
> that law and we can think about, but I'd like
> to see the messages in question to figure out what happened.
Maybe it is possible to do it like the old mail system did:
If there were too many bounces, it sent a probe, if that didn't
bounce, nothing more happened.
That worked OK, the current system does not.
Regards
Thomas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-22 9:05 ` Florian Weimer
@ 2020-03-22 13:24 ` Maciej W. Rozycki
2020-03-22 13:29 ` Florian Weimer
0 siblings, 1 reply; 13+ messages in thread
From: Maciej W. Rozycki @ 2020-03-22 13:24 UTC (permalink / raw)
To: Florian Weimer
Cc: Frank Ch. Eigler, overseers, gcc mailing list,
Overseers mailing list, Thomas Koenig
On Sun, 22 Mar 2020, Florian Weimer wrote:
> > Spam bouncing is evil and often hits an innocent person whose address has
> > been faked by the sender of spam, making the source of bounces not better
> > than the originator.
>
> I expect this to be an SMTP-level rejection, not a bounce. sourceware
> generates a bounce from that, and Mailman reacts to that. But the
> target mail server does not generate a bounce. So your concern about
> bad ISP behavior does not apply here.
You mean as with a failure response given to the SMTP DATA command?
This is actually equally evil as the resulting bounce (i.e. a delivery
failure notification, or a flood of them, once other MTAs have joined in a
response to a mass mailing; that is exactly what I suffered from a few
years ago) will hit whoever's fake envelope sender address has been given
with the MAIL FROM command. You don't expect a real one with spam, do
you?
As I say, just silently drop it on the floor, this is the least harmful
way of dealing with spam. And sometimes indirectly blocking a specific
e-mail address chosen to look like a source of spam *will be* the actual
objective of what looks like usual spam.
Maciej
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-22 13:24 ` Maciej W. Rozycki
@ 2020-03-22 13:29 ` Florian Weimer
2020-03-22 16:13 ` Maciej W. Rozycki
0 siblings, 1 reply; 13+ messages in thread
From: Florian Weimer @ 2020-03-22 13:29 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Frank Ch. Eigler, overseers, gcc mailing list,
Overseers mailing list, Thomas Koenig
* Maciej W. Rozycki:
> On Sun, 22 Mar 2020, Florian Weimer wrote:
>
>> > Spam bouncing is evil and often hits an innocent person whose address has
>> > been faked by the sender of spam, making the source of bounces not better
>> > than the originator.
>>
>> I expect this to be an SMTP-level rejection, not a bounce. sourceware
>> generates a bounce from that, and Mailman reacts to that. But the
>> target mail server does not generate a bounce. So your concern about
>> bad ISP behavior does not apply here.
>
> You mean as with a failure response given to the SMTP DATA command?
> This is actually equally evil as the resulting bounce (i.e. a delivery
> failure notification, or a flood of them, once other MTAs have joined in a
> response to a mass mailing; that is exactly what I suffered from a few
> years ago) will hit whoever's fake envelope sender address has been given
> with the MAIL FROM command. You don't expect a real one with spam, do
> you?
No, this is not what happens (unless an open SMTP relay is involved,
which is a different kind of problem).
The error result from the DATA command is either observed directly by
the spamming software (which does not generate a bounce message), or
by some mail relay at an ISP. These relays check the envelope sender
address before accepting a message for relaying, so if they need to
generate a bounce, it will not be sent to an unrelated party.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-22 13:29 ` Florian Weimer
@ 2020-03-22 16:13 ` Maciej W. Rozycki
0 siblings, 0 replies; 13+ messages in thread
From: Maciej W. Rozycki @ 2020-03-22 16:13 UTC (permalink / raw)
To: Florian Weimer
Cc: Frank Ch. Eigler, overseers, gcc mailing list,
Overseers mailing list, Thomas Koenig
On Sun, 22 Mar 2020, Florian Weimer wrote:
> > You mean as with a failure response given to the SMTP DATA command?
> > This is actually equally evil as the resulting bounce (i.e. a delivery
> > failure notification, or a flood of them, once other MTAs have joined in a
> > response to a mass mailing; that is exactly what I suffered from a few
> > years ago) will hit whoever's fake envelope sender address has been given
> > with the MAIL FROM command. You don't expect a real one with spam, do
> > you?
>
> No, this is not what happens (unless an open SMTP relay is involved,
> which is a different kind of problem).
>
> The error result from the DATA command is either observed directly by
> the spamming software (which does not generate a bounce message), or
> by some mail relay at an ISP. These relays check the envelope sender
> address before accepting a message for relaying, so if they need to
> generate a bounce, it will not be sent to an unrelated party.
What's the problem setting an own relay (or relay network) that accepts
and/or cooks up anything and then sends stuff to various places according
to the recipients given including say <gcc@gcc.gnu.org>? The ultimate
recipient's MTA is then far down the chain and its reject won't ever reach
the original actual sender's MTA. However it will hurt other people.
Maybe some spammers are so naïve as to (still) send directly, but the
"industry" has now had decades to learn and evolve.
Maciej
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Spam, bounces and gcc list removal
2020-03-22 8:01 ` Winfried Magerl
@ 2020-03-22 16:35 ` Maciej W. Rozycki
0 siblings, 0 replies; 13+ messages in thread
From: Maciej W. Rozycki @ 2020-03-22 16:35 UTC (permalink / raw)
To: Winfried Magerl; +Cc: gcc, overseers
Hi Winfried,
> [......]
> > Spam bouncing is evil and often hits an innocent person
> [......]
>
> others like me might see it different:
> Spam discarding is evil and often hits an innocent person.
>
> Silently discarding a legal mail because of false spam-detection is
> the worst case for the sender. But this is OffTopic.
Freedom of speech includes the right not to listen, so it's none of
anyone's business if a recipient of any e-mail decides to silently discard
any incoming messages based on any criteria. If an ISP does that against
a customer's will, then that's a matter between the ISP and the customer
(I'd change the ISP right away if it applied to me and it weren't by
mistake).
Whereas deliberately forwarding spam received to a third party is never
right and may even be illegal in certain jurisdictions.
Maciej
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-03-22 16:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-15 12:24 Spam, bounces and gcc list removal Thomas Koenig
2020-03-21 19:39 ` Thomas Koenig
2020-03-21 20:08 ` H.J. Lu
2020-03-22 2:39 ` Oleg Endo
2020-03-21 20:29 ` Frank Ch. Eigler
2020-03-21 21:22 ` Maciej W. Rozycki
2020-03-22 8:01 ` Winfried Magerl
2020-03-22 16:35 ` Maciej W. Rozycki
2020-03-22 9:05 ` Florian Weimer
2020-03-22 13:24 ` Maciej W. Rozycki
2020-03-22 13:29 ` Florian Weimer
2020-03-22 16:13 ` Maciej W. Rozycki
2020-03-22 9:54 ` Thomas Koenig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).