Re: Spam, bounces and gcc list removal

[Winfried Magerl]

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

[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

[Thomas Koenig via Gcc]

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

Successful bootstrap and test for GCC9.3.0 on Darwin platforms.

[Iain Sandoe]

General notes:

* GCC on Darwin depends on the installed “binutils”, typically provided by a 
version of “Xcode" or “Xcode command line tools”.  Unless noted otherwise, the 
bootstrap sequences here make use of the last available xcode command line 
tools and SDK for the platform version.

* Apple gcc-4.2.1 will no longer bootstrap GCC9+, the built stage1 compiler 
fails self-test with memory management errors,  given that earlier GCC versions 
produce sucessful bootstraps on other platforms, I’m not pursuing fixes to the 
gcc.4.2.1 sources.

* Two bootstrap and test sequences (where possible);
1) Using a version of GCC+Ada as the bootstrap compiler, allowing a build and 
test for Ada.
2) For Darwin11+, using the Apple clang that relates to the installed command 
line tools.

* In some cases, particularly with the earlier versions, the installed ‘atos’ 
is not really compatible with the versions of libsanitizer that are built with 
GCC8.  In that case, it’s usually better to install a version of 
llvm-symbolizer and set the ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer.

* I don’t have enough physical hardware to cover all of the versions directly, 
so some are (macOS hosted) VMs using VirtualBox.  In these cases, timeouts are 
not necessarily significant (noted in the relevant results).

cheers
Iain

---

Darwin19, (macOS 10.15)
xcode 11.4b3 command line tools and SDK was current

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556983.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556984.html

Darwin18 (10.14)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556981.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556982.html

Darwin17 (10.13)

here I have used XC 9.4, to avoid the errors caused by the deprecation of m32 
flagged by later tools.
(32b multilib still works fine here)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556979.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556980.html

Darwin16

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556977.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556978.html

Darwin15

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556975.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556976.html

Darwin14
(VM)
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556973.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556974.html

Darwin13
(VM)
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556971.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556972.html

Darwin12
(VM)
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556969.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556970.html

Darwin11
(VM)
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556967.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556968.html

Darwin10 (X86_64)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556966.html

Darwin10 (i686)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556964.html

Darwin9 (i686)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556961.html

Darwin9 (powerpc64)

powercp64-darwin9 will not bootstrap with the system ld64 (the binary size now 
exceeds the [buggy] branch island limit in that tool).  It is possible to make 
the bootstrap with an updated ld64 with that limit fixed, and using -Os for the 
stage1 compiler options.  There are several public branches with fixed ld64 
versions available - I used a version of https://github.com/iains/darwin-xtools

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556963.html

Darwin9 (powerpc)

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556962.html

Darwin8 (i686, powerpc)

Darwin8 cannot be built with the last release of XCode for the system (2.5)

At least ld64-85.2.1 is needed.
the results here were obtained with the cctools/ld64 sources from the xcode 
3.1.4 source release.

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556959.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556960.html

+ two small patches:
(1) for libstdc++

diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index 155a3cdea1b..d16d9519e43 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -240,11 +240,6 @@ case "${host_os}" in
  darwin8 | darwin8.* )
# For 8+ compatibility is better if not -flat_namespace.
OPT_LDFLAGS="${OPT_LDFLAGS} -Wl,-single_module"
-case "${host_cpu}" in
-  i[34567]86 | x86_64)
-OPTIMIZE_CXXFLAGS="${OPTIMIZE_CXXFLAGS} -fvisibility-inlines-hidden"
-;;
-esac
os_include_dir="os/bsd/darwin"
;;
  darwin*)


(2) for Ada

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 41434655865..74f843f2907 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -2351,7 +2351,10 @@ __gnat_number_of_cpus (void)
#if defined (__linux__) || defined (__sun__) || defined (_AIX) \
  |

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

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

gcc-10-20200322 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20200322 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20200322/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 83aa5aa313af9463c6962c72f7c238f914677824

You'll find:

 gcc-10-20200322.tar.xz   Complete GCC

  SHA256=945b175238ffdace82bbce03bbd55f67919fc591a7747f51d8869a714abc437b
  SHA1=bfe49065853b600d00f7cd06f967dcd41a8fc971

Diffs from 10-20200315 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Su factura - A8QS9

[Facturación Electrónica - Disponible -020]

Descargar el Comprobante 
Fiscal

Envio de Comprobante Fiscal Digital - MiTelcel

FOLIO: P56X287829R3ROJGMLY1CMNKP
FECHA DE EMISION:   22/03/2020
MONTO TOTAL:1.917,46



MiTelcel  (PLI830517184)

B3270L6L8FNKCO2VO46E