Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

Hi Leo,

> how are they forwarding the message

It's essentially taking raw message from Gmail (click on "Show original",
then copy everything), and then it's trivial to pass that on to Gmail's
SMTP servers, you can do that with telnet :)
telnet gmail-smtp-in.l.google.com 25
EHLO whatever.like.really
MAIL FROM:
RCPT TO:
paste your raw message here
.
.

Profit!

> what are they using?  Maybe that can be a vector to stop them.

They are using spam networks from which no one else would accept
connections, much less mail. Trashy hosting companies, IP ranges listed in
SBL, even DROP lists.
Don't bother sending abuse reports to them.



[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Sat, Mar 5, 2022 at 3:53 AM  wrote:

> Hi Edgaras,
>
> Our gmails have been getting spammed by this person, what i cant wrap my
> head around is; Once the send the email from esp to their gmail, how are
> they forwarding the message or what are they using?  Maybe that can be a
> vector to stop them.
>
> thanks
> > 3. The email is signed with getresponse-mail.com
> > , a domain with a good reputation at Gmail.
> > 4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
> > against the reputation of getresponse-mail.com <
> http://getresponse-mail.com>
> > 5. Mails are delivered to countless Gmail users
>
>
>
>
>
> Edgaras | SENDER via mailop  wrote ..
> > > This message was correctly marked as spam.
> >
> > This one was, but there are cases when they go to Primary tab. Sometimes
> > they are moved to junk after delivery.
> >
> > > The DKIM reputation is taking a hit due to the spamming, but that is an
> > accurate assessment on our part, as it is being used for sending spam.
> > They wouldn't be used for that, if you guys would simply reject mail from
> > IPs with no rDNS, or those in SPF -all. Right now it's a huge hole.
> >
> > > A quick glance at some IPs and the Networks from the SBL addresses you
> > listed show very low reputation and lots of blocked messages.
> > I don't know how your filters work on the inside, but it could be a very
> > good signal to detect attacks like this one.
> >
> > > I assume the fact that dkim replay attack spam messages are winding up
> in
> > the spam labels of our users isn't the actual issue that concerns you.
> > No, that is not the problem. Problem is accepting mail from extremely
> shady
> > sources and counting that mail as legitimately sent on the victim
> domain's
> > behalf.
> >
> >
> > [image: Sender] Edgar Vaitkevičius, founder / CEO
> > ed...@sender.net
> >
> >
> >
> >
> > On Wed, Mar 2, 2022 at 9:08 PM Brandon Long  wrote:
> >
> > > This message was correctly marked as spam.
> > >
> > > Generally speaking, it looks like our systems are correctly determining
> > > which of these is spam and which is not.  The DKIM reputation is
> taking a
> > > hit due to the spamming, but that is an accurate assessment on our
> part, as
> > > it is being used for sending spam.  The SPF reputation of the domain is
> > > doing better, as are the IP addresses you listed in the SPF record,
> perhaps
> > > that is visible to you on the postmaster page.  A quick glance at some
> IPs
> > > and the Networks from the SBL addresses you listed show very low
> reputation
> > > and lots of blocked messages.
> > >
> > > I assume the fact that dkim replay attack spam messages are winding up
> in
> > > the spam labels of our users isn't the actual issue that concerns you.
> > >
> > > Brandon
> > >
> > > On Wed, Mar 2, 2022 at 10:38 AM Edgaras | SENDER via mailop <
> > > mailop@mailop.org> wrote:
> > >
> > >> > Add just the headers from a single abuse email here on the thread..
> > >> Here you go, latest victim (Wix) abused by
> azeddinebenlarbi...@gmail.com:
> > >>
> > >> Delivered-To: trappy.mctrapf...@gmail.com
> > >> Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
> > >> Wed, 2 Mar 2022 09:00:00 -0800 (PST)
> > >> X-Google-Smtp-Source:
> > >>
> ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
> > >> X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id
> > >> m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;
> > >> Wed, 02 Mar 2022 09:00:00 -0800 (PST)
> > >> ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
> > >> d=google.com; s=arc-20160816;
> > >>
> > >> b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC
> > >>
> > >>  rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr
> > >>
> > >>  McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb
> > >>
> > >>  42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz
> > >>
> > >>  +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za
> > >>  fhKQ==
> > >> ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
> google.com;
> > >> s=arc-20160816;
> > >>
>  

Re: [mailop] [E] What the f**k, Google?

[Brandon Long via mailop]

This message was correctly marked as spam.

Generally speaking, it looks like our systems are correctly determining
which of these is spam and which is not.  The DKIM reputation is taking a
hit due to the spamming, but that is an accurate assessment on our part, as
it is being used for sending spam.  The SPF reputation of the domain is
doing better, as are the IP addresses you listed in the SPF record, perhaps
that is visible to you on the postmaster page.  A quick glance at some IPs
and the Networks from the SBL addresses you listed show very low reputation
and lots of blocked messages.

I assume the fact that dkim replay attack spam messages are winding up in
the spam labels of our users isn't the actual issue that concerns you.

Brandon

On Wed, Mar 2, 2022 at 10:38 AM Edgaras | SENDER via mailop <
mailop@mailop.org> wrote:

> > Add just the headers from a single abuse email here on the thread..
> Here you go, latest victim (Wix) abused by azeddinebenlarbi...@gmail.com:
>
> Delivered-To: trappy.mctrapf...@gmail.com
> Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
> Wed, 2 Mar 2022 09:00:00 -0800 (PST)
> X-Google-Smtp-Source:
> ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
> X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id
> m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;
> Wed, 02 Mar 2022 09:00:00 -0800 (PST)
> ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
> d=google.com; s=arc-20160816;
>
> b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC
>
>  rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr
>
>  McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb
>
>  42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz
>
>  +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za
>  fhKQ==
> ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
> s=arc-20160816;
> h=to:feedback-id:reply-to:subject:subject:message-id:message-id
>  :mime-version:from:date:dkim-signature:dkim-signature;
> bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
>
> b=L2r7W1Ax8bOAZ/mPCFbyQiXSepDAqF4Z3BDl11dszqt3si4yReg9zYoIqc7wGFOXBV
>
>  QuKBtFWs3FTE9fGqBFEwgaDiObCUWdVL08BMI7Uw9EZPL8ej3Mhk5oipUMi3gcSpDbgz
>
>  uK6UChfO33wOx8uXoiDVZ8QmBoUEPiBvH/NLVYPHVdcVw9sIDS4/Rv/i+DCuAou2KQua
>
>  emuPHs4W0SDrKRCYpOfYTilzse9RWiTgoCTjTL3whe/uZuWwYgeljZF682+Np+i7+OoZ
>
>  YhyyHOijqWNwDR3dLPMXOpg7/u01xguZsjgTFoBMXYvPKWn3V/AXPoVjqC67CJ81vatf
>  Jlhw==
> ARC-Authentication-Results: i=2; mx.google.com;
>dkim=pass header.i=@test.ascendbywix.com header.s=s1
> header.b=P9JGN5Pt;
>dkim=pass header.i=@sendgrid.info header.s=smtpapi
> header.b="PzohlIQ/";
>arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com dkim=pass
> dkdomain=test.ascendbywix.com dkim=pass dkdomain=sendgrid.info dmarc=pass
> fromdomain=test.ascendbywix.com);
>spf=fail (google.com: domain of
> bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
> does not designate 81.7.6.53 as permitted sender)
> smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=
> gmail@sg.test.ascendbywix.com";
>dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=
> test.ascendbywix.com
> Return-Path:  gmail@sg.test.ascendbywix.com>
> Received: from takataka.gr ([81.7.6.53])
> by mx.google.com with ESMTP id
> r1-20020a1709061ba100b006d07f388e25si10294892ejg.908.2022.03.02.09.00.00
> for ;
> Wed, 02 Mar 2022 09:00:00 -0800 (PST)
> Received-SPF: fail (google.com: domain of
> bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
> does not designate 81.7.6.53 as permitted sender) client-ip=81.7.6.53;
> Authentication-Results: mx.google.com;
>dkim=pass header.i=@test.ascendbywix.com header.s=s1
> header.b=P9JGN5Pt;
>dkim=pass header.i=@sendgrid.info header.s=smtpapi
> header.b="PzohlIQ/";
>arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com dkim=pass
> dkdomain=test.ascendbywix.com dkim=pass dkdomain=sendgrid.info dmarc=pass
> fromdomain=test.ascendbywix.com);
>spf=fail (google.com: domain of
> bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
> does not designate 81.7.6.53 as permitted sender)
> smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=
> gmail@sg.test.ascendbywix.com";
>dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=
> test.ascendbywix.com
> Received: by 2002:a4a:390e:0:0:0:0:0 with SMTP id m14csp2497925ooa;
> Tue, 1 Mar 2022 01:20:28 -0800 (PST)
> X-Received: by 2002:a25:b3c7:0:b0:623:e9fe:e108 with SMTP id
> x7-20020a25b3c700b00623e9fee108mr24017231ybf.335.1646126428656;
> Tue, 01 Mar 2022 01:20:28 -0800 (PST)
> ARC-Seal: i=1; a=rsa-sha256; t=1646126428; cv=none;
> d=google.com; s=arc-20160816;
>
> 

Re: [mailop] [E] What the f**k, Google?

[Brandon Long via mailop]

On Wed, Mar 2, 2022 at 12:07 PM Edgaras | SENDER  wrote:

> > I think you are misunderstanding what the dkim reputation means, that it
> is some sort of value judgement for the company or people who own the
> domain.
> No, I understand that it's just one of the signals you use, but it is a
> very significant one. It wouldn't be a problem if it did not have a large
> impact on message delivery.
>
> > If 90% of the messages we see with that DKIM domain are spam, then the
> reputation should trend to 10%.
> Correct. Problem here is disregarding a ton of basic checks, allowing
> attackers to fairly easily deploy such amounts of spam, that even a domain
> with large amounts of legitimate mail will get it's reputation wrecked.
>

We seem to not be understanding each other.


The reputations are:

for feature in message.features:
  reputation.Vote(feature, message.is_spam)

Not:

for feature in message.features:
  if not message.is_really_really_really_spammy:
reputation.Vote(feature, message.is_spam)

And yes, as signals become murkier, it's harder to know what is spam and
what is not, our false positive/false negative rates will go up, and we
work to improve them.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Brandon Long via mailop]

On Wed, Mar 2, 2022 at 10:51 AM Edgaras | SENDER via mailop <
mailop@mailop.org> wrote:

> > It does seem like Google could notice "old" date headers and BCCs and
> the fact the mail is coming from a dedicated spam factory and maybe treat
> it a little differently, though.
>
> My point exactly. They could maybe notice it's hard failing SPF, or rDNS,
> or just about every requirement they have published.
>

We do notice all of those things, and we do use that to determine which are
spam and which are not with some level of accuracy.

It seems like you want us to block all of these messages at smtp time.  We
do block a lot, but not all.  Partially, we don't block them all so that
there is some chance
for false positives to make it to the spam label where they can be marked
not spam.

And yes, we know that scams getting to the spam label have some potential
for harm, and we do try to limit that in multiple ways... and of course,
generally speaking the spam label is much more expensive to us than
blocking at smtp time, so keeping the size of the spam label is a goal.  We
know that spammers send billions of messages just to get some into the spam
label.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> I think you are misunderstanding what the dkim reputation means, that it
is some sort of value judgement for the company or people who own the
domain.
No, I understand that it's just one of the signals you use, but it is a
very significant one. It wouldn't be a problem if it did not have a large
impact on message delivery.

> If 90% of the messages we see with that DKIM domain are spam, then the
reputation should trend to 10%.
Correct. Problem here is disregarding a ton of basic checks, allowing
attackers to fairly easily deploy such amounts of spam, that even a domain
with large amounts of legitimate mail will get it's reputation wrecked.

> You want us to have 100% rules like rejecting -all messages.  We don't do
100% rules, certainly not for any long term basis.  We mostly ignore -all,
that's come up on this
> list multiple times, it's generally the wrong choice.  People forward
messages, they aren't all DKIM replays.
I don't expect simplistic measures like that from companies like Google.
But you can definitely do A LOT better to detect attacks like this,
especially now that they are drastically increasing in volume, as more and
more spammers are "discovering" this. People do forward messages, but they
are not adding fake Subject: lines on forwarded mail, and legitimate users
follow your own mail guidelines to some degree.



[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 9:47 PM Brandon Long  wrote:

>
>
> On Wed, Mar 2, 2022 at 11:22 AM Edgaras | SENDER 
> wrote:
>
>> > This message was correctly marked as spam.
>>
>> This one was, but there are cases when they go to Primary tab. Sometimes
>> they are moved to junk after delivery.
>>
>> > The DKIM reputation is taking a hit due to the spamming, but that is an
>> accurate assessment on our part, as it is being used for sending spam.
>> They wouldn't be used for that, if you guys would simply reject mail from
>> IPs with no rDNS, or those in SPF -all. Right now it's a huge hole.
>>
>> > A quick glance at some IPs and the Networks from the SBL addresses you
>> listed show very low reputation and lots of blocked messages.
>> I don't know how your filters work on the inside, but it could be a very
>> good signal to detect attacks like this one.
>>
>> > I assume the fact that dkim replay attack spam messages are winding up
>> in the spam labels of our users isn't the actual issue that concerns you.
>> No, that is not the problem. Problem is accepting mail from extremely
>> shady sources and counting that mail as legitimately sent on the victim
>> domain's behalf.
>>
>
> I think you are misunderstanding what the dkim reputation means, that it
> is some sort of value judgement for the company or people who own the
> domain.
>
> What the reputation means is an approximation of the likelihood of a
> message with that feature is spam or not.  If 90% of the messages we see
> with that DKIM domain
> are spam, then the reputation should trend to 10%.  We have plenty of
> other reputation features we apply to the messages as well, such as the IP,
> netblock, ASN, SPF domain
> and dozens more.
>
> Prior to DKIM replay attacks, the DKIM domain reputation was a good proxy
> for spam source control.  Now, it is not.  It isn't quite as bad as
> "Advertised domain" (ie, domains in the body of the message), where we've
> seen very common domains drop to very low reputation (linkedin.com,
> imgur.com, bit.ly etc come to mind as many year old issues).  SPF and IP
> reputation have always been better proxies for spam source control.
>
> You want us to have 100% rules like rejecting -all messages.  We don't do
> 100% rules, certainly not for any long term basis.  We mostly ignore -all,
> that's come up on this list multiple times, it's generally the wrong
> choice.  People forward messages, they aren't all DKIM replays.
>
> Brandon
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Brandon Long via mailop]

On Wed, Mar 2, 2022 at 11:22 AM Edgaras | SENDER  wrote:

> > This message was correctly marked as spam.
>
> This one was, but there are cases when they go to Primary tab. Sometimes
> they are moved to junk after delivery.
>
> > The DKIM reputation is taking a hit due to the spamming, but that is an
> accurate assessment on our part, as it is being used for sending spam.
> They wouldn't be used for that, if you guys would simply reject mail from
> IPs with no rDNS, or those in SPF -all. Right now it's a huge hole.
>
> > A quick glance at some IPs and the Networks from the SBL addresses you
> listed show very low reputation and lots of blocked messages.
> I don't know how your filters work on the inside, but it could be a very
> good signal to detect attacks like this one.
>
> > I assume the fact that dkim replay attack spam messages are winding up
> in the spam labels of our users isn't the actual issue that concerns you.
> No, that is not the problem. Problem is accepting mail from extremely
> shady sources and counting that mail as legitimately sent on the victim
> domain's behalf.
>

I think you are misunderstanding what the dkim reputation means, that it is
some sort of value judgement for the company or people who own the domain.

What the reputation means is an approximation of the likelihood of a
message with that feature is spam or not.  If 90% of the messages we see
with that DKIM domain
are spam, then the reputation should trend to 10%.  We have plenty of other
reputation features we apply to the messages as well, such as the IP,
netblock, ASN, SPF domain
and dozens more.

Prior to DKIM replay attacks, the DKIM domain reputation was a good proxy
for spam source control.  Now, it is not.  It isn't quite as bad as
"Advertised domain" (ie, domains in the body of the message), where we've
seen very common domains drop to very low reputation (linkedin.com,
imgur.com, bit.ly etc come to mind as many year old issues).  SPF and IP
reputation have always been better proxies for spam source control.

You want us to have 100% rules like rejecting -all messages.  We don't do
100% rules, certainly not for any long term basis.  We mostly ignore -all,
that's come up on this list multiple times, it's generally the wrong
choice.  People forward messages, they aren't all DKIM replays.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> This will probably help Gmail understand the threat more, at the very
> least, if they haven't been watching for this already.
I hope that they will pay attention now that this is being exploited all
over the place. When I reported this a month ago, nothing happened.

> For all we know, when they parse this, they see the SPF pass, and don't
> check the later SPF fail, but given that they get a lot of forwarded
> email from banks etc, that their customers want, they probably have
> decided to allow this behavior.
Well, legitimate email forwarders are supposed to be properly configured
for that.

> You do have an argument that if you advertise a -all on the SPF record,
> you are expecting Gmail to reject it.
Exactly. That should be a strong signal that the message is not authorized
by the supposed sending domain.

> And of course, the IP itself. interesting that it is only on a couple of
> RBL's.. but Gmail should be able to note the volume of identical mail...
Spammers using these networks are probably focusing on exploiting Gmail
weakness and targeting their @gmail.com addresses specifically. That would
explain the lack of other RBL listings.

> But this should NOT affect the domain reputation IMHO, there may be
> other things that are affecting it.
Precisely!

> I would question why you choose to use a MAIL FROM, with a different
> domain than you use in the header from, eg
I think it's their VERP implementation.

[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 8:45 PM Michael Peddemors 
wrote:

> This will probably help Gmail understand the threat more, at the very
> least, if they haven't been watching for this already.
>
> For all we know, when they parse this, they see the SPF pass, and don't
> check the later SPF fail, but given that they get a lot of forwarded
> email from banks etc, that their customers want, they probably have
> decided to allow this behavior.
>
> (And even you probably want your forwarded email to get to the customer)
>
> There are some curious things, eg ordering and placement of their trace
> headers above the Return-Path, and I won't talk about that..
>
> You do have an argument that if you advertise a -all on the SPF record,
> you are expecting Gmail to reject it.
>
> Also, you have an argument that Gmail should be stripping (and/or
> questioning) the fast there is an existing Return-Path header, which
> should be suspicious/stripped.
>
> And of course, the IP itself. interesting that it is only on a couple of
> RBL's.. but Gmail should be able to note the volume of identical mail...
> or this obvious forged relay attempt, but at this point (and yeah, it is
> the same attack vector that has been reported here and in other places
> over the last couple months) we should leave it to the Gmail folks to
> comment on..
>
> But this should NOT affect the domain reputation IMHO, there may be
> other things that are affecting it.
>
> I would question why you choose to use a MAIL FROM, with a different
> domain than you use in the header from, eg
>
> Return-Path:
>  gmail@sg.test.ascendbywix.com>
>
> vs
>
> From: "" 
>
>
>
>
> On 2022-03-02 10:18 a.m., Edgaras | SENDER wrote:
> >  > Add just the headers from a single abuse email here on the thread..
> > Here you go, latest victim (Wix) abused by azeddinebenlarbi...@gmail.com
> > :
> >
> > Delivered-To: trappy.mctrapf...@gmail.com
> > 
> > Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
> >  Wed, 2 Mar 2022 09:00:00 -0800 (PST)
> > X-Google-Smtp-Source:
> >
> ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
> > X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id
> > m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;
> >  Wed, 02 Mar 2022 09:00:00 -0800 (PST)
> > ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
> >  d=google.com ; s=arc-20160816;
> >
> > b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC
> >
> >   rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr
> >
> >   McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb
> >
> >   42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz
> >
> >   +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za
> >   fhKQ==
> > ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
> > d=google.com ; s=arc-20160816;
> >  h=to:feedback-id:reply-to:subject:subject:message-id:message-id
> >   :mime-version:from:date:dkim-signature:dkim-signature;
> >  bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
> >
> > b=L2r7W1Ax8bOAZ/mPCFbyQiXSepDAqF4Z3BDl11dszqt3si4yReg9zYoIqc7wGFOXBV
> >
> >   QuKBtFWs3FTE9fGqBFEwgaDiObCUWdVL08BMI7Uw9EZPL8ej3Mhk5oipUMi3gcSpDbgz
> >
> >   

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> We do notice all of those things, and we do use that to determine which
are spam and which are not with some level of accuracy.
It seems the weights of these things on spam filtering have been changed
recently for the worse. I haven't seen these attacks in such volume before.

> It seems like you want us to block all of these messages at smtp time.
We do block a lot, but not all.  Partially, we don't block them all so that
there is some chance
for false positives to make it to the spam label where they can be marked
not spam.
That would be a logical thing to do in cases like I just reported,
where the IP is extremely bad, or rDNS is missing, or it's in -all.
Softfail cases should be treated like you described.

>  generally speaking the spam label is much more expensive to us than
blocking at smtp time, so keeping the size of the spam label is a goal
So here's a pretty low hanging fruit for your team. The samples I sent
should be easy to reject just on basic sane mail server requirements.

I still don't understand how a replayed message with
oversigned From,To,CC,Subject,Date headers could pass DKIM authentication
at Gmail. I don't have sample headers, but there are millions of messages
like that sent on Feb 28 from the spam IP ranges I mentioned in the initial
email.



[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 9:20 PM Brandon Long  wrote:

>
>
> On Wed, Mar 2, 2022 at 10:51 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>> > It does seem like Google could notice "old" date headers and BCCs and
>> the fact the mail is coming from a dedicated spam factory and maybe treat
>> it a little differently, though.
>>
>> My point exactly. They could maybe notice it's hard failing SPF, or rDNS,
>> or just about every requirement they have published.
>>
>
> We do notice all of those things, and we do use that to determine which
> are spam and which are not with some level of accuracy.
>
> It seems like you want us to block all of these messages at smtp time.  We
> do block a lot, but not all.  Partially, we don't block them all so that
> there is some chance
> for false positives to make it to the spam label where they can be marked
> not spam.
>
> And yes, we know that scams getting to the spam label have some potential
> for harm, and we do try to limit that in multiple ways... and of course,
> generally speaking the spam label is much more expensive to us than
> blocking at smtp time, so keeping the size of the spam label is a goal.  We
> know that spammers send billions of messages just to get some into the spam
> label.
>
> Brandon
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> This message was correctly marked as spam.

This one was, but there are cases when they go to Primary tab. Sometimes
they are moved to junk after delivery.

> The DKIM reputation is taking a hit due to the spamming, but that is an
accurate assessment on our part, as it is being used for sending spam.
They wouldn't be used for that, if you guys would simply reject mail from
IPs with no rDNS, or those in SPF -all. Right now it's a huge hole.

> A quick glance at some IPs and the Networks from the SBL addresses you
listed show very low reputation and lots of blocked messages.
I don't know how your filters work on the inside, but it could be a very
good signal to detect attacks like this one.

> I assume the fact that dkim replay attack spam messages are winding up in
the spam labels of our users isn't the actual issue that concerns you.
No, that is not the problem. Problem is accepting mail from extremely shady
sources and counting that mail as legitimately sent on the victim domain's
behalf.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 9:08 PM Brandon Long  wrote:

> This message was correctly marked as spam.
>
> Generally speaking, it looks like our systems are correctly determining
> which of these is spam and which is not.  The DKIM reputation is taking a
> hit due to the spamming, but that is an accurate assessment on our part, as
> it is being used for sending spam.  The SPF reputation of the domain is
> doing better, as are the IP addresses you listed in the SPF record, perhaps
> that is visible to you on the postmaster page.  A quick glance at some IPs
> and the Networks from the SBL addresses you listed show very low reputation
> and lots of blocked messages.
>
> I assume the fact that dkim replay attack spam messages are winding up in
> the spam labels of our users isn't the actual issue that concerns you.
>
> Brandon
>
> On Wed, Mar 2, 2022 at 10:38 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>> > Add just the headers from a single abuse email here on the thread..
>> Here you go, latest victim (Wix) abused by azeddinebenlarbi...@gmail.com:
>>
>> Delivered-To: trappy.mctrapf...@gmail.com
>> Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
>> Wed, 2 Mar 2022 09:00:00 -0800 (PST)
>> X-Google-Smtp-Source:
>> ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
>> X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id
>> m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;
>> Wed, 02 Mar 2022 09:00:00 -0800 (PST)
>> ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
>> d=google.com; s=arc-20160816;
>>
>> b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC
>>
>>  rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr
>>
>>  McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb
>>
>>  42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz
>>
>>  +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za
>>  fhKQ==
>> ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
>> s=arc-20160816;
>> h=to:feedback-id:reply-to:subject:subject:message-id:message-id
>>  :mime-version:from:date:dkim-signature:dkim-signature;
>> bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
>>
>> b=L2r7W1Ax8bOAZ/mPCFbyQiXSepDAqF4Z3BDl11dszqt3si4yReg9zYoIqc7wGFOXBV
>>
>>  QuKBtFWs3FTE9fGqBFEwgaDiObCUWdVL08BMI7Uw9EZPL8ej3Mhk5oipUMi3gcSpDbgz
>>
>>  uK6UChfO33wOx8uXoiDVZ8QmBoUEPiBvH/NLVYPHVdcVw9sIDS4/Rv/i+DCuAou2KQua
>>
>>  emuPHs4W0SDrKRCYpOfYTilzse9RWiTgoCTjTL3whe/uZuWwYgeljZF682+Np+i7+OoZ
>>
>>  YhyyHOijqWNwDR3dLPMXOpg7/u01xguZsjgTFoBMXYvPKWn3V/AXPoVjqC67CJ81vatf
>>  Jlhw==
>> ARC-Authentication-Results: i=2; mx.google.com;
>>dkim=pass header.i=@test.ascendbywix.com header.s=s1
>> header.b=P9JGN5Pt;
>>dkim=pass header.i=@sendgrid.info header.s=smtpapi
>> header.b="PzohlIQ/";
>>arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com
>> dkim=pass dkdomain=test.ascendbywix.com dkim=pass dkdomain=sendgrid.info
>> dmarc=pass fromdomain=test.ascendbywix.com);
>>spf=fail (google.com: domain of
>> bounces+3348031-0178-azeddinebenlarbi329=
>> gmail@sg.test.ascendbywix.com does not designate 81.7.6.53 as
>> permitted sender) smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=
>> gmail@sg.test.ascendbywix.com";
>>dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=
>> test.ascendbywix.com
>> Return-Path: > gmail@sg.test.ascendbywix.com>
>> Received: from takataka.gr ([81.7.6.53])
>> by mx.google.com with ESMTP id
>> r1-20020a1709061ba100b006d07f388e25si10294892ejg.908.2022.03.02.09.00.00
>> for ;
>> Wed, 02 Mar 2022 09:00:00 -0800 (PST)
>> Received-SPF: fail (google.com: domain of
>> bounces+3348031-0178-azeddinebenlarbi329=
>> gmail@sg.test.ascendbywix.com does not 

Re: [mailop] [E] What the f**k, Google?

[Michael Peddemors via mailop]

This will probably help Gmail understand the threat more, at the very 
least, if they haven't been watching for this already.


For all we know, when they parse this, they see the SPF pass, and don't 
check the later SPF fail, but given that they get a lot of forwarded 
email from banks etc, that their customers want, they probably have 
decided to allow this behavior.


(And even you probably want your forwarded email to get to the customer)

There are some curious things, eg ordering and placement of their trace 
headers above the Return-Path, and I won't talk about that..


You do have an argument that if you advertise a -all on the SPF record, 
you are expecting Gmail to reject it.


Also, you have an argument that Gmail should be stripping (and/or 
questioning) the fast there is an existing Return-Path header, which 
should be suspicious/stripped.


And of course, the IP itself. interesting that it is only on a couple of 
RBL's.. but Gmail should be able to note the volume of identical mail... 
or this obvious forged relay attempt, but at this point (and yeah, it is 
the same attack vector that has been reported here and in other places 
over the last couple months) we should leave it to the Gmail folks to 
comment on..


But this should NOT affect the domain reputation IMHO, there may be 
other things that are affecting it.


I would question why you choose to use a MAIL FROM, with a different 
domain than you use in the header from, eg


Return-Path: 



vs

From: "" 




On 2022-03-02 10:18 a.m., Edgaras | SENDER wrote:

 > Add just the headers from a single abuse email here on the thread..
Here you go, latest victim (Wix) abused by azeddinebenlarbi...@gmail.com 
:


Delivered-To: trappy.mctrapf...@gmail.com 


Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
         Wed, 2 Mar 2022 09:00:00 -0800 (PST)
X-Google-Smtp-Source: 
ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id 
m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;

         Wed, 02 Mar 2022 09:00:00 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
         d=google.com ; s=arc-20160816;
 
b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC
 
  rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr
 
  McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb
 
  42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz
 
  +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za

          fhKQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 
d=google.com ; s=arc-20160816;

         h=to:feedback-id:reply-to:subject:subject:message-id:message-id
          :mime-version:from:date:dkim-signature:dkim-signature;
         bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
 
b=L2r7W1Ax8bOAZ/mPCFbyQiXSepDAqF4Z3BDl11dszqt3si4yReg9zYoIqc7wGFOXBV
 
  QuKBtFWs3FTE9fGqBFEwgaDiObCUWdVL08BMI7Uw9EZPL8ej3Mhk5oipUMi3gcSpDbgz
 
  uK6UChfO33wOx8uXoiDVZ8QmBoUEPiBvH/NLVYPHVdcVw9sIDS4/Rv/i+DCuAou2KQua
 
  emuPHs4W0SDrKRCYpOfYTilzse9RWiTgoCTjTL3whe/uZuWwYgeljZF682+Np+i7+OoZ
 
  YhyyHOijqWNwDR3dLPMXOpg7/u01xguZsjgTFoBMXYvPKWn3V/AXPoVjqC67CJ81vatf

          Jlhw==
ARC-Authentication-Results: i=2; mx.google.com ;
        dkim=pass header.i=@test.ascendbywix.com 
 header.s=s1 header.b=P9JGN5Pt;
        dkim=pass header.i=@sendgrid.info  
header.s=smtpapi header.b="PzohlIQ/";
        arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com 
 dkim=pass dkdomain=test.ascendbywix.com 
 dkim=pass dkdomain=sendgrid.info 
 dmarc=pass fromdomain=test.ascendbywix.com 
);
        spf=fail (google.com : domain of 
bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com 
 does not designate 81.7.6.53 
as permitted sender) 
smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com 
";
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) 
header.from=test.ascendbywix.com 
Return-Path: 
>

Received: from takataka.gr  ([81.7.6.53])
         by mx.google.com  with ESMTP id 
r1-20020a1709061ba100b006d07f388e25si10294892ejg.908.2022.03.02.09.00.00
         for >;

         Wed, 02 Mar 2022 09:00:00 -0800 (PST)
Received-SPF: fail (google.com : domain of 

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 02/03/2022 18:00, Edgaras | SENDER via mailop wrote:
> We did, several times actually.
> Does nothing.

It doesn't look like you're able to provide an example of an email where
Google have accepted it as belonging to you when the DKIM signature
fails.

Do you only have the IP addresses that were involved in resending your
email? I have no idea what information Google provide to you.

You would be able to tell when Google make DNS queries for selectors
that you have revoked (rotating without removing or modifying them will
not be enough) by monitoring queries on your DNS servers.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> It does seem like Google could notice "old" date headers and BCCs and the
fact the mail is coming from a dedicated spam factory and maybe treat it a
little differently, though.

My point exactly. They could maybe notice it's hard failing SPF, or rDNS,
or just about every requirement they have published.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 8:09 PM Alan Hodgson via mailop 
wrote:

> On Wed, 2022-03-02 at 17:28 +, Simon Arlott via mailop wrote:
>
> On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
> There's literally nothing you can do as a sender to prevent your
> reputation from being trashed.
>
>
> No, that's quite clearly not literally true. Stop DKIM signing the spam
> email and the problem goes away.
>
>
> This. If you're sending mail on behalf of a stranger, perhaps you should
> only sign it with their domain.
>
> It does seem like Google could notice "old" date headers and BCCs and the
> fact the mail is coming from a dedicated spam factory and maybe treat it a
> little differently, though.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> Add just the headers from a single abuse email here on the thread..
Here you go, latest victim (Wix) abused by azeddinebenlarbi...@gmail.com:

Delivered-To: trappy.mctrapf...@gmail.com
Received: by 2002:ac9:5a7:0:0:0:0:0 with SMTP id 36csp448821ocw;
Wed, 2 Mar 2022 09:00:00 -0800 (PST)
X-Google-Smtp-Source:
ABdhPJyxgfRpUsqWbBr/re0QDp8Iuv7ucxtW/eurO7tWJljvtHlCTV1lhn/G7sQ8oaAejLhkikay
X-Received: by 2002:a17:906:2ac9:b0:6ce:dc0f:9139 with SMTP id
m9-20020a1709062ac900b006cedc0f9139mr24070631eje.206.1646240400450;
Wed, 02 Mar 2022 09:00:00 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1646240400; cv=pass;
d=google.com; s=arc-20160816;
b=l3yLyzfYcfCR9yaygSwMGchxrJnNoDvQiZ7ulrnSnSJDNm0Z6OzuvvxQRxFitXfKkC

 rv+M/at6NjqHvthAySYJHllze6pEFIgdYPLDbajCqIin8a09vhX6YsWdsGK8OMin/Zlr

 McvJ3AxyItbQ5vASGm2pROGaky8iG+isG1TIu1HtmVbGk75ihEllQDx8yxgKh7rsZ2Nb

 42quNIa1SZ50v3wgs5o6F07ZCWGc9xR6t7UGhAOscbrTYYUWzCcjXNG3s2zqwhAV0kuz

 +ML+Idfy5jUvcrNWiKA1eBnELSskInJoYdzHddUq8E9tf+609ECu58A2pdizVkGWu/Za
 fhKQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=to:feedback-id:reply-to:subject:subject:message-id:message-id
 :mime-version:from:date:dkim-signature:dkim-signature;
bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
b=L2r7W1Ax8bOAZ/mPCFbyQiXSepDAqF4Z3BDl11dszqt3si4yReg9zYoIqc7wGFOXBV

 QuKBtFWs3FTE9fGqBFEwgaDiObCUWdVL08BMI7Uw9EZPL8ej3Mhk5oipUMi3gcSpDbgz

 uK6UChfO33wOx8uXoiDVZ8QmBoUEPiBvH/NLVYPHVdcVw9sIDS4/Rv/i+DCuAou2KQua

 emuPHs4W0SDrKRCYpOfYTilzse9RWiTgoCTjTL3whe/uZuWwYgeljZF682+Np+i7+OoZ

 YhyyHOijqWNwDR3dLPMXOpg7/u01xguZsjgTFoBMXYvPKWn3V/AXPoVjqC67CJ81vatf
 Jlhw==
ARC-Authentication-Results: i=2; mx.google.com;
   dkim=pass header.i=@test.ascendbywix.com header.s=s1
header.b=P9JGN5Pt;
   dkim=pass header.i=@sendgrid.info header.s=smtpapi
header.b="PzohlIQ/";
   arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com dkim=pass
dkdomain=test.ascendbywix.com dkim=pass dkdomain=sendgrid.info dmarc=pass
fromdomain=test.ascendbywix.com);
   spf=fail (google.com: domain of
bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
does not designate 81.7.6.53 as permitted sender)
smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=
gmail@sg.test.ascendbywix.com";
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=
test.ascendbywix.com
Return-Path: 
Received: from takataka.gr ([81.7.6.53])
by mx.google.com with ESMTP id
r1-20020a1709061ba100b006d07f388e25si10294892ejg.908.2022.03.02.09.00.00
for ;
Wed, 02 Mar 2022 09:00:00 -0800 (PST)
Received-SPF: fail (google.com: domain of
bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
does not designate 81.7.6.53 as permitted sender) client-ip=81.7.6.53;
Authentication-Results: mx.google.com;
   dkim=pass header.i=@test.ascendbywix.com header.s=s1
header.b=P9JGN5Pt;
   dkim=pass header.i=@sendgrid.info header.s=smtpapi
header.b="PzohlIQ/";
   arc=pass (i=1 spf=pass spfdomain=sg.test.ascendbywix.com dkim=pass
dkdomain=test.ascendbywix.com dkim=pass dkdomain=sendgrid.info dmarc=pass
fromdomain=test.ascendbywix.com);
   spf=fail (google.com: domain of
bounces+3348031-0178-azeddinebenlarbi329=gmail@sg.test.ascendbywix.com
does not designate 81.7.6.53 as permitted sender)
smtp.mailfrom="bounces+3348031-0178-azeddinebenlarbi329=
gmail@sg.test.ascendbywix.com";
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=
test.ascendbywix.com
Received: by 2002:a4a:390e:0:0:0:0:0 with SMTP id m14csp2497925ooa;
Tue, 1 Mar 2022 01:20:28 -0800 (PST)
X-Received: by 2002:a25:b3c7:0:b0:623:e9fe:e108 with SMTP id
x7-20020a25b3c700b00623e9fee108mr24017231ybf.335.1646126428656;
Tue, 01 Mar 2022 01:20:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1646126428; cv=none;
d=google.com; s=arc-20160816;
b=klrOQobiQW3z0we7NWks+cp02ocQHUJPSDgVAWXTvkjyJxD+ihHvo9ERutsIQzrG8K

 1zVjI45xZs4cE7O6cB6Ylech/BF0+6XA4LmbHa7P69SfszZ0BJvkHMbQIKGSQ2EgkuIj

 wsxPqXOGAEUfcv3loqu+yhHvfF/e1FB7yJgASvLFU36gkWSy/cz91O1eeGfFGrgKSP9V

 n8CBONOor1cpwVaFhRTEPQ0ByIJRx/10feTaguiwCpoovac0/uajp+wgV3kBu8yMQOsL

 yFDfTH30/w8Lmo9A3R7yExiXctr88AkYrMIXSg5S3JZlCLieLxEfSirEDH4Hchgiiwzs
 KU2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=to:feedback-id:reply-to:subject:message-id:mime-version:from:date
 :dkim-signature:dkim-signature;
bh=unij9luYZjytYq8AnlTGrziLaTBYROHjkIEkJHrCZEI=;
b=e7JNdh6KCXyb8EhXXTQo9p1qZ9yFuguH3aBwGC+IaK009NPSfnv8r7NBCK8FiiOESN

 m14bKwy+o9XaLGAw3F7UO2TE9q74/sOgB2L1IdGZ7F+pKvKGlQVRoKGFl1cy5CTZ9QXX

 kL3YX3J97nd3eOLe2QgR55G19Cxqa/wcgdfaJjzDrN/9aTSAvhX/K8UkVyLmGF/wxSL+

 s6ZJchYDxaORmFRaUK79sN/oafqXYPH84/32Nc1IWHC9PL1ecItttkLij8SwUvDMjInv

 mtcY9WoZbTIBvgTNRaxeEZwfuLweaV9VUwub2RNNOwLfRezbW3z6aezBUUiMd2FR5wc3
 bJqA==
ARC-Authentication-Results: i=1; 

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

> No, that's quite clearly not literally true. Stop DKIM signing the spam
email and the problem goes away.
Yep, and go directly against all the best email practices, guidelines and
so on.

> You may not like it but Google is implementing DMARC correctly if the
DKIM signature is still valid.
The point is not their implementation of DMARC. It's how they handle
messages from obvious spam sources, which funnily enough don't satisfy any
of their own guidelines https://support.google.com/mail/answer/81126,
except for a hijacked DKIM signature.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 7:30 PM Simon Arlott via mailop 
wrote:

> On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
> > To clarify further, I will walk through the case where an attacker abuses
> > Getresponse (getresponse2.eml).
> > What happens here:
> > 1. Attacker creates an account at Getresponse using a throwaway spam site
> > storagemodels.org.uk
> > 2. Sends a single email from Getresponse (using
> re...@storagemodels.org.uk)
> > to himself (arsalanpir...@gmail.com is the attacker's Gmail address)
> > 3. The email is signed with getresponse-mail.com, a domain with a good
> > reputation at Gmail.
>
> The spam email has been signed by getresponse-mail.com
>
> > 4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
> > against the reputation of getresponse-mail.com
> > 5. Mails are delivered to countless Gmail users.
>
> > There's literally nothing you can do as a sender to prevent your
> reputation from being trashed.
>
> No, that's quite clearly not literally true. Stop DKIM signing the spam
> email and the problem goes away.
>
> > What's worrying is that even if the headers are oversigned, DMARC set to
> reject, it does nothing to stop this attack.
>
> Do you have an example where the DKIM signature is now invalid but Google
> has accepted it and associated it with the victim domain?
>
> You may not like it but Google is implementing DMARC correctly if the DKIM
> signature is still valid.
>
> --
> Simon Arlott
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

We did, several times actually.
Does nothing.

[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 7:55 PM Evan Burke  wrote:

>
> Have you rotated keys since you began oversigning headers? Until you do,
> there's nothing stopping them from replaying older messages that weren't
> oversigned.
>
>
>
> On Wed, Mar 2, 2022 at 9:16 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>> Hi Simon,
>>
>> > Which domains, IP addresses and DKIM signatures are you responsible for
>> > (or not) in the examples?
>> Our domain that is impacted: sendersrv.com
>> SPF: v=spf1 ip4:185.3.229.125 ip4:185.3.229.126 ip4:185.3.229.127 ip4:
>> 185.3.229.128/27 ip4:141.136.38.0/24 ip4:141.136.40.0/24 ip4:
>> 195.191.140.0/24 ip4:195.191.176.0/24 -all
>> IP addresses, which we do not control and which are being to send out
>> spam are mentioned in my initial email:
>> 176.56.220.0/24
>> 176.56.221.0/24
>> 176.56.222.0/24
>> 103.110.248.0/24
>> 
>>
>> I added other samples that we discovered just to show that the problem is
>> not only affecting us.
>> Other abused domains are:
>> sendgrid.info, spam sent from 104.168.76.42 (no rDNS!)
>> getresponse-mail.com, from 119.235.249.182 (again no rDNS, SPF hard
>> fails...)
>> sfr.fr, from 85.120.225.105 (SPF fails)
>> ...
>> BTW, I only redacted the spamtrap email address, all other headers are
>> left as is.
>> To clarify further, I will walk through the case where an attacker abuses
>> GetResponse (getresponse2.eml).
>> What happens here:
>> 1. Attacker creates an account at Getresponse using a throwaway spam site
>> storagemodels.org.uk
>> 2. Sends a single email from Getresponse (using
>> re...@storagemodels.org.uk) to himself (arsalanpir...@gmail.com is the
>> attacker's Gmail address)
>> 3. The email is signed with getresponse-mail.com, a domain with a good
>> reputation at Gmail.
>> 4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
>> against the reputation of getresponse-mail.com
>> 5. Mails are delivered to countless Gmail users.
>>
>> What's worrying is that even if the headers are oversigned, DMARC set to
>> reject, it does nothing to stop this attack. There's literally nothing you
>> can do as a sender to prevent your reputation from being trashed.
>>
>>
>> [image: Sender] Edgar Vaitkevičius, founder / CEO
>> ed...@sender.net
>>
>>
>>
>>
>> On Wed, Mar 2, 2022 at 6:39 PM Simon Arlott via mailop 
>> wrote:
>>
>>> On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
>>> > Sorry for losing my nerve, but it is harming our reputation for a month
>>> > now, tried all possible channels to report this, and the issue is being
>>> > completely ignored.
>>>
>>> These examples have the same problem that the original one in January
>>> did. They're just copies of emails without any explanation as to who
>>> you are and which domain's reputation is being impacted.
>>>
>>> Which domains, IP addresses and DKIM signatures are you responsible for
>>> (or not) in the examples?
>>>
>>> If you need to redact something then replace it with "example.com",
>>> "example.net", "example.org", etc. and state how each of them fit into
>>> this. Provide a copy of the SPF/DKIM records (where relevant) for any
>>> redacted domains (the immediate sending IP may not be in the SPF record
>>> but maybe an earlier one or Google is).
>>>
>>> Which domain's reputation is being impacted?
>>>
>>> Without that information it's very hard to identify exactly what is
>>> going on. You've stated previously that "first an attacker sent a test
>>> email from our platform" but these ones don't appear to originate from
>>> you.
>>>
>>> --
>>> Simon Arlott
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Alan Hodgson via mailop]

On Wed, 2022-03-02 at 17:28 +, Simon Arlott via mailop wrote:
> On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop
>  wrote:
> 
> > There's literally nothing you can do as a sender to prevent your
> > reputation from being trashed.
> 
> No, that's quite clearly not literally true. Stop DKIM signing the
> spam email and the problem goes away.
> 

This. If you're sending mail on behalf of a stranger, perhaps you
should only sign it with their domain.

It does seem like Google could notice "old" date headers and BCCs and
the fact the mail is coming from a dedicated spam factory and maybe
treat it a little differently, though.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Michael Peddemors via mailop]

Add just the headers from a single abuse email here on the thread.. 
sanitize as needed.. seems that they of course can only use part of the 
information as a forgery (eg SendGrid headers)


I think this is an attack vector that was seen back even a few months 
ago, however that type of an attack quickly gets an IP on an RBL.. normally.


On 2022-03-02 9:12 a.m., Edgaras | SENDER via mailop wrote:

Hi Simon,

 > Which domains, IP addresses and DKIM signatures are you responsible for
 > (or not) in the examples?
Our domain that is impacted: sendersrv.com 
SPF: v=spf1 ip4:185.3.229.125 ip4:185.3.229.126 ip4:185.3.229.127 
ip4:185.3.229.128/27  ip4:141.136.38.0/24 
 ip4:141.136.40.0/24  
ip4:195.191.140.0/24  ip4:195.191.176.0/24 
 -all
IP addresses, which we do not control and which are being to send out 
spam are mentioned in my initial email:

176.56.220.0/24 
176.56.221.0/24 
176.56.222.0/24 
103.110.248.0/24 


I added other samples that we discovered just to show that the problem 
is not only affecting us.

Other abused domains are:
sendgrid.info , spam sent from 104.168.76.42 (no 
rDNS!)
getresponse-mail.com , from 119.235.249.182 
(again no rDNS, SPF hard fails...)

sfr.fr , from 85.120.225.105 (SPF fails)
...
BTW, I only redacted the spamtrap email address, all other headers are 
left as is.
To clarify further, I will walk through the case where an attacker 
abuses GetResponse (getresponse2.eml).

What happens here:
1. Attacker creates an account at Getresponse using a throwaway spam 
site storagemodels.org.uk 
2. Sends a single email from Getresponse (using 
re...@storagemodels.org.uk ) 
to himself (arsalanpir...@gmail.com  is 
the attacker's Gmail address)
3. The email is signed with getresponse-mail.com 
, a domain with a good reputation at Gmail.
4. Attacker then proceeds to spam from 119.235.249.182, spam mails count 
against the reputation of getresponse-mail.com 

5. Mails are delivered to countless Gmail users.

What's worrying is that even if the headers are oversigned, DMARC set to 
reject, it does nothing to stop this attack. There's literally nothing 
you can do as a sender to prevent your reputation from being trashed.



Sender  Edgar Vaitkevičius, founder / CEO
ed...@sender.net 




On Wed, Mar 2, 2022 at 6:39 PM Simon Arlott via mailop 
mailto:mailop@mailop.org>> wrote:


On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
 > Sorry for losing my nerve, but it is harming our reputation for a
month
 > now, tried all possible channels to report this, and the issue is
being
 > completely ignored.

These examples have the same problem that the original one in January
did. They're just copies of emails without any explanation as to who
you are and which domain's reputation is being impacted.

Which domains, IP addresses and DKIM signatures are you responsible for
(or not) in the examples?

If you need to redact something then replace it with "example.com
",
"example.net ", "example.org
", etc. and state how each of them fit into
this. Provide a copy of the SPF/DKIM records (where relevant) for any
redacted domains (the immediate sending IP may not be in the SPF record
but maybe an earlier one or Google is).

Which domain's reputation is being impacted?

Without that information it's very hard to identify exactly what is
going on. You've stated previously that "first an attacker sent a test
email from our platform" but these ones don't appear to originate from
you.

-- 
Simon Arlott

___
mailop mailing list
mailop@mailop.org 
https://list.mailop.org/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop  
wrote:
> To clarify further, I will walk through the case where an attacker abuses
> Getresponse (getresponse2.eml).
> What happens here:
> 1. Attacker creates an account at Getresponse using a throwaway spam site
> storagemodels.org.uk
> 2. Sends a single email from Getresponse (using re...@storagemodels.org.uk)
> to himself (arsalanpir...@gmail.com is the attacker's Gmail address)
> 3. The email is signed with getresponse-mail.com, a domain with a good
> reputation at Gmail.

The spam email has been signed by getresponse-mail.com

> 4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
> against the reputation of getresponse-mail.com
> 5. Mails are delivered to countless Gmail users.

> There's literally nothing you can do as a sender to prevent your reputation 
> from being trashed.

No, that's quite clearly not literally true. Stop DKIM signing the spam email 
and the problem goes away.

> What's worrying is that even if the headers are oversigned, DMARC set to 
> reject, it does nothing to stop this attack.

Do you have an example where the DKIM signature is now invalid but Google has 
accepted it and associated it with the victim domain?

You may not like it but Google is implementing DMARC correctly if the DKIM 
signature is still valid.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

Hi Simon,

> Which domains, IP addresses and DKIM signatures are you responsible for
> (or not) in the examples?
Our domain that is impacted: sendersrv.com
SPF: v=spf1 ip4:185.3.229.125 ip4:185.3.229.126 ip4:185.3.229.127 ip4:
185.3.229.128/27 ip4:141.136.38.0/24 ip4:141.136.40.0/24 ip4:
195.191.140.0/24 ip4:195.191.176.0/24 -all
IP addresses, which we do not control and which are being to send out spam
are mentioned in my initial email:
176.56.220.0/24
176.56.221.0/24
176.56.222.0/24
103.110.248.0/24


I added other samples that we discovered just to show that the problem is
not only affecting us.
Other abused domains are:
sendgrid.info, spam sent from 104.168.76.42 (no rDNS!)
getresponse-mail.com, from 119.235.249.182 (again no rDNS, SPF hard
fails...)
sfr.fr, from 85.120.225.105 (SPF fails)
...
BTW, I only redacted the spamtrap email address, all other headers are left
as is.
To clarify further, I will walk through the case where an attacker abuses
GetResponse (getresponse2.eml).
What happens here:
1. Attacker creates an account at Getresponse using a throwaway spam site
storagemodels.org.uk
2. Sends a single email from Getresponse (using re...@storagemodels.org.uk)
to himself (arsalanpir...@gmail.com is the attacker's Gmail address)
3. The email is signed with getresponse-mail.com, a domain with a good
reputation at Gmail.
4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
against the reputation of getresponse-mail.com
5. Mails are delivered to countless Gmail users.

What's worrying is that even if the headers are oversigned, DMARC set to
reject, it does nothing to stop this attack. There's literally nothing you
can do as a sender to prevent your reputation from being trashed.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 6:39 PM Simon Arlott via mailop 
wrote:

> On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
> > Sorry for losing my nerve, but it is harming our reputation for a month
> > now, tried all possible channels to report this, and the issue is being
> > completely ignored.
>
> These examples have the same problem that the original one in January
> did. They're just copies of emails without any explanation as to who
> you are and which domain's reputation is being impacted.
>
> Which domains, IP addresses and DKIM signatures are you responsible for
> (or not) in the examples?
>
> If you need to redact something then replace it with "example.com",
> "example.net", "example.org", etc. and state how each of them fit into
> this. Provide a copy of the SPF/DKIM records (where relevant) for any
> redacted domains (the immediate sending IP may not be in the SPF record
> but maybe an earlier one or Google is).
>
> Which domain's reputation is being impacted?
>
> Without that information it's very hard to identify exactly what is
> going on. You've stated previously that "first an attacker sent a test
> email from our platform" but these ones don't appear to originate from
> you.
>
> --
> Simon Arlott
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
> Sorry for losing my nerve, but it is harming our reputation for a month
> now, tried all possible channels to report this, and the issue is being
> completely ignored.

These examples have the same problem that the original one in January
did. They're just copies of emails without any explanation as to who
you are and which domain's reputation is being impacted.

Which domains, IP addresses and DKIM signatures are you responsible for
(or not) in the examples?

If you need to redact something then replace it with "example.com",
"example.net", "example.org", etc. and state how each of them fit into
this. Provide a copy of the SPF/DKIM records (where relevant) for any
redacted domains (the immediate sending IP may not be in the SPF record
but maybe an earlier one or Google is).

Which domain's reputation is being impacted?

Without that information it's very hard to identify exactly what is
going on. You've stated previously that "first an attacker sent a test
email from our platform" but these ones don't appear to originate from
you.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

I have tried sending spam samples as attachments, looks like that didn't
work, probably list spam filter rejects them. Uploaded them here:
https://www.dropbox.com/sh/dtoz0af0k5b86ic/AAC4mFJeTqFUjuEF41jj13XNa?dl=0

All of them are exploiting the same flaw I reported a *month* ago.
Scenario:
Attacker sends a message via Klaviyo, Sendgrid, Sender.net, SFR, etc to
their own email address, then massively replays that message via whatever
IP addresses under their control.
It doesn't matter that the IP addresses might be without rDNS match, not
included in SPF records, DMARC can be set to reject, all of that is ignored.
Gmail thinks it's authenticated with the abused domain, and counts all the
spam messages against the domain's reputation.
Given that the amount of spam sent this way is staggering, it quickly
damages the domain.

Sorry for losing my nerve, but it is harming our reputation for a month
now, I have tried all possible channels to report this, and the issue is
being completely ignored.



[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 5:29 PM Marcel Becker 
wrote:

>
> On Wed, Mar 2, 2022 at 2:00 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>>
>> sorry, I can't describe the stupidity and incompetence of Gmail systems
>> lately without resorting to expletives.
>>
>
> Personally I think it's more productive -- and in the spirit of this
> mailing list -- to focus on sharing more details and examples so maybe the
> community can form their own opinion and even help, than doing what you are
> doing.
>
> - Marcel
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

Some attached spamples - all of them are exploiting the same flaw I
reported a *month *ago.
Attacker sends a message via Klaviyo, Sendgrid, SFR, etc to their own email
address, then massively replays that message via whatever IP addresses
under their control.
It doesn't matter that the IP addresses might be without rDNS match, not
included in SPF records, DMARC can be set to reject, all of that is ignored.
Gmail thinks it's authenticated with the abused domain, and counts that
message against the domain's reputation.
Given that the amount of spam sent this way is staggering, it quickly
damages the domain.

Sorry for losing my nerve, but it is harming our reputation for a month
now, tried all possible channels to report this, and the issue is being
completely ignored.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 5:29 PM Marcel Becker 
wrote:

>
> On Wed, Mar 2, 2022 at 2:00 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>>
>> sorry, I can't describe the stupidity and incompetence of Gmail systems
>> lately without resorting to expletives.
>>
>
> Personally I think it's more productive -- and in the spirit of this
> mailing list -- to focus on sharing more details and examples so maybe the
> community can form their own opinion and even help, than doing what you are
> doing.
>
> - Marcel
>
>
--- Begin Message ---

*ɢᴀ̊ʀ ᴜᴛ sɴᴀʀᴛ: ᴅɪɴ ᴅʏsᴏɴ ᴠᴀᴄᴜᴜᴍ-ʙᴇʟᴏ̈ɴɪɴɢ*




sᴠᴀʀᴀ & ᴠɪɴɴ!
ᴅʏsᴏɴ ᴠᴀᴄᴄᴜᴍ

ᴅᴜ ʜᴀʀ ʙʟɪᴠɪᴛ ᴜᴛᴠᴀʟᴅ ᴛɪʟʟ ᴀᴛᴛ ᴅᴇʟᴛᴀ ɪ ᴠᴀ̊ʀᴛ ʟᴏᴊᴀʟɪᴛᴇᴛsᴘʀᴏɢʀᴀᴍ ʜᴇʟᴛ 
ɢʀᴀᴛɪs! ᴅᴇᴛ ᴋᴏᴍᴍᴇʀ ʙᴀʀᴀ ᴀᴛᴛ ᴛᴀ ᴅɪɢ ᴇɴ ᴍɪɴᴜᴛ, sᴀ̊ ᴋᴏᴍᴍᴇʀ ᴅᴜ ᴀᴛᴛ ғᴀ̊ ᴇᴛᴛ 
ғᴀɴᴛᴀsᴛɪsᴋᴛ ᴘʀɪs.


**ɢᴏ̈ʀ ᴇɴᴋᴀ̈ᴛᴇɴ ɴᴜ ❭❭** 

ᴏᴍ ᴅᴜ ɪɴᴛᴇ ʟᴀ̈ɴɢʀᴇ ᴠɪʟʟ ᴛᴀ ᴇᴍᴏᴛ ᴅᴇssᴀ ᴇ-ᴘᴏsᴛᴍᴇᴅᴅᴇʟᴀɴᴅᴇɴ ᴋᴀɴ ᴅᴜ ᴀᴠsʟᴜᴛᴀ 
ᴘʀᴇɴᴜᴍᴇʀᴀᴛɪᴏɴᴇɴ ɢᴇɴᴏᴍ ᴀᴛᴛ ᴋʟɪᴄᴋᴀhär 
ᴇʟʟᴇʀ ɢᴇɴᴏᴍ ᴀᴛᴛ sᴋʀɪᴠᴀ ᴛɪʟʟ ퟸퟸퟷퟸ s ᴄʜɪᴄᴋᴀsᴀᴡ ᴛʀʟ. ᴏʀʟᴀɴᴅᴏ, ғʟ 
ퟹퟸ퟾ퟸퟻ




ᴛʜᴇ ᴀᴅᴠᴇʀᴛɪsᴇʀ ᴅᴏᴇs ɴᴏᴛ ᴍᴀɴᴀɢᴇ ʏᴏᴜʀ sᴜʙsᴄʀɪᴘᴛɪᴏɴ.
ɪғ ʏᴏᴜ ᴘʀᴇғᴇʀ ɴᴏᴛ ᴛᴏ ʀᴇᴄᴇɪᴠᴇ ғᴜʀᴛʜᴇʀ ᴄᴏᴍᴍᴜɴɪᴄᴀᴛɪᴏɴ ᴘʟᴇᴀsᴇ 
ᴜɴsᴜʙsᴄʀɪʙᴇhere 
ᴏʀ ᴡʀɪᴛᴇ ᴛᴏ: ퟼ퟷퟶퟷ ʟᴏɴɢ ᴘʀᴀɪʀɪᴇ ʀᴅ,sᴛᴇ ퟽ퟺퟺ #ퟻퟷퟷ, ғʟᴏᴡᴇʀ ᴍᴏᴜɴᴅ, 
ᴛx, ퟽ퟻퟶퟸ퟾
--- End Message ---
--- Begin Message ---
[Träffa våra andra medlemmar](https://t.co/fyf0hKrrTp)

https://t.co/fyf0hKrrTp

[och koppla ihop idag!n](https://t.co/fyf0hKrrTp)
 

[ Din information](https://t.co/fyf0hKrrTp)
 

[kommer att behandlas konfidentiellt](https://t.co/fyf0hKrrTp)
 

[Gratis fan](https://t.co/fyf0hKrrTp)

[Klicka här](https://t.co/fyf0hKrrTp)

[Hitta enkla tjejer här!](https://t.co/fyf0hKrrTp)
 

[Kan inte se bilderna? klicka bara här >>](https://t.co/fyf0hKrrTp)

 

[=>FUCK GRATIS ENDAST IDAG
=>inga falska profiler
=>inget kreditkort krävs
=>den fria tillgången](https://t.co/fyf0hKrrTp)

https://t.co/fyf0hKrrTp

https://t.co/fyf0hKrrTp

 

https://t.co/fyf0hKrrTp
 

 

Om du vill sluta ta emot detta meddelande [KLICKA HÄR](https://t.co/t2PgHvzZ3C)

[säga upp](https://t.co/r4ypaZN3bQ)

Powered by 
[Klaviyo](https://www.klaviyo.com/?utm_medium=freebie_source=brand_term=YgF2dk)

You received this email from sexynudes. If you would like to unsubscribe, 
[click here](http://manage.kmail-lists.com/subscriptions/placeholder).--- End Message ---
--- Begin Message ---
Title: *|MC:SUBJECT|*








*|MC_PREVIEW_TEXT|*





































  	
			









	
		
			
			

	
		
		
			

	Med QuickFinans kan du enkelt och utan besvr lne penger online.


	
	Genom att samla dessa smln i ett och samma ln kan du f bttre villkor och framfrallt en billigare mnadskostnad.

	S hr funkar det:

	QuickFinans har en bra och enkel tjnst som hjlper dig hitta rtt ln  helt kostnadsfritt!

	
		Enkel online-anskan - f svar direkt
		Du behver ingen skerhet fr lnet
		Du kan anvnda pengarna till vad du vill
		
			Fyll i formulret och f svar p din anskan direkt.
			Skriv under ditt avtal med e-signering.
			Din 

Re: [mailop] [E] What the f**k, Google?

[Edgaras | SENDER via mailop]

Hi Marcel,

I sent an email to the list with examples where SFR, GetResponse, Klaviyo,
Sendgrid and others are being abused the same way.
Looks like it did not get posted, maybe due to the spam attachments.
Will try again now.


[image: Sender] Edgar Vaitkevičius, founder / CEO
ed...@sender.net




On Wed, Mar 2, 2022 at 5:29 PM Marcel Becker 
wrote:

>
> On Wed, Mar 2, 2022 at 2:00 AM Edgaras | SENDER via mailop <
> mailop@mailop.org> wrote:
>
>>
>> sorry, I can't describe the stupidity and incompetence of Gmail systems
>> lately without resorting to expletives.
>>
>
> Personally I think it's more productive -- and in the spirit of this
> mailing list -- to focus on sharing more details and examples so maybe the
> community can form their own opinion and even help, than doing what you are
> doing.
>
> - Marcel
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] What the f**k, Google?

[Marcel Becker via mailop]

On Wed, Mar 2, 2022 at 2:00 AM Edgaras | SENDER via mailop <
mailop@mailop.org> wrote:

>
> sorry, I can't describe the stupidity and incompetence of Gmail systems
> lately without resorting to expletives.
>

Personally I think it's more productive -- and in the spirit of this
mailing list -- to focus on sharing more details and examples so maybe the
community can form their own opinion and even help, than doing what you are
doing.

- Marcel
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop