Re: Spam, bounces and gcc list removal
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
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 ? 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
* 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
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
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
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 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
Hello Maciej, On Sat, Mar 21, 2020 at 09:22:31PM +, 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
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
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
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
On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc 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
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