Re: [mailop] Gmail throttles anyway

[Gil Bahat]

you know, I think that's one of the highly undesirable unintended
consequences of DMARC ATM - the habit it's forming to dig out messages from
spam. I keep thinking to myself how I need not make a mistake about
something patently spammy or risky when digging out these from spam. so I
spend a lot more time looking at spam.

Gil

On Thu, Feb 4, 2016 at 11:10 PM, Franck Martin  wrote:

>
>
> On Thu, Feb 4, 2016 at 1:02 PM, Michael Wise 
> wrote:
>
>> It looks like the DKIM bits were added by Gmail.
>>
>> As to point 4 … Do Not Get Me Started.
>>
>>
>>
> This list is not hosted by Google? So the bits that break DKIM are added
> by mailman, and it is a statement not a judgement.
>
> As for 4, why deny so much fun? :P
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Matthias Leisi]

> Am 04.02.2016 um 22:41 schrieb Brandon Long :
> That's what I think is the case, indeed. Hetzner is the provider.
> 
> It is a netblock quota you're hitting, yes.  As we see more and larger hit 
> and run spam jobs from previously unknown or low volume IPs and netblocks, 
> the low volume senders are caught in the cross fire.

At dnswl.org  we’ve seen an increased number of spam sources 
at Hetzner over the past few weeks. We do not see mail content, just DNS 
lookups (other than through a couple of spamtraps), but there seems to be a 
pattern to it: „new“ IP, using Hetzner’s default rDNS, starting with large 
volumes per IP right away, IPs scattered around Hetzner netblocks „randomly“. 

> I'll ping the spam team about the messaging again, saying IP is definitely 
> wrong there.  And I can ping them about better handling about this, they've 
> made some improvements recently, but it's a hard problem.

Reputation by AS is indeed non-trivial. It works well for most ASes, but for 
"tightly packed" ASes such as for large hosters, it’s usefulness is limited.

— Matthias


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[SM]

Hi Michael,
At 17:27 04-02-2016, Michael Wise wrote:
If you're going to do something that will break the DKIM signature 
as a matter of course,

You should remove the DKIM signature, and maybe re-sign it with your own.

You shouldn't break the signature and then forward what was once 
goodmail with a now busted signature.


The issue with removing a DKIM signature which would get broken is 
that it is not easy to reverse the removal in future.  It is better 
[1] to treat the "broken" DKIM signature as unsigned.


Regards,
-sm

1. This depends on the receivers you are sending mail to. 



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Franck Martin]

On Thu, Feb 4, 2016 at 12:45 PM, Brandon Long  wrote:

>
>
> On Thu, Feb 4, 2016 at 12:17 PM, Franck Martin 
> wrote:
>
>> Neil,
>>
>> it is even surprising it gets delivered at all...
>>
>
> *whistling*
>
> Yeah, I added a personal filter for my account, if list:mailop never spam.
>
> I'm sure ARC will solve all our troubles.
>
> Yeap, I do that and have a DMARC exception for this list (dis=mailing_list),
and looking forward to ARC. First step for this list is SPF and DKIM.

Original-Authentication-Results: x.linkedin.com; iprev=pass
policy.iprev="213.138.100.131"; spf=neutral
smtp.mailfrom="mailop-boun...@mailop.org"
smtp.helo="chilli.nosignal.org"; dkim=fail (signature verification
failed) header.d=google.com; tls=none; dmarc=fail (p=reject;
dis=mailing_list) header.from=google.com

seeing also tls=none, It would be uber cool if this list was doing STARTTLS too.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Andreas Schamanek]

Hi Brandon,

On Thu, 4 Feb 2016, at 13:41, Brandon Long wrote:

> It is a netblock quota you're hitting, yes.  As we see more and 
> larger hit and run spam jobs from previously unknown or low volume 
> IPs and netblocks, the low volume senders are caught in the cross 
> fire.
> 
> I'll ping the spam team about the messaging again, saying IP is 
> definitely wrong there. 

Thanks!

> And I can ping them about better handling about this, they've made 
> some improvements recently, but it's a hard problem.

That would be even better. But I understand that the problem is hard. 
I am active in the antispam community, too.

> Also, the bulk sender guidelines don't only apply to bulk senders, 
> in particular, you have no authentication for your messages.

For one, I don't believe in DKIM. But more importantly, it's just not 
worth the efforts to implement DKIM, DMARC, DNSSEC etc. for 15 msg/day,
or at least it wasn't so far.

> Some of the messages from that server we're treating as 
> authenticated because of our best guess for SPF, but that's not 
> really sustainable.

This I do not understand. All involved domains have MX records 
pointing at the server's IP address. How could a guessed SPF fail?

> > It's also their customers who do not receive (in my case) mostly 
> > individual messages which are often even expected in advance (like 
> > people asking for a document via SMS, and then they have to wait 
> > hours until it arrives at Gmail).
> 
> Spam fighting is a tradeoff between false positives and false 
> negatives.

While this is true we should still strive to reduce false 
classifications.

What Google/Gmail effectively is doing here is a greylisting with 
delays in the range of several hours. I wonder how efficient this is. 
Anyway, it would be nice if Gmail would at least honor "serious" mail 
servers who do not give up sending the same message for hours, i.e. 
whitelist like typical greylisting implementations do.

Of course, I only know my own servers and networks. It probably looks 
quite different from the other side.

-- 
-- Andreas

   :-)


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Michael Wise]

If you're going to run a mailing-list and you don't believe in DKIM ... fine!
But remove the DKIM headers before resending the traffic, please.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Andreas Schamanek
Sent: Thursday, February 4, 2016 2:28 PM
To: mailop <mailop@mailop.org>
Subject: Re: [mailop] Gmail throttles anyway


Hi Brandon,

On Thu, 4 Feb 2016, at 13:41, Brandon Long wrote:

> It is a netblock quota you're hitting, yes.  As we see more and 
> larger hit and run spam jobs from previously unknown or low volume 
> IPs and netblocks, the low volume senders are caught in the cross 
> fire.
> 
> I'll ping the spam team about the messaging again, saying IP is 
> definitely wrong there. 

Thanks!

> And I can ping them about better handling about this, they've made 
> some improvements recently, but it's a hard problem.

That would be even better. But I understand that the problem is hard. 
I am active in the antispam community, too.

> Also, the bulk sender guidelines don't only apply to bulk senders, 
> in particular, you have no authentication for your messages.

For one, I don't believe in DKIM. But more importantly, it's just not 
worth the efforts to implement DKIM, DMARC, DNSSEC etc. for 15 msg/day,
or at least it wasn't so far.

> Some of the messages from that server we're treating as 
> authenticated because of our best guess for SPF, but that's not 
> really sustainable.

This I do not understand. All involved domains have MX records 
pointing at the server's IP address. How could a guessed SPF fail?

> > It's also their customers who do not receive (in my case) mostly 
> > individual messages which are often even expected in advance (like 
> > people asking for a document via SMS, and then they have to wait 
> > hours until it arrives at Gmail).
> 
> Spam fighting is a tradeoff between false positives and false 
> negatives.

While this is true we should still strive to reduce false 
classifications.

What Google/Gmail effectively is doing here is a greylisting with 
delays in the range of several hours. I wonder how efficient this is. 
Anyway, it would be nice if Gmail would at least honor "serious" mail 
servers who do not give up sending the same message for hours, i.e. 
whitelist like typical greylisting implementations do.

Of course, I only know my own servers and networks. It probably looks 
quite different from the other side.

-- 
-- Andreas

   :-)


___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop%0a=01%7c01%7cmichael.wise%40microsoft.com%7cb47e614b62cb4c8cf1c108d32db32d7c%7c72f988bf86f141af91ab2d7cd011db47%7c1=xYHJ7JZluwQOF%2bbhRhJvRGAb02Wfcu4C%2faUYBPywRxc%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Brandon Long]

On Thu, Feb 4, 2016 at 9:13 AM, Andreas Schamanek  wrote:

>
> On Thu, 4 Feb 2016, at 08:19, Franck Martin wrote:
>
> > Have you considered that may be it is not postfix sending these
> > emails from your IP?
>
> Yes, of course. This particular server is not even generating enough
> traffic according to the firewall to qualify as bulk sender. Besides,
> if there was any considerable mail traffic I don't know of its IP
> address would have been blacklisted sooner or later.
>
> On Thu, 4 Feb 2016, at 17:53, Petar Bogdanovic wrote:
>
> > Maybe your ASN is as filthy as the one surrounding my MTA (Hetzner).
> > Gmail seems to score ASNs and rate-limit whole ranges no matter what
> > your MTA does in particular.
>
> That's what I think is the case, indeed. Hetzner is the provider.
>

It is a netblock quota you're hitting, yes.  As we see more and larger hit
and run spam jobs from previously unknown or low volume IPs and netblocks,
the low volume senders are caught in the cross fire.

I'll ping the spam team about the messaging again, saying IP is definitely
wrong there.  And I can ping them about better handling about this, they've
made some improvements recently, but it's a hard problem.

Also, the bulk sender guidelines don't only apply to bulk senders, in
particular, you have no authentication for your messages.  Some of the
messages from that server we're treating as authenticated because of our
best guess for SPF, but that's not really sustainable.


> > gsmtp is still very suspicious of my submissions but at least they
> > don't cut me off for *days* anymore.
>
> Gmail is not just cutting _us_ off. They are cutting themselves off!
> It's also their customers who do not receive (in my case) mostly
> individual messages which are often even expected in advance (like
> people asking for a document via SMS, and then they have to wait hours
> until it arrives at Gmail).


Spam fighting is a tradeoff between false positives and false negatives.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Michael Wise]

It looks like the DKIM bits were added by Gmail.
As to point 4 … Do Not Get Me Started.

Aloha,
Michael.
--
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Thursday, February 4, 2016 1:01 PM
To: Michael Wise <michael.w...@microsoft.com>
Cc: Neil Schwartzman <n...@cauce.org>; mailop <mailop@mailop.org>; Andreas 
Schamanek <scham...@fam.tuwien.ac.at>
Subject: Re: [mailop] Gmail throttles anyway



On Thu, Feb 4, 2016 at 12:32 PM, Michael Wise 
<michael.w...@microsoft.com<mailto:michael.w...@microsoft.com>> wrote:

Authentication-Results: spf=none (sender IP is 213.138.100.131)
smtp.mailfrom=mailop.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmailop.org=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=iQ0ng%2bfgca%2f21J3%2fwVl4ntv8MyU5w4LLy%2furYQWEF3s%3d>;
 
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.com=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=k5UgurRzEm2DGFLWDqpK0OX%2fw3%2bpj%2fneNU4nv3jOktM%3d>;
 dkim=fail (signature did not verify)
header.d=linkedin.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flinkedin.com=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=ZhXTzxK3SIsov6hHYWLCEx1tR7VqbLQcEXnqlrf4SeI%3d>;microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.com=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=k5UgurRzEm2DGFLWDqpK0OX%2fw3%2bpj%2fneNU4nv3jOktM%3d>;
 dmarc=fail action=oreject
header.from=linkedin.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flinkedin.com=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=ZhXTzxK3SIsov6hHYWLCEx1tR7VqbLQcEXnqlrf4SeI%3d>;


Couple of points
1) MLM forward email and add some bits therefore breaks original DKIM 
signature, Well Known problem
2) no SPF for 
https://dmarcian.com/spf-survey/mailop.org<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdmarcian.com%2fspf-survey%2fmailop.org=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=qM7elyItt%2bkOqb9Ur%2bTrPbRMbQST1yIVyaLd%2bRX5tUY%3d>
3) no DKIM 
d=mailop.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmailop.org=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=iQ0ng%2bfgca%2f21J3%2fwVl4ntv8MyU5w4LLy%2furYQWEF3s%3d>
 for this list
4) why 
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.com=01%7c01%7cMichael.Wise%40microsoft.com%7c05576a301a004e5c0cb108d32da648b7%7c72f988bf86f141af91ab2d7cd011db47%7c1=k5UgurRzEm2DGFLWDqpK0OX%2fw3%2bpj%2fneNU4nv3jOktM%3d>
 string is added in your AR header? This is a weird construct

Can we, please, get 2) and 3) fixed?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Franck Martin]

On Thu, Feb 4, 2016 at 12:32 PM, Michael Wise 
wrote:

>
>
> Authentication-Results: spf=none (sender IP is 213.138.100.131)
>
> smtp.mailfrom=mailop.org; microsoft.com; dkim=fail (signature did not
> verify)
>
> header.d=linkedin.com;microsoft.com; dmarc=fail action=oreject
>
> header.from=linkedin.com;
>
>
>

Couple of points
1) MLM forward email and add some bits therefore breaks original DKIM
signature, Well Known problem
2) no SPF for https://dmarcian.com/spf-survey/mailop.org
3) no DKIM d=mailop.org for this list
4) why microsoft.com string is added in your AR header? This is a weird
construct

Can we, please, get 2) and 3) fixed?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Franck Martin]

On Thu, Feb 4, 2016 at 1:02 PM, Michael Wise 
wrote:

> It looks like the DKIM bits were added by Gmail.
>
> As to point 4 … Do Not Get Me Started.
>
>
>
This list is not hosted by Google? So the bits that break DKIM are added by
mailman, and it is a statement not a judgement.

As for 4, why deny so much fun? :P
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[John R Levine]

If it's a mailing list, the traffic is not simply passing thru. Since the 
message is being modified, the signature should at the very least be 
deactivated.


For the third time, why?  The RFC says it doesn't matter.

I believe it goes into the junk, but I don't believe it has anything to do 
with a broken DKIM signature.


R's,
John


If you're going to do something that will break the DKIM signature as a matter 
of course,
You should remove the DKIM signature, and maybe re-sign it with your own.

You shouldn't break the signature and then forward what was once goodmail with 
a now busted signature.


Au contraire.  You should always preserve all the signatures to make it
easier to figure out what happened if there's some sort of trouble down
the line.

Since the spec says that there is no difference in message handling for a
broken signature and one that's not there, could you be more specific
about why you think it's important to make forensics harder?

Signed,
Confused

PS: See RFC 6376, section 6.1:

   Survivability of signatures after transit is not guaranteed, and
   signatures can fail to verify through no fault of the Signer.
   Therefore, a Verifier SHOULD NOT treat a message that has one or more
   bad signatures and no good signatures differently from a message with
   no signature at all.

   ...

   In the following description, text reading "return status
   (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
   means that the Verifier MUST immediately cease processing that
   signature.  The Verifier SHOULD proceed to the next signature, if one
   is present, and completely ignore the bad signature.




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[John Levine]

In article 
 
you write:
>If you're going to run a mailing-list and you don't believe in DKIM ... fine!
>But remove the DKIM headers before resending the traffic, please.

Why?  The DKIM spec is super duper 100% clear that an invalid
signature is the same as no signature.  Any system that scores
against broken signatures is badly broken.

It's not surprising that there are badly broken systems, but please,
let's encourage people to fix what's broken rather than telling them
to apply band-aids.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Michael Wise]

If it's a mailing list, the traffic is not simply passing thru. Since the 
message is being modified, the signature should at the very least be 
deactivated.

Or, as we're seeing, into the Junk it goes.

Aloha,
Michael.
--
Sent from my Windows Phone

From: John R Levine<mailto:jo...@taugh.com>
Sent: ‎2/‎4/‎2016 5:51 PM
To: Michael Wise<mailto:michael.w...@microsoft.com>
Cc: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: RE: [mailop] Gmail throttles anyway

> If you're going to do something that will break the DKIM signature as a 
> matter of course,
> You should remove the DKIM signature, and maybe re-sign it with your own.
>
> You shouldn't break the signature and then forward what was once goodmail 
> with a now busted signature.

Au contraire.  You should always preserve all the signatures to make it
easier to figure out what happened if there's some sort of trouble down
the line.

Since the spec says that there is no difference in message handling for a
broken signature and one that's not there, could you be more specific
about why you think it's important to make forensics harder?

Signed,
Confused

PS: See RFC 6376, section 6.1:

Survivability of signatures after transit is not guaranteed, and
signatures can fail to verify through no fault of the Signer.
Therefore, a Verifier SHOULD NOT treat a message that has one or more
bad signatures and no good signatures differently from a message with
no signature at all.

...

In the following description, text reading "return status
(explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
means that the Verifier MUST immediately cease processing that
signature.  The Verifier SHOULD proceed to the next signature, if one
is present, and completely ignore the bad signature.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Michael Wise]

If you're going to do something that will break the DKIM signature as a matter 
of course,
You should remove the DKIM signature, and maybe re-sign it with your own.

You shouldn't break the signature and then forward what was once goodmail with 
a now busted signature.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: John Levine [mailto:jo...@taugh.com] 
Sent: Thursday, February 4, 2016 5:11 PM
To: mailop@mailop.org
Cc: Michael Wise <michael.w...@microsoft.com>
Subject: Re: [mailop] Gmail throttles anyway

In article 
<by2pr03mb411a879e4d2574379e7e39880...@by2pr03mb411.namprd03.prod.outlook.com> 
you write:
>If you're going to run a mailing-list and you don't believe in DKIM ... fine!
>But remove the DKIM headers before resending the traffic, please.

Why?  The DKIM spec is super duper 100% clear that an invalid
signature is the same as no signature.  Any system that scores
against broken signatures is badly broken.

It's not surprising that there are badly broken systems, but please,
let's encourage people to fix what's broken rather than telling them
to apply band-aids.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Michael Wise]

Concede your point, it was DMARC that said kill it for the LinkedIn.com domain.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: John R Levine [mailto:jo...@taugh.com] 
Sent: Thursday, February 4, 2016 5:59 PM
To: Michael Wise <michael.w...@microsoft.com>
Cc: mailop@mailop.org
Subject: RE: [mailop] Gmail throttles anyway

> If it's a mailing list, the traffic is not simply passing thru. Since the 
> message is being modified, the signature should at the very least be 
> deactivated.

For the third time, why?  The RFC says it doesn't matter.

I believe it goes into the junk, but I don't believe it has anything to do 
with a broken DKIM signature.

R's,
John

>> If you're going to do something that will break the DKIM signature as a 
>> matter of course,
>> You should remove the DKIM signature, and maybe re-sign it with your own.
>>
>> You shouldn't break the signature and then forward what was once goodmail 
>> with a now busted signature.
>
> Au contraire.  You should always preserve all the signatures to make it
> easier to figure out what happened if there's some sort of trouble down
> the line.
>
> Since the spec says that there is no difference in message handling for a
> broken signature and one that's not there, could you be more specific
> about why you think it's important to make forensics harder?
>
> Signed,
> Confused
>
> PS: See RFC 6376, section 6.1:
>
>Survivability of signatures after transit is not guaranteed, and
>signatures can fail to verify through no fault of the Signer.
>Therefore, a Verifier SHOULD NOT treat a message that has one or more
>bad signatures and no good signatures differently from a message with
>no signature at all.
>
>...
>
>In the following description, text reading "return status
>(explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
>means that the Verifier MUST immediately cease processing that
>signature.  The Verifier SHOULD proceed to the next signature, if one
>is present, and completely ignore the bad signature.
>
>

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[John R Levine]

If you're going to do something that will break the DKIM signature as a matter 
of course,
You should remove the DKIM signature, and maybe re-sign it with your own.

You shouldn't break the signature and then forward what was once goodmail with 
a now busted signature.


Au contraire.  You should always preserve all the signatures to make it 
easier to figure out what happened if there's some sort of trouble down 
the line.


Since the spec says that there is no difference in message handling for a 
broken signature and one that's not there, could you be more specific 
about why you think it's important to make forensics harder?


Signed,
Confused

PS: See RFC 6376, section 6.1:

   Survivability of signatures after transit is not guaranteed, and
   signatures can fail to verify through no fault of the Signer.
   Therefore, a Verifier SHOULD NOT treat a message that has one or more
   bad signatures and no good signatures differently from a message with
   no signature at all.

   ...

   In the following description, text reading "return status
   (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
   means that the Verifier MUST immediately cease processing that
   signature.  The Verifier SHOULD proceed to the next signature, if one
   is present, and completely ignore the bad signature.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Franck Martin]

Have you considered that may be it is not postfix sending these emails from
your IP?


On Thu, Feb 4, 2016 at 1:03 AM, Andreas Schamanek  wrote:

>
> We are not forwarding, we are not sending spam, in fact we are not
> even sending bulk mail at all, still we get rate limited by Google.
>
> Strangely enough, right since I verified my domain schamanek.net for
> postmaster.google.com we get rate limited every few days. E.g.
>
>   Feb  2 16:52:04 iac postfix/smtp[7719]: 1A9BB227: host
>   gmail-smtp-in.l.google.com[173.194.65.27] said: 421-4.7.0
>   [188.40.39.209  15] Our system has detected an unusual rate of
>   421-4.7.0 unsolicited mail originating from your IP address. To
>   protect our 421-4.7.0 users from spam, mail sent from your IP
>   address has been temporarily 421-4.7.0 rate limited. Please visit
>   421-4.7.0 https://support.google.com/mail/answer/81126 to review
>   our Bulk Email 421 4.7.0 Senders Guidelines. r17si2803368wjw.232
>   - gsmtp (in reply to end of DATA command)
>
> We are sending on average 15 messages per day to gmail addresses. Our
> total outbound rate is 135/day. I wonder what Google considers an
> "unusual rate of unsolicited mail". Apparently, zero qualifies, too!?
>
> So, good luck to those who, just like me, have spam filters (of
> course) and consider(ed) to add feedback loops, special headers,
> change forwarding to fetching etc., it might not help.
>
> --
> -- Andreas
>
>:-/
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Andreas Schamanek]

On Thu, 4 Feb 2016, at 08:19, Franck Martin wrote:

> Have you considered that may be it is not postfix sending these 
> emails from your IP?

Yes, of course. This particular server is not even generating enough 
traffic according to the firewall to qualify as bulk sender. Besides, 
if there was any considerable mail traffic I don't know of its IP 
address would have been blacklisted sooner or later.

On Thu, 4 Feb 2016, at 17:53, Petar Bogdanovic wrote:

> Maybe your ASN is as filthy as the one surrounding my MTA (Hetzner).
> Gmail seems to score ASNs and rate-limit whole ranges no matter what
> your MTA does in particular.

That's what I think is the case, indeed. Hetzner is the provider.

> gsmtp is still very suspicious of my submissions but at least they 
> don't cut me off for *days* anymore.

Gmail is not just cutting _us_ off. They are cutting themselves off! 
It's also their customers who do not receive (in my case) mostly 
individual messages which are often even expected in advance (like 
people asking for a document via SMS, and then they have to wait hours 
until it arrives at Gmail).

-- 
-- Andreas

   :-|


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Franck Martin]

Neil,

it is even surprising it gets delivered at all...

It is rather funny that this mailing list, does not have SPF nor DKIM.

On Thu, Feb 4, 2016 at 11:10 AM, Neil Schwartzman  wrote:

it may also be content. both franck’s and Andreas’ emails ended up in my
> gmail junk folder.
>
>
>
> On Feb 4, 2016, at 11:19 AM, Franck Martin  wrote:
>>
>>
>> Have you considered that may be it is not postfix sending these emails
>> from your IP?
>>
>>
>> On Thu, Feb 4, 2016 at 1:03 AM, Andreas Schamanek <
>> scham...@fam.tuwien.ac.at> wrote:
>>
>>
>> We are not forwarding, we are not sending spam, in fact we are not
>>
>> even sending bulk mail at all, still we get rate limited by Google.
>>
>>>
>> Strangely enough, right since I verified my domain schamanek.net for
>>
>>> postmaster.google.com we get rate limited every few days. E.g.
>>
>>>
>>   Feb  2 16:52:04 iac postfix/smtp[7719]: 1A9BB227: host
>>
>>   gmail-smtp-in.l.google.com[173.194.65.27] said: 421-4.7.0
>>
>>   [188.40.39.209  15] Our system has detected an unusual rate of
>>
>>   421-4.7.0 unsolicited mail originating from your IP address. To
>>
>>   protect our 421-4.7.0 users from spam, mail sent from your IP
>>
>>   address has been temporarily 421-4.7.0 rate limited. Please visit
>>
>>   421-4.7.0 https://support.google.com/mail/answer/81126 to review
>>
>>   our Bulk Email 421 4.7.0 Senders Guidelines. r17si2803368wjw.232
>>
>>   - gsmtp (in reply to end of DATA command)
>>
>>>
>> We are sending on average 15 messages per day to gmail addresses. Our
>>
>> total outbound rate is 135/day. I wonder what Google considers an
>>
>> "unusual rate of unsolicited mail". Apparently, zero qualifies, too!?
>>
>>>
>> So, good luck to those who, just like me, have spam filters (of
>>
>> course) and consider(ed) to add feedback loops, special headers,
>>
>> change forwarding to fetching etc., it might not help.
>>
>>>
>> --
>>
>> -- Andreas
>>
>>
>>:-/
>>
>>
>>
>> ___
>>
>> mailop mailing list
>>
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>> ___
>>
>> mailop mailing list
>>
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttles anyway

[Brandon Long]

On Thu, Feb 4, 2016 at 12:17 PM, Franck Martin  wrote:

> Neil,
>
> it is even surprising it gets delivered at all...
>

*whistling*

Yeah, I added a personal filter for my account, if list:mailop never spam.

I'm sure ARC will solve all our troubles.

Brandon

It is rather funny that this mailing list, does not have SPF nor DKIM.
>
> On Thu, Feb 4, 2016 at 11:10 AM, Neil Schwartzman  wrote:
>
> it may also be content. both franck’s and Andreas’ emails ended up in my
>> gmail junk folder.
>>
>>
>>
>>
>> On Feb 4, 2016, at 11:19 AM, Franck Martin  wrote:
>>>
>>>
>>> Have you considered that may be it is not postfix sending these emails
>>> from your IP?
>>>
>>>
>>> On Thu, Feb 4, 2016 at 1:03 AM, Andreas Schamanek <
>>> scham...@fam.tuwien.ac.at> wrote:
>>>
>>>
>>> We are not forwarding, we are not sending spam, in fact we are not
>>>
 even sending bulk mail at all, still we get rate limited by Google.
>>>

>>> Strangely enough, right since I verified my domain schamanek.net for
>>>
 postmaster.google.com we get rate limited every few days. E.g.
>>>

>>>   Feb  2 16:52:04 iac postfix/smtp[7719]: 1A9BB227: host
>>>
   gmail-smtp-in.l.google.com[173.194.65.27] said: 421-4.7.0
>>>
   [188.40.39.209  15] Our system has detected an unusual rate of
>>>
   421-4.7.0 unsolicited mail originating from your IP address. To
>>>
   protect our 421-4.7.0 users from spam, mail sent from your IP
>>>
   address has been temporarily 421-4.7.0 rate limited. Please visit
>>>
   421-4.7.0 https://support.google.com/mail/answer/81126 to review
>>>
   our Bulk Email 421 4.7.0 Senders Guidelines. r17si2803368wjw.232
>>>
   - gsmtp (in reply to end of DATA command)
>>>

>>> We are sending on average 15 messages per day to gmail addresses. Our
>>>
 total outbound rate is 135/day. I wonder what Google considers an
>>>
 "unusual rate of unsolicited mail". Apparently, zero qualifies, too!?
>>>

>>> So, good luck to those who, just like me, have spam filters (of
>>>
 course) and consider(ed) to add feedback loops, special headers,
>>>
 change forwarding to fetching etc., it might not help.
>>>

>>> --
>>>
 -- Andreas
>>>

>>>:-/
>>>

>>>
>>> ___
>>>
 mailop mailing list
>>>
 mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>> ___
>>>
>>> mailop mailing list
>>>
>>> mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop