Re: [mailop] Should I be disappointed with Reflexion?

[Jay Hennigan]

On 4/12/16 1:17 PM, Mark Keymer wrote:

We recently setup our first customer using the encryption aspect with
Reflexion. And for the end-user they have been dealing with bounce backs
from recipients e-mail accounts not liking the e-mail that Reflexion
sends that basically tells the recipients to use a link to go and look
at the encrypted mail.

So I reached out to Reflexion about the issues trying to see if maybe
the template used to notify the recipients could be changed. For example
when sending to
optimum.net you get "smtp; 554 5.7.1 Spam detected by content scanner.
Message rejected." Maybe it is the URL, wording in the e-mail, or
something else.


Do optimum.net users have the ability to whitelist senders? If so this 
might be an option.



At any rate I thought that as Reflexion is who is really sending the
e-mail that they would have a team to reach out to ISP/Email hosters
etc, to work on trying to see about getting those e-mails whitelisted.


How is this being used? If the mail is being sent to those who expect 
it, that's one thing.


If not, then I see two potential problems to this scaling well at all, 
regardless of whether the receiving ISP filters it. As DMARC becomes 
more widespread, this would require that the sender address of the 
Reflexion mail be different from the actual originator.


It also sounds like the recipient is in all cases being asked to click 
on a link in email which is likely to be from an unknown sender (to 
avoid DMARC issues). This is a potential malware vector.


It might be useful for certain specialized applications but it doesn't 
look particularly scalable for general use.


--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

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

Re: [mailop] How long does an IP address take to "Warm up"?

[Luke Martinez via mailop]

To piggy back a bit on what has been said already...

When it comes to gmail. every new "sending resource" requires a new warm
up. From what I have gathered, a "sending resource" is (non-exhaustively) a
new IP address, new SPF domain, or new DKIM domain.

We send a lot of mail from a wide variety of different senders. For what it
is worth, we frequently see significant filtering problems at gmail when
senders modify their DKIM domain. Occasionally even when they follow the
recommended warm up strategy.

We have seen senders drop from +90% inboxing down to single digits over
night after changing nothing but their DKIM domain. Sometimes this involves
simply *adding a subdomain* to their already established DKIM domain.

It is a pretty awkward conversation to have, but we are starting to
strongly discourage senders from making modifications to their DKIM domains
because we have been unable to help good senders inbox on new domains. New
IPs and new SPF (5321.From) domain are much less problematic.


Luke


On Wed, Apr 13, 2016 at 3:19 PM, Franck Martin via mailop  wrote:

> I take the rule of thumb that hotmail/outlook.com does not like more than
> 20% volume changes day over day and week over week. Subscribe to the SNDS,
> and if you see your IPs in the yellow, stop ramping up. All the other
> mailbox providers follow same rules more or less, but this gives you a fair
> control of your ramping up.
>
> On Wed, Apr 13, 2016 at 1:15 PM, Robert Guthrie 
> wrote:
>
>> Wow. Thanks for the really helpful replies List.
>>
>> As of this morning I'm not seeing the delays anymore. The IP has been in
>> use as our main SMTP for 13 days from a cold start.
>>
>> The old, warmed up IP address is long gone - back to the VPS provider. I
>> know now that that was a Rookie mistake - For a long time I was
>> misunderstanding my error messages, and I thought that somehow my old
>> (warmed up) IP address had been blacklisted, but actually I had the Haraka
>> dnsbl plugin enabled, and it was rejecting because my worker dyno on Heroku
>> was blacklisted (I assume for being used to send spam by a previous admin).
>>
>> I have DKIM, SPF, TLS all configured on this instance. I saw delays start
>> out at about 8 hours and reduce to about 40 minutes until they disappeared
>> today.
>>
>> I'm going to publish a blog post about my experiences trying to setup an
>> SMTP using Haraka so hopefully some people can learn from my mistakes.
>>
>>
>>
>>
>>
>> On Thu, 14 Apr 2016 at 07:53 G. Miliotis 
>> wrote:
>>
>>> On 13/4/2016 22:28, Brandon Long via mailop wrote:
>>> > if you have sufficient volume and your mail authenticates and you keep
>>> > the same authentication when switching IPs, then your reputation
>>> > should transfer.
>>> Does this mean having the same DKIM key or something else?
>>>
>>> --GM
>>>
>>> ___
>>> 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
>
>


-- 

Luke Martinez
SendGrid Deliverability Consultant
520.400.5693
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Any Proofpoint contacts here?

[Jim Cheetham]

I'm suffering from a strange recurrent blocking ...

https://support.proofpoint.com/rbl-lookup.cgi?ip=139.80.64.247

As of right now, it says "Most Recently Seen as Spam10/04/2014
23:44:25 GMT " and customers are rejecting our email.

I delisted this yesterday, but it's back, and I can't attempt another
delist within 24h. Also, there's no information about what might really
have happened (like all networks we do occasionally emit spam, and we'd
love to know about it). And that 2014 date worries me.

But as I'm not a Proofpoint customer myself, I can't see any way to raise
this issue. So a contact from Proofpoint would be welcome ... :-)

-- 
Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
✉ jim.cheet...@otago.ac.nz☏ +64 3 470 4670☏ m +64 21 279 4670
⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605


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

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

[Michael Wise]

Hmm…

$ telnet 46.165.222.180 25
Trying 46.165.222.180...
Connected to mx8.antispamcloud.com.
Escape character is '^]'.
220 mx8.antispamcloud.com ESMTP Exim 4.85-98781 Thu, 14 Apr 2016 03:47:59 +0200
HELO *
250 mx8.antispamcloud.com Hello * [*.*.*.*]
MAIL FROM: 
250 OK
RCPT TO: 
451-*.*.*.* is not yet authorized to deliver mail from
451  to . Please try later.
quit

Greylisting?
(You can always check in your logs if you need more details)

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: Wednesday, April 13, 2016 6:42 PM
To: Michael Wise 
Cc: Dickie LaFlamme ; mailop@mailop.org
Subject: Re: [mailop] DMARC record in p=none not receiving aggregate reports to 
RUA

DMARC looks ok:
https://dmarcian.com/dmarc-inspector/chinalovecupid.com

Sometimes it takes more than 24 hours, also make sure the mail system does not 
flag the report as spam (because containing bad IPs)...

On Wed, Apr 13, 2016 at 6:22 PM, Michael Wise 
> wrote:

I see it slightly differently:

$ host -t txt 
_dmarc.chinalovecupid.com
_dmarc.chinalovecupid.com
 descriptive text "v=DMARC1\; p=none\; 
rua=mailto:dm...@chinalovecupid.com"

What’s with the “\” in front of the “;”’s?

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

From: Dickie LaFlamme [mailto:rlafla...@dyn.com]
Sent: Wednesday, April 13, 2016 6:02 PM
To: Michael Wise >
Cc: mailop@mailop.org
Subject: Re: [mailop] DMARC record in p=none not receiving aggregate reports to 
RUA

ha, no worries. That's fair enough. Here's the customers DMARC record.

The domain
​:​
chinalovecupid.com

v=DMARC1; p=none; 
rua=mailto:dm...@chinalovecupid.com

​Again we know that this does not currently have the ​"pct=100" tag, but with 
or without the results have been the same.



Thanks,

  


Dickie LaFlamme / Deliverability Specialist
 +1 603-296-1952
 

On Wed, Apr 13, 2016 at 8:43 PM, Michael Wise  
wrote:
 

… as always, please let us know the customer’s real domain name (or IP address, 
or whatever) when making these 

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

[Franck Martin via mailop]

DMARC looks ok:
https://dmarcian.com/dmarc-inspector/chinalovecupid.com

Sometimes it takes more than 24 hours, also make sure the mail system does
not flag the report as spam (because containing bad IPs)...

On Wed, Apr 13, 2016 at 6:22 PM, Michael Wise 
wrote:

>
>
> I see it slightly differently:
>
>
>
> $ host -t txt _dmarc.chinalovecupid.com
>
> _dmarc.chinalovecupid.com descriptive text "v=DMARC1\; p=none\;
> rua=mailto:dm...@chinalovecupid.com;
>
>
>
> What’s with the “\” in front of the “;”’s?
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Dickie LaFlamme [mailto:rlafla...@dyn.com]
> *Sent:* Wednesday, April 13, 2016 6:02 PM
> *To:* Michael Wise 
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] DMARC record in p=none not receiving aggregate
> reports to RUA
>
>
>
> ha, no worries. That's fair enough. Here's the customers DMARC record.
>
> The domain
>
> ​:​
>
> chinalovecupid.com
> 
>
> v=DMARC1; p=none; rua=mailto:dm...@chinalovecupid.com
>
>
>
> ​Again we know that this does not currently have the ​"pct=100" tag, but
> with or without the results have been the same.
>
>
>
>
> Thanks,
>
> [image: Image removed by sender. Dyn logo, Dyn.com]
> 
>   [image: Image removed by sender.]
> 
>
> [image:
> Image removed by sender. Dyn facebook account]
> 
>
> [image:
> Image removed by sender. Dyn LinkedIn account]
> 
>
> Dickie LaFlamme / Deliverability Specialist
> [image: Image removed by sender.] +1 603-296-1952
>
>
>
> On Wed, Apr 13, 2016 at 8:43 PM, Michael Wise 
> wrote:
>
>
>
> … as always, please let us know the customer’s real domain name (or IP
> address, or whatever) when making these requests.
>
>
>
> Not including that is about on par with the legendary complaints of:
>
>
>
> “ It Doesn’t Work.
>
> “ I Can’t Print.
>
> Etc,
>
>
>
> At some point, we’re going to ask you for it anyway, so best to just
> provide it at the start.
>
>
>
> 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 *Dickie
> LaFlamme
> *Sent:* Wednesday, April 13, 2016 5:28 PM
> *To:* mailop@mailop.org
> *Subject:* [mailop] DMARC record in p=none not receiving aggregate
> reports to RUA
>
>
>
> We have a customer who's setup a DMARC record with the correct TXT record;
> v=DMARC1; p=none; pct=100; rua=mailto:dmarc@"customerspostmaster; after
> waiting the 24 hour period we still did not receive any aggregate reports
> to the mailbox. After some searching we advised the customer to try and
> take out "PCT" as that could possibly have been triggering something to not
> work correctly 

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

[Michael Wise]

I see it slightly differently:

$ host -t txt _dmarc.chinalovecupid.com
_dmarc.chinalovecupid.com descriptive text "v=DMARC1\; p=none\; 
rua=mailto:dm...@chinalovecupid.com;

What’s with the “\” in front of the “;”’s?

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

From: Dickie LaFlamme [mailto:rlafla...@dyn.com]
Sent: Wednesday, April 13, 2016 6:02 PM
To: Michael Wise 
Cc: mailop@mailop.org
Subject: Re: [mailop] DMARC record in p=none not receiving aggregate reports to 
RUA

ha, no worries. That's fair enough. Here's the customers DMARC record.

The domain
​:​
chinalovecupid.com

v=DMARC1; p=none; 
rua=mailto:dm...@chinalovecupid.com

​Again we know that this does not currently have the ​"pct=100" tag, but with 
or without the results have been the same.



Thanks,

[Image removed by sender. Dyn logo, 
Dyn.com]
[Image removed by sender.] 



 [Image removed by sender. Dyn facebook account] 



 [Image removed by sender. Dyn LinkedIn account] 


Dickie LaFlamme / Deliverability Specialist
[Image removed by sender.] +1 603-296-1952

On Wed, Apr 13, 2016 at 8:43 PM, Michael Wise 
> wrote:

… as always, please let us know the customer’s real domain name (or IP address, 
or whatever) when making these requests.

Not including that is about on par with the legendary complaints of:

“ It Doesn’t Work.
“ I Can’t Print.
Etc,

At some point, we’re going to ask you for it anyway, so best to just provide it 
at the start.

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 Dickie LaFlamme
Sent: Wednesday, April 13, 2016 5:28 PM
To: mailop@mailop.org
Subject: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

We have a customer who's setup a DMARC record with the correct TXT record; 
v=DMARC1; p=none; pct=100; 
rua=mailto:dmarc@"customerspostmaster" after waiting the 24 hour 
period we still did not receive any aggregate reports to the mailbox. After 
some searching we advised the customer to try and take out "PCT" as that could 
possibly have been triggering something to not work correctly (shot in the dark 
try).

Then after that attempt and no result I did some more research and found that 
in some instances reports can be huge and up to 10MB and denied by their 
internal servers. We then advised the customer to check their logs to make sure 
mail wasn't getting denied at their gateway. To no avail reports still are not 
being sent.

Has anyone else run into this problem with customers when 

Re: [mailop] TLS verify=FAIL

[Franck Martin via mailop]

Have a look at
https://tools.ietf.org/html/draft-martin-authentication-results-tls-03 may
be jump to the example...

I did not pursue, but many MTA clients are sending the certificates, meant
for receiving email to the server they are connecting too.

You can verify that the certificate is trusted (based on your list of
trusted CAs), but there are no good method to do hostname verification. May
be a FCrDNS would allow you to compare with the DNS names in the
SubjectAltNames of the certificate...

On Wed, Apr 13, 2016 at 4:58 PM, Al Iverson 
wrote:

> Boo @ designing something so that "FAIL is really nothing is to be
> concerned with."
>
> It's the kind of thing deliverability people will now be spending the
> rest of their lives explaining to clients that this big ole FAIL is to
> be ignored.
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
>
> On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard 
> wrote:
> > Hi Robert,
> >
> > I'm one of the developers of Haraka.
> >
> > verify=FAIL simply means that the TLS certificate presented by the peer
> host
> > could not be verified as trusted by a CA.
> > In the case of an MUA (which this appears to be), it would be normal as
> an
> > MUA does not usually present client TLS certificates, so this would
> always
> > be expected to fail verification because we have no certificate to verify
> > against, so I changed this in the latest alpha say verify=NO meaning we
> > couldn't verify the certificate as one wasn't presented.
> >
> > Your logs will provide more information e.g.:
> >
> > haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369]
> [defendermx/tls]
> > secured: cipher=ECDHE-RSA-AES256-SHA38
> > 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer
> > certificate"
> >
> > haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F]
> > [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256
> > version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com"
> organization="Google
> > Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT"
> > fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00
> >
> > In short - it's really nothing to be concerned with.
> >
> > Kind regards,
> > Steve.
> >
> >
> >
> > On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:
> >
> > Hello List,
> >
> > I wonder if someone could tell me about the verify=FAIL messages I'm
> seeing
> > in email headers sent from my SMTP's.
> >
> > Received: from loomio.io (errbit.loomio.org [45.55.128.240])
> >   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
> > 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
> >   envelope-from  (authenticated bits=0)
> >   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384
> verify=FAIL);
> >   Wed, 13 Apr 2016 21:05:59 +
> >
> > If I'm seeing this, is there something I can or should do to resolve
> this?
> > Sometimes I see verify=NO also.
> >
> >
> > ___
> > 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] TLS verify=FAIL

[Al Iverson]

Boo @ designing something so that "FAIL is really nothing is to be
concerned with."

It's the kind of thing deliverability people will now be spending the
rest of their lives explaining to clients that this big ole FAIL is to
be ignored.

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


On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard  wrote:
> Hi Robert,
>
> I'm one of the developers of Haraka.
>
> verify=FAIL simply means that the TLS certificate presented by the peer host
> could not be verified as trusted by a CA.
> In the case of an MUA (which this appears to be), it would be normal as an
> MUA does not usually present client TLS certificates, so this would always
> be expected to fail verification because we have no certificate to verify
> against, so I changed this in the latest alpha say verify=NO meaning we
> couldn't verify the certificate as one wasn't presented.
>
> Your logs will provide more information e.g.:
>
> haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369] [defendermx/tls]
> secured: cipher=ECDHE-RSA-AES256-SHA38
> 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer
> certificate"
>
> haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F]
> [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256
> version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com" organization="Google
> Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT"
> fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00
>
> In short - it's really nothing to be concerned with.
>
> Kind regards,
> Steve.
>
>
>
> On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:
>
> Hello List,
>
> I wonder if someone could tell me about the verify=FAIL messages I'm seeing
> in email headers sent from my SMTP's.
>
> Received: from loomio.io (errbit.loomio.org [45.55.128.240])
>   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
> 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
>   envelope-from  (authenticated bits=0)
>   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL);
>   Wed, 13 Apr 2016 21:05:59 +
>
> If I'm seeing this, is there something I can or should do to resolve this?
> Sometimes I see verify=NO also.
>
>
> ___
> 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] TLS verify=FAIL

[Brandon Long via mailop]

If the server is saying your client connection is verify=FAIL/NO, I would
imagine that means either you have a client certificate that doesn't
verify, or you don't have a client certificate the remote server is being
pedantic about it.

Brandon

On Wed, Apr 13, 2016 at 2:56 PM, Robert Guthrie  wrote:

> Hello List,
>
> I wonder if someone could tell me about the verify=FAIL messages I'm
> seeing in email headers sent from my SMTP's.
>
> Received: from loomio.io (errbit.loomio.org [45.55.128.240])
>   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id 
> 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
>   envelope-from  (authenticated bits=0)
>   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 *verify=FAIL*);
>   Wed, 13 Apr 2016 21:05:59 +
>
>
> If I'm seeing this, is there something I can or should do to resolve this?
> Sometimes I see verify=NO also.
>
> ___
> 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] TLS verify=FAIL

[Robert Guthrie]

Hello List,

I wonder if someone could tell me about the verify=FAIL messages I'm seeing
in email headers sent from my SMTP's.

Received: from loomio.io (errbit.loomio.org [45.55.128.240])
by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
envelope-from  (authenticated bits=0)
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 *verify=FAIL*);
Wed, 13 Apr 2016 21:05:59 +


If I'm seeing this, is there something I can or should do to resolve this?
Sometimes I see verify=NO also.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How long does an IP address take to "Warm up"?

[Robert Guthrie]

Wow. Thanks for the really helpful replies List.

As of this morning I'm not seeing the delays anymore. The IP has been in
use as our main SMTP for 13 days from a cold start.

The old, warmed up IP address is long gone - back to the VPS provider. I
know now that that was a Rookie mistake - For a long time I was
misunderstanding my error messages, and I thought that somehow my old
(warmed up) IP address had been blacklisted, but actually I had the Haraka
dnsbl plugin enabled, and it was rejecting because my worker dyno on Heroku
was blacklisted (I assume for being used to send spam by a previous admin).

I have DKIM, SPF, TLS all configured on this instance. I saw delays start
out at about 8 hours and reduce to about 40 minutes until they disappeared
today.

I'm going to publish a blog post about my experiences trying to setup an
SMTP using Haraka so hopefully some people can learn from my mistakes.





On Thu, 14 Apr 2016 at 07:53 G. Miliotis  wrote:

> On 13/4/2016 22:28, Brandon Long via mailop wrote:
> > if you have sufficient volume and your mail authenticates and you keep
> > the same authentication when switching IPs, then your reputation
> > should transfer.
> Does this mean having the same DKIM key or something else?
>
> --GM
>
> ___
> 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] How long does an IP address take to "Warm up"?

[Brandon Long via mailop]

It's old now, but I think the basics are likely still there:

http://ceas.cc/2006/19.pdf

Brandon

On Wed, Apr 13, 2016 at 12:49 PM, Eric Henson  wrote:

> I think he means Google has a list of domains and they have a score from 0
> to 100 or something like that.
>
> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of G. Miliotis
> Sent: Wednesday, April 13, 2016 2:45 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] How long does an IP address take to "Warm up"?
>
> On 13/4/2016 22:28, Brandon Long via mailop wrote:
> > if you have sufficient volume and your mail authenticates and you keep
> > the same authentication when switching IPs, then your reputation
> > should transfer.
> Does this mean having the same DKIM key or something else?
>
> --GM
>
> ___
> 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] How long does an IP address take to "Warm up"?

[Brandon Long via mailop]

On Wed, Apr 13, 2016 at 12:45 PM, G. Miliotis 
wrote:

> On 13/4/2016 22:28, Brandon Long via mailop wrote:
>
>> if you have sufficient volume and your mail authenticates and you keep
>> the same authentication when switching IPs, then your reputation should
>> transfer.
>>
> Does this mean having the same DKIM key or something else?


It shouldn't require the same key, but the domain should be the same.
Ditto for SPF.  Different sub-domains don't work nearly as well, since
splitting types of mail by sub-domain is common.

If you are, then you should be able to ramp faster.  It's always worth
being careful, of course.

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

Re: [mailop] How long does an IP address take to "Warm up"?

[Eric Henson]

I think he means Google has a list of domains and they have a score from 0 to 
100 or something like that.

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of G. Miliotis
Sent: Wednesday, April 13, 2016 2:45 PM
To: mailop@mailop.org
Subject: Re: [mailop] How long does an IP address take to "Warm up"?

On 13/4/2016 22:28, Brandon Long via mailop wrote:
> if you have sufficient volume and your mail authenticates and you keep 
> the same authentication when switching IPs, then your reputation 
> should transfer.
Does this mean having the same DKIM key or something else?

--GM

___
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] How long does an IP address take to "Warm up"?

[Brandon Long via mailop]

Yes, I need details to be able to investigate.

Yes, some throttles apply to netblocks, but I should point out that
throttles are not "just" a netblock or "just" an IP or domain, we have
hundreds of different throttles depending on many features, and good enough
reputation will exempt you from most of them.  If you're hitting throttles,
either you're basically "unknown" to us, very low volume, or there's a very
good chance the message was going to go to the spam label anyways.

Also, switching IPs shouldn't be hard.. if you have sufficient volume and
your mail authenticates and you keep the same authentication when switching
IPs, then your reputation should transfer.

That said, that's the theory, some of the senders here may have more
insight to how the system actually works in practice since they fight with
it every day.  And, our filter is far from perfect, so happy to investigate
so we can tune it.

Brandon

On Wed, Apr 13, 2016 at 8:42 AM, Paul Kincaid-Smith via mailop <
mailop@mailop.org> wrote:

> Hi Robert,
>
> Gmail's systems are very sensitive to sudden changes. Start with just a
> few/tens of emails the first day and ramp up slowly -- an *order of
> magnitude* at a time. Eventually their machine learning systems will
> discover that recipients want your mail and adjust accordingly.
>
> Paul
>
> On Wed, Apr 13, 2016 at 4:39 AM, Robert Guthrie 
> wrote:
>
>> Hello list,
>>
>> I run a group decision making app. We send about 40,000 transactional
>> emails a day, with very good open rates.
>>
>> I recently setup a new SMTP on a new IP address, emails to Google Apps
>> accounts take a few hours to arrive do to throttling on Google's end. I
>> wish I'd reused the old IP address, because those emails always arrived
>> immediately.
>>
>> After about a week I'm still seeing 1 hour delays on things like password
>> reset emails. How long does this warm up process typically take? Is there
>> anything I can do to reduce the delay time?
>>
>> ___
>> 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 Blacklisting

[Brandon Long via mailop]

We don't just run reputation on IP addresses, the spammer killed the
reputation of any associated domains and such.  Your domain is recovering,
but it can take up to 30 days to fully recover sometimes longer if
people don't mark your mail as not spam.

Though, that's only for the domain you're posting from, without details not
much more I can go on.

Brandon

On Wed, Apr 13, 2016 at 10:48 AM, Franck Martin via mailop <
mailop@mailop.org> wrote:

> And it is not only to Google, many other mail receivers requires SPF or
> DKIM over IPv6.
>
> And if you set up a mail receiver with IPv6, do these requirements too, it
> is an industry best practice (cf M3AAWG.org).
>
> On Wed, Apr 13, 2016 at 2:59 AM, Tony Finch  wrote:
>
>> Thomas Wilhelm  wrote:
>> >
>> > Does anybody have a hint for us, how to fix this problem?
>>
>> To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
>> everything set up to the best anti-spam standards.
>>
>> Tony.
>> --
>> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
>> punycode
>> Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then
>> cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a
>> time.
>> Showers. Good.
>>
>> ___
>> 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 Blacklisting

[Franck Martin via mailop]

And it is not only to Google, many other mail receivers requires SPF or
DKIM over IPv6.

And if you set up a mail receiver with IPv6, do these requirements too, it
is an industry best practice (cf M3AAWG.org).

On Wed, Apr 13, 2016 at 2:59 AM, Tony Finch  wrote:

> Thomas Wilhelm  wrote:
> >
> > Does anybody have a hint for us, how to fix this problem?
>
> To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
> everything set up to the best anti-spam standards.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then
> cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a time.
> Showers. Good.
>
> ___
> 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] How long does an IP address take to "Warm up"?

[Paul Kincaid-Smith via mailop]

Hi Robert,

Gmail's systems are very sensitive to sudden changes. Start with just a
few/tens of emails the first day and ramp up slowly -- an *order of
magnitude* at a time. Eventually their machine learning systems will
discover that recipients want your mail and adjust accordingly.

Paul

On Wed, Apr 13, 2016 at 4:39 AM, Robert Guthrie  wrote:

> Hello list,
>
> I run a group decision making app. We send about 40,000 transactional
> emails a day, with very good open rates.
>
> I recently setup a new SMTP on a new IP address, emails to Google Apps
> accounts take a few hours to arrive do to throttling on Google's end. I
> wish I'd reused the old IP address, because those emails always arrived
> immediately.
>
> After about a week I'm still seeing 1 hour delays on things like password
> reset emails. How long does this warm up process typically take? Is there
> anything I can do to reduce the delay time?
>
> ___
> 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] How long does an IP address take to "Warm up"?

[Al Iverson]

The very rough thought is that it takes about four weeks to warm up a
new IP address. In your case, I think you'd want to split the traffic
50/50 between the old IP address and new one and then it'd be a case
of waiting to see how long before Gmail figured out that the mail
coming from the new IP address is good stuff and thus shouldn't be
subject to delays.

I'd also make sure that the mail passes SPF and is signed with DKIM.
There's a chance that they'll identify the mail as good faster if it
comes in the door with stable, accurate authentication.

I don't know for sure if enabling TLS would make things better, but it
can't hurt, either.

The keys here are: 1. This is annoying, but 2. It is not forever. Keep
your head down and send good mail and it will get better.

If you seed your own Gmail address in sends hourly/every 4 hours/12
hours or daily, then you can pretty easily download that mail with
IMAP or POP3 using something like Fetchmail and then pull the
date/time fields out of the received headers to give you insight into
where the delays are at any given time. I've done this in the past to
troubleshoot internal hop delays at Gmail (a different issue).

Hope that helps.

Cheers,
Al Iverson

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


On Wed, Apr 13, 2016 at 5:39 AM, Robert Guthrie  wrote:
> Hello list,
>
> I run a group decision making app. We send about 40,000 transactional emails
> a day, with very good open rates.
>
> I recently setup a new SMTP on a new IP address, emails to Google Apps
> accounts take a few hours to arrive do to throttling on Google's end. I wish
> I'd reused the old IP address, because those emails always arrived
> immediately.
>
> After about a week I'm still seeing 1 hour delays on things like password
> reset emails. How long does this warm up process typically take? Is there
> anything I can do to reduce the delay time?
>
> ___
> 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] How long does an IP address take to "Warm up"?

[Andreas Schamanek]

On Wed, 13 Apr 2016, at 10:39, Robert Guthrie wrote:

> I recently setup a new SMTP on a new IP address, emails to Google 
> Apps accounts take a few hours to arrive do to throttling on 
> Google's end. ... After about a week I'm still seeing 1 hour delays 
> on things like password reset emails. How long does this warm up 
> process typically take?

Can't say how sensitive Gmail's IP reputation mechs are. However, you 
should be aware of the fact that Gmail also throttles netblocks, cf. 
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2016-February/006928.html
 
Then there's no warm-up.

> Is there anything I can do to reduce the delay time?

Provide us with more details (domain, IP etc.) and what you've already 
done.

-- 
-- Andreas

   :-)


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

[mailop] How long does an IP address take to "Warm up"?

[Robert Guthrie]

Hello list,

I run a group decision making app. We send about 40,000 transactional
emails a day, with very good open rates.

I recently setup a new SMTP on a new IP address, emails to Google Apps
accounts take a few hours to arrive do to throttling on Google's end. I
wish I'd reused the old IP address, because those emails always arrived
immediately.

After about a week I'm still seeing 1 hour delays on things like password
reset emails. How long does this warm up process typically take? Is there
anything I can do to reduce the delay time?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Blacklisting

[Tony Finch]

Thomas Wilhelm  wrote:
>
> Does anybody have a hint for us, how to fix this problem?

To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
everything set up to the best anti-spam standards.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then
cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a time.
Showers. Good.

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

[mailop] Gmail Blacklisting

[Thomas Wilhelm]

Hello List,

We have several issues sending mails to gmail/google over IPv6. 

Background:
We are a local ISP in Germany with about 40,000 private customers. We had a 
spam problem with one of our customers, that burned our IPv6 mailserver 
addresses. This problem has been fixed. We now run an rspamd on our outgoing 
mailservers. 

Problem:
We try to publish new IPv6 addresses on our outgoing mailserver. We started 
with 5% of our outgoing mails over these new addresses and it works like a 
charm. Except for gmail/google. After a few hours/days, they block our mails 
from us with the "likely unsolicited mail" error message. IPv4 works without 
any problems.

Does anybody have a hint for us, how to fix this problem?

Best regards,

Thomas

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