Spam, bounces and gcc list removal

Spam, bounces and gcc list removal

[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).

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

Re: Spam, bounces and gcc list removal

[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

> 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

Re: Spam, bounces and gcc list removal

[H.J. Lu]

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.

Re: Spam, bounces and gcc list removal

[Oleg Endo]

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

Re: Spam, bounces and gcc list removal

[Frank Ch. Eigler]

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

Re: Spam, bounces and gcc list removal

[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 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

Re: Spam, bounces and gcc list removal

[Winfried Magerl]

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

Re: Spam, bounces and gcc list removal

[Maciej W. Rozycki]

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

Re: Spam, bounces and gcc list removal

[Florian Weimer]

* 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.

Re: Spam, bounces and gcc list removal

[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?

 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

Re: Spam, bounces and gcc list removal

[Florian Weimer]

* 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.

Re: Spam, bounces and gcc list removal

[Maciej W. Rozycki]

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

Re: Spam, bounces and gcc list removal

[Thomas Koenig]

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