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

[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
Sent: ‎2/‎4/‎2016 5:51 PM
To: Michael Wise
Cc: 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

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

On Thu, Feb 4, 2016 at 3:55 PM, Brandon Long  wrote:

>
>
> On Thu, Feb 4, 2016 at 2:27 PM, Andreas Schamanek <
> scham...@fam.tuwien.ac.at> wrote:
>
>>
>> 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.
>>
>
> If you don't believe in message authentication, you're going to have a bad
> time.
>
> And I didn't talk about dmarc or dnssec, and at the low end, SPF is kind
> of trivial.
>
>

Yes SPF or DKIM on emails is the bare minimum to do for an email
administrator nowadays.

I think the community is starting to treat unauthenticated emails as a
problem.

If you were trying to send over IPv6, unauthenticated emails would go
nowhere.

About email authentication metrics:
https://googleonlinesecurity.blogspot.com/2013/12/internet-wide-efforts-to-fight-email.html

The only thing that may help you in a bad environment is to clearly claim
who you are by authenticating your emails, it is not anymore a question of
belief in a technology, we passed that point a while back.
___
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 
Subject: Re: [mailop] Gmail throttles anyway

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

[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 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 
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&data=01%7c01%7cmichael.wise%40microsoft.com%7cb47e614b62cb4c8cf1c108d32db32d7c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xYHJ7JZluwQOF%2bbhRhJvRGAb02Wfcu4C%2faUYBPywRxc%3d
___
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

[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

[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

[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

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

From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Thursday, February 4, 2016 1:01 PM
To: Michael Wise 
Cc: Neil Schwartzman ; mailop ; Andreas 
Schamanek 
Subject: Re: [mailop] Gmail throttles anyway



On Thu, Feb 4, 2016 at 12:32 PM, Michael Wise 
mailto:michael.w...@microsoft.com>> 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 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

[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

Re: [mailop] Gmail throttles anyway

[Michael Wise]

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;

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

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Franck Martin
Sent: Thursday, February 4, 2016 12:17 PM
To: Neil Schwartzman 
Cc: mailop ; Andreas Schamanek 
Subject: Re: [mailop] Gmail throttles anyway

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 
mailto:n...@cauce.org>> 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 
mailto:fmar...@linkedin.com>> 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 
mailto: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

[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

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

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

[mailop] Gmail throttles anyway

[Andreas Schamanek]

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

Re: [mailop] Barracuda Central

[David Hofstee]

This has started, for me, at the 13th. There is a thread below (from the 21st) 
describing the same issues. I did not get a response either.

They somehow seem to give false positive answers on their DNS when they should 
not (although I cannot verify that). After a timeout of 5 minutes, their TTL, 
everything is normal.


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

Van: mailop [mailto:mailop-boun...@mailop.org] Namens Udeme Ukutt
Verzonden: woensdag 3 februari 2016 17:30
Aan: Ian McDonald
CC: mailop@mailop.org
Onderwerp: Re: [mailop] Barracuda Central

Ian, I second your notion.

I've seen similar over the last few days & at a point thought I was going 
bonkers, but I'm glad to add any useful information if needed.
Udeme

On Wed, Feb 3, 2016 at 11:11 AM, Ian McDonald 
mailto:i...@st-andrews.ac.uk>> wrote:
Hi,

We’re experiencing that barracuda’s BRBL (barracudacentral) is returning 
transient “false positives”. Is there anyone from Barracuda that could contact 
me off-list please? I’ve tried filling in the contact form a few times without 
success.

Thanks

--
ian

___
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