Re: [mailop] GMail Reputation

2016-12-20 Thread Paul Witting 
We are definitely doing this; I just double checked and see it as both a
standalone header and  in each of the DKIM pass statements; its being
injected by our MTA

 

Thank You,

 

Paul Witting

 

Check out our new whitepaper on the Chronicle of Philanthropy!

  7 Basic Concepts of
Online Giving (that you might be missing)

 

  

Paul Witting | Director of IT & CSO | o:703.639.9015 | c:202.255.7311

paul.witt...@bisglobal.com |  
www.charityengine.net

  

 



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] gmail doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread Kurt Andersen (b) 
On Tue, Dec 20, 2016 at 7:20 AM, Al Iverson 
wrote:

>
> In your example - you have two periods in a row. This is widely
> understood to be disallowed.
>
> http://serverfault.com/questions/395766/are-two-
> periods-allowed-in-the-local-part-of-an-email-address


Or just quote the localpart and then (almost) anything goes :-)

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

Re: [mailop] gmail doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread John Levine 
In article  you write:
>I would bet Gmail is behaving correctly

Yup.

>As you can see then you can use dots to separate atoms which in turn are not 
>allowed to include dots. There must be at least a
>single atom character after dot.

If you read the rest of that part of RFC 5321, you can put whatever you want in 
the local-part of
an address if you quote the whole thing, e.g.

>> mail from: <"SRS0=GW..5e=YD=test.pl=test"@example.com>

But I concur with the advice from everyone else to fix his
system so it doesn't generate double dots in the first place.

R's,
John

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

Re: [mailop] gmail doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread James Cloos 
It looks like srs would need to use the 'URL and Filename safe'
alphabet from rfc 4648, with minus and underline for the 62nd and
63rd, to provide an encoded string which all MTAs and MUAs ought
to accept.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

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

Re: [mailop] GMail Reputation

2016-12-20 Thread Vick Khera 
On Tue, Dec 20, 2016 at 11:57 AM, Paul Witting
 wrote:
> Is this the tag you are referring to, if so, what are the other tags?

https://support.google.com/mail/answer/6254652?hl=en

That's the feedback loop. It is based on tags provided in a
"Feedback-ID" header, which you DKIM sign.

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

Re: [mailop] Postmaster contact at orange.fr/wanadoo.fr?

2016-12-20 Thread Karen Balle 
Nic,

Orange has a concurrent connection limit of 3, but some of their MTAs sit
behind a NAT and have multiple external IPs.  We've had to set our
concurrent connections to 1, which has helped immensely.  If that doesn't
work out, drop me a line and I'll see if I can get a better contact for you.

Karen

On Mon, Dec 19, 2016 at 8:22 AM, Webb, Nic via mailop 
wrote:

> Hello:
>
>
>
> I’m trying to reach someone at Orange. Over the last 4 days, we’re seeing
> a significant number of throttling messages (around 300,000 over the last
> 24 hours) like the following:
>
>
>
> 421 mwinf5c07 ME Service refuse. Veuillez essayer plus tard. Service
> refused, please try later. OFR_999 [999]
>
> 421 mwinf5c86 ME Trop de connexions, veuillez verifier votre
> configuration. Too many connections, slow down. OFR004_104 [104]
>
>
>
> We’re doing our throttle back our connections, but it’s at the point where
> I have hundreds of recipients at Orange / Wanadoo domains reaching out to
> us wondering where their transactional mails are – they’re seeing delays of
> over 12 hours.
>
>
>
> Emails to postmaster@ are returning “552 5.2.2 Over quota” which leads me
> to believe my attempts to contact over the weekend are not going through.
>
>
>
> I’ll happily take this conversation off-list. Thanks!
>
>
>
> ---
>
> Nicolas Webb
>
> Email Postmaster
>
> Amazon Simple Email Service (SES)
>
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>


-- 
Love is strong yet delicate.
It can be broken.
To truly love is to understand this.
To be in love is to respect this.
~ Stephen Packer ~
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GMail Reputation

2016-12-20 Thread Paul Witting 
>> Since discovering the issue we've been going over our system with a 

>> fine toothed comb, We generally have SPF and DKIM deployed, and based 

>> on Google's recommendations, DMARC, as well as updating mail headers 

>> to be what seems to be in line with Google's recommendations. We've 

>> also turned our eyes on what is being sent, and found some minor 

>> issues where a small volume of unwanted

> 

> You need 100% DKIM coverage if you want to get mail to inbox at gmail.

> Perhaps rotate out the signing key and make sure *only* your transactional


> mail uses that one specific identifier.

 

We are now double signing emails, signed with the "From:" domain's DKIM and 

our own "Sender" DKIM. Transactional emails are waiting for a code update
that 

will allow them to go out a new mail relay that supports DKIM (the IIS SMTP 

server doesn't support DKIM)

 

> I'll suggest doing some some subject line rewording and possibly re-word
the

> content as well. Since you're sending receipts, that may be a little
tricky.

 

We've tried this, it appears their "domain reputation" is the issue, they
are even 

filtering Test messages

 

> How many IPs are you sending through (does anyone else share them), and 

> what is your volume? Maybe you can segregate the various types of mail to 

> see if one or the other is causing problems. Do you get any reports from
the 

> gmail FBL? You should use one of the 4 tags they allow to identify the
type of 

> mail, if that provides clues.

 

There's no Google FBL we can find. We are setup on the Postmaster 

Tools, but since it seems everything goes to Spam, nobody is flagging 

anything as Spam; catch 22. We are adding a header that should serve

this purpose:

 

Return-Path:
<3ef.1c.271340513-17311346.167049.Witting=gmail@smartmailer.bisglobal.ne
t>

 

And we are using the Precedence: bulk tag for gmail deliveries since we 

started our recovery process since we learned they want it

 

Precedence: bulk

 

Is this the tag you are referring to, if so, what are the other tags?

 

One client is in a dedicated pool of 5 IP's, others are in our general pool

of 10 that is shared among clients. We are starting to try to isolate 

larger clients that are sending a million or more per month. We recently 

tried going to 1 IP and saw a lot of deferrals that prevented getting them 

out in our 1 day window

 

Thank You,

 

Paul Witting



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Earthlink?

2016-12-20 Thread Staudinger, Malcolm 
Replied off-list

Malcolm Staudinger, SSCP
Lead Infosec Analyst
Enterprise Information Security Operations
EarthLink
[http://www.earthlink.net/img/com/email_logo_sm.png]

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Brett Schenker
Sent: Monday, December 19, 2016 11:16 AM
To: mailop@mailop.org
Subject: [mailop] Anyone from Earthlink?

Our range has been listed and they've cited a poor senderbase score, but 
senderbase lists everything as "good." So hoping to chat with someone if 
they're on here. Thanks!
Brett

--
Brett Schenker
Man of Many Things, Including
5B Consulting - http://www.5bconsulting.com
Graphic Policy - http://www.graphicpolicy.com

Twitter - http://twitter.com/bhschenker
LinkedIn - http://www.linkedin.com/in/brettschenker
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Postmaster contact at orange.fr/wanadoo.fr?

2016-12-20 Thread Luke Martinez via mailop 
For what it's worth...Orange.fr and Wannadoo.fr are consistently at the top
of our list for average and median end to end times here at SendGrid. For
the most part, end to end time does seem to scale linearly based on volume
(the more mail you send to them, the longer it takes to deliver), but there
are some outliers which may indicate that reputation has something to with
how much mail they will accept from you per minute/hour/day.


Luke Martinez

On Tue, Dec 20, 2016 at 5:28 AM, Benoit Panizzon 
wrote:

> Hi Nicolas
>
> Orange.fr / wanadoo.fr can be a real pain. Beginning 2015 we started
> seeing more and more spam from their "MAIL-ESSENTIALS-FRANCE" IP
> Ranges.
>
> Their abuse desk never reacted to any complaints. Escalations via
> Orange Switzerland lead to nothing, because the brand 'orange' in
> France apparently had been bought by France Telecom who had nothing to
> do with the rest of the 'Orange' company.
>
> After some analyzing of the amount of spam versus ham from their ranges
> we concluded that 98% spam vs 2% ham, and the fact that their abuse
> desk was obviously deaf, legitimated a full block off their
> mail-platform ip ranges beginning june 2015 via SWINOG Blacklist used
> by many Swiss ISP. This was also announced on the SWINOG Mailinglist.
>
> This had the desired effect. Their customers support got so many
> complaints from their own customers, that after only one week they
> choose to contact us, from their official abuse email address,
> pretending we had never notified them of the problem, which I could
> swiftly prove wrong.
>
> So this is what I found out in contact with their abuse desk:
>
> * The problem began, when they started to offer services under the
>   brand of 'orange.fr' and 'wanadoo.fr' and with IP addresses from
>   their france based email plattform to some bigger ISP in eastern
>   europe who didn't bother about taking actions against abusers.
>
> * They were getting massively flooded by abuse complaints so that they
>   more or less just gave up looking at them and considered it their
>   east Europe wholesale email ISP customers' problem when his service
>   ip addresses on their platform got blacklisted.
>
> We agreed with them, that we lift the block on the whole range and just
> keep blocking the range: 193.252.22.210 to 193.252.22.219 which
> according to them was assigned to the service for the ISP causing all
> that trouble.
>
> So basically yes, they have an abuse email address, but I'm still not
> sure if they read those emails.
>
> Unfortunately none of their emails stated any kind of personal name or
> phone number I could send you off-list.
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



-- 

Luke Martinez
Team Lead | Email Delivery
520.400.5693
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] gmail doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread Al Iverson 
Periods aren't the issue. A single period works just fine.

$ telnet aspmx.l.google.com 25
[...]
mail from:
250 2.1.0 OK g8si23063144wje.166 - gsmtp
quit
221 2.0.0 closing connection g8si23063144wje.166 - gsmtp
Connection closed by foreign host.

In your example - you have two periods in a row. This is widely
understood to be disallowed.

http://serverfault.com/questions/395766/are-two-periods-allowed-in-the-local-part-of-an-email-address

Best regards,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130


On Tue, Dec 20, 2016 at 9:58 AM, Arkadiusz Miśkiewicz  wrote:
>
> libsrs_alt library (used by exim to generate SRS addresses for example;
> copy on https://github.com/LynxChaus/libsrs-alt) has an option:
>
> "
> --with-base64compat
>
> This option alters the behaviour of the base64 encoder built
> in to libsrs_alt to use the non-standard characters '_' and
> '.' instead of '+' and '/'. This move vastly improves the
> compatibility of SRS with MTAs. The option comes highly
> recommended.
> "
>
> which producess addresses like this:
>
> $ srs --alias=example.com --secret=1386 --forward t...@test.pl
> SRS0=GW..5e=YD=test.pl=t...@example.com
>
> (note two dots instead of two slashes; without base64compat option that would 
> be
> SRS0=GW//5e=YD=test.pl=t...@example.com)
>
> but google refuses these claiming that it violates RFC-5321
> (which IMO isn't true as this is valid RFC5321 address)
>
> $ telnet aspmx.l.google.com 25
> Trying 2a00:1450:400c:c0c::1a.25...
> Connected to wr-in-x1a.1e100.net.
> Escape character is '^]'.
> 220 mx.google.com ESMTP ue16si22842569wjb.138 - gsmtp
> ehlo test
> 250-mx.google.com at your service, [2001:67c:267c:1:3::2]
> 250-SIZE 157286400
> 250-8BITMIME
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-CHUNKING
> 250 SMTPUTF8
> mail from: 
> 553-5.1.2 The sender address  is not 
> a
> 553 5.1.2 valid RFC-5321 address. ue16si22842569wjb.138 - gsmtp
>
>
> Can anyone from google take a look at adding dots handling in srs hash?
>
> Thanks,
> --
> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
>
> ___
> 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 doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread Andris Reinman 
I would bet Gmail is behaving correctly

From RFC5321:
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part  = Dot-string / Quoted-string
Dot-string  = Atom *("."  Atom)
Atom= 1*atext

From RFC5322 (as atext is not defined in RFC5321):
atext   =   ALPHA / DIGIT /; Printable US-ASCII
"!" / "#" /;  characters not including
"$" / "%" /;  specials.  Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"

As you can see then you can use dots to separate atoms which in turn are not 
allowed to include dots. There must be at least a single atom character after 
dot.

Best regards,
Andris Reinman


> On 20. dets 2016, at 16:58, Arkadiusz Miśkiewicz  wrote:
> 
> 
> libsrs_alt library (used by exim to generate SRS addresses for example;
> copy on https://github.com/LynxChaus/libsrs-alt) has an option:
> 
> "
> --with-base64compat
> 
> This option alters the behaviour of the base64 encoder built
> in to libsrs_alt to use the non-standard characters '_' and
> '.' instead of '+' and '/'. This move vastly improves the
> compatibility of SRS with MTAs. The option comes highly
> recommended.
> "
> 
> which producess addresses like this:
> 
> $ srs --alias=example.com --secret=1386 --forward t...@test.pl
> SRS0=GW..5e=YD=test.pl=t...@example.com
> 
> (note two dots instead of two slashes; without base64compat option that would 
> be
> SRS0=GW//5e=YD=test.pl=t...@example.com)
> 
> but google refuses these claiming that it violates RFC-5321
> (which IMO isn't true as this is valid RFC5321 address)
> 
> $ telnet aspmx.l.google.com 25
> Trying 2a00:1450:400c:c0c::1a.25...
> Connected to wr-in-x1a.1e100.net.
> Escape character is '^]'.
> 220 mx.google.com ESMTP ue16si22842569wjb.138 - gsmtp
> ehlo test
> 250-mx.google.com at your service, [2001:67c:267c:1:3::2]
> 250-SIZE 157286400
> 250-8BITMIME
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-CHUNKING
> 250 SMTPUTF8
> mail from: 
> 553-5.1.2 The sender address  is not 
> a
> 553 5.1.2 valid RFC-5321 address. ue16si22842569wjb.138 - gsmtp
> 
> 
> Can anyone from google take a look at adding dots handling in srs hash?
> 
> Thanks,
> -- 
> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
> 
> ___
> 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 doesn't accept (incorrectly) SRS hashes with dots inside

2016-12-20 Thread Arkadiusz Miśkiewicz 

libsrs_alt library (used by exim to generate SRS addresses for example;
copy on https://github.com/LynxChaus/libsrs-alt) has an option:

"
--with-base64compat

This option alters the behaviour of the base64 encoder built
in to libsrs_alt to use the non-standard characters '_' and
'.' instead of '+' and '/'. This move vastly improves the
compatibility of SRS with MTAs. The option comes highly
recommended.
"

which producess addresses like this:

$ srs --alias=example.com --secret=1386 --forward t...@test.pl
SRS0=GW..5e=YD=test.pl=t...@example.com

(note two dots instead of two slashes; without base64compat option that would be
SRS0=GW//5e=YD=test.pl=t...@example.com)

but google refuses these claiming that it violates RFC-5321
(which IMO isn't true as this is valid RFC5321 address)

$ telnet aspmx.l.google.com 25
Trying 2a00:1450:400c:c0c::1a.25...
Connected to wr-in-x1a.1e100.net.
Escape character is '^]'.
220 mx.google.com ESMTP ue16si22842569wjb.138 - gsmtp
ehlo test
250-mx.google.com at your service, [2001:67c:267c:1:3::2]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
mail from: 
553-5.1.2 The sender address  is not a
553 5.1.2 valid RFC-5321 address. ue16si22842569wjb.138 - gsmtp


Can anyone from google take a look at adding dots handling in srs hash?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

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

Re: [mailop] GMail Reputation

2016-12-20 Thread Vick Khera 
On Mon, Dec 19, 2016 at 1:27 PM, Paul Witting
 wrote:
> Since discovering the issue we’ve been going over our system with a fine
> toothed comb, We generally have SPF and DKIM deployed, and based on Google’s
> recommendations, DMARC, as well as updating mail headers to be what seems to
> be in line with Google’s recommendations. We’ve also turned our eyes on what
> is being sent, and found some minor issues where a small volume of unwanted

You need 100% DKIM coverage if you want to get mail to inbox at gmail.
Perhaps rotate out the signing key and make sure *only* your
transactional mail uses that one specific identifier.

I'll suggest doing some some subject line rewording and possibly
re-word the content as well. Since you're sending receipts, that may
be a little tricky.

How many IPs are you sending through (does anyone else share them),
and what is your volume? Maybe you can segregate the various types of
mail to see if one or the other is causing problems. Do you get any
reports from the gmail FBL? You should use one of the 4 tags they
allow to identify the type of mail, if that provides clues.

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

Re: [mailop] Postmaster contact at orange.fr/wanadoo.fr?

2016-12-20 Thread Benoit Panizzon 
Hi Nicolas

Orange.fr / wanadoo.fr can be a real pain. Beginning 2015 we started
seeing more and more spam from their "MAIL-ESSENTIALS-FRANCE" IP
Ranges.

Their abuse desk never reacted to any complaints. Escalations via
Orange Switzerland lead to nothing, because the brand 'orange' in
France apparently had been bought by France Telecom who had nothing to
do with the rest of the 'Orange' company.

After some analyzing of the amount of spam versus ham from their ranges
we concluded that 98% spam vs 2% ham, and the fact that their abuse
desk was obviously deaf, legitimated a full block off their
mail-platform ip ranges beginning june 2015 via SWINOG Blacklist used
by many Swiss ISP. This was also announced on the SWINOG Mailinglist.

This had the desired effect. Their customers support got so many
complaints from their own customers, that after only one week they
choose to contact us, from their official abuse email address,
pretending we had never notified them of the problem, which I could
swiftly prove wrong.

So this is what I found out in contact with their abuse desk:

* The problem began, when they started to offer services under the
  brand of 'orange.fr' and 'wanadoo.fr' and with IP addresses from
  their france based email plattform to some bigger ISP in eastern
  europe who didn't bother about taking actions against abusers.

* They were getting massively flooded by abuse complaints so that they
  more or less just gave up looking at them and considered it their
  east Europe wholesale email ISP customers' problem when his service
  ip addresses on their platform got blacklisted.

We agreed with them, that we lift the block on the whole range and just
keep blocking the range: 193.252.22.210 to 193.252.22.219 which
according to them was assigned to the service for the ISP causing all
that trouble.

So basically yes, they have an abuse email address, but I'm still not
sure if they read those emails.

Unfortunately none of their emails stated any kind of personal name or
phone number I could send you off-list.

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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