Re: [mailop] Issue with Gmail Postmaster

[Luke Martinez via mailop]

Are you assuming that the bad IPs are the result of senders abusing your
DKIM, or is there something more to this "time to rotate your DKIM keys"
recommendation?

On Thu, Dec 28, 2017 at 8:46 AM, Mohammed Ahmed 
wrote:

> If you are seeing dark red on IP reputation page of GPT and the IPs are
> not yours then it is time to rotate your DKIM keys.
>
> On Thu, Dec 28, 2017 at 10:36 AM, Mark DiMaio via mailop <
> mailop@mailop.org> wrote:
>
>> Google changed something early yesterday afternoon as this was fine up
>> until then.  Observing this across the board here as well.
>>
>>  Mark DiMaio - President
>>   p: 415.935.1051 <(415)%20935-1051>
>>   
>> 
>>
>> On Dec 28, 2017, at 7:28 AM, Chris Nagele  wrote:
>>
>> I can confirm we are seeing the same for most domains. IP reputation
>> is showing many new IPs we don't recognize and domain reputation
>> retroactively changed from being high to medium and even low.
>>
>> --
>> Chris Nagele
>> CTO, Wildbit
>> http://wildbit.com
>>
>> ___
>> 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
>>
>>
>
>
> --
>
> Mohammed Ahmed
> Director, Deliverability
> Phone # 1-877-AWeber-1 ext 813
>
> *https://www.aweber.com/email-automation.htm?utm_source=awemail_medium=email_campaign=awteam_content=awteamsign_automations
> *
>
> ___
> 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] Microsoft FBL Increase

[Luke Martinez via mailop]

Thanks for your time and insights Mihai. Incredibly helpful.

Is it safe to assume that this recipient feedback has always been captured
by Microsoft's reputation systems and the only change is that senders are
now being exposed to it? I'm just trying to gather as many talking points
as I can in preparation for the inevitable conversations around correcting
or banning senders who were previously under our radar... Or even
conversations with good senders who are caught off guard by the increase in
spam reports.

Thanks again for your time.


Luke

On Thu, Dec 14, 2017 at 9:58 AM, Mihai Costea  wrote:

> Hi all,
>
>
> I will try to explain what happened with the Microsoft FBL signal over the
> past year from the Microsoft side.
>
>
> There were three factors at play
>
> a. We slowly transitioned the traffic away from the legacy Hotmail.com
> infrastructure to Office365.  Started moving some recipient domains in
> April and after multiple steps, validations, spam attacks, we completed the
> traffic switch last week.  This transition means some domains were seeing
> the old infra and some the new infra in varying proportions.  Each infra
> has its own specifics and bugs, but all legacy font-doors (mx1.hotmail.com)
> have networking ACLs since Dec 7th.
>
> b. We addressed the lack of ReportJunk UX/buttons in mobile clients by
> enabling "implicit junk reports".  We hooked "move to junk folder" signals
> on the mailbox side (so it works across all clients, including old ones)
> and generate a ARF report on behalf of the user.  Around 55% of consumer
> email sessions are actually on mobile these days.  Hence this provided a
> boost of signals and the quality of the signal is very good actually.
>
> c. Over the past year we had few incidents that caused disruption to the
> feed (I remember some certificate expired, a huge migration of the big data
> platform to Azure Data Lake, other things like that).  Non-emergency
> changes in the service are introduced via gradual deployments, so this was
> the cause of some dips.
>
>
> The good news is that outlook.com service is fully on the modern stack
> and there is visibility in the mobile userbase which actually revealed some
> new sets of campaigns: some (spam) senders use the FBL feed to actually
> prune out the users that provide ReportJunk feedback (in other words
> senders do list cleaning instead of improving their campaigns).
>
>
> Separately, the assumption that ReportJunk only happens from emails in
> inbox is not always true, some users actually reportJunk (if the UX is
> available) also from the junk folder.  Some users even call support "why
> did I get this spam mail in my junk folder" as they want an empty junk
> folder or not having any explicit emails or spoofs, etc.  This is actually
> also good signal as it tells us (and you) that this user really does not
> want that mail.
>
>
> Regards,
>
> Mihai Costea
>
> O365 Information Protection
>
>
>
> Message: 1
> Date: Thu, 14 Dec 2017 11:11:47 +0100
> From: Stefano Bagnara 
> To: mailop 
> Subject: Re: [mailop] Microsoft FBL Increase
> Message-ID:
>  +2p...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 14 December 2017 at 00:06, Chace Barber via mailop 
> wrote:
> > Microsoft recently added the ability to report emails as "junk" in
> mobile devices, something not previously available from them. This is
> resulting in many more users being able to report emails as junk than was
> the case a few months ago.
>
> Can you share more about with app/apps (iOS? Android?) introduced the
> spam button and what release/s did that?
>
> I can't believe this explain the drop we saw the past april and the
> sudden increase we see in the last 2 weeks, but I'd like to
> investigate.
> We have 3-4x FBL than before, if the reason was the mobile spam button
> then it would mean that there are 3x users of the outlook mobile
> application compared to the users of the webmail while our open
> reports give outlook app a very very low share.
>
> Sure this may be one of the causes, but IMHO there is something else
> going on on Microsoft side.
>
> > While getting more complaints may not seem like a good thing this time
> of year, this is an opportunity for senders to get more accurate feedback
> from their subscribers. Listen to what the new mobile users are telling
> you, and you will end up with a more effective email program.
>
> Generating complaints is bad but not receiving notifications for the
> complaints is much worse. So I think we are all happy we finally see
> much more FBL from microsoft. Furthermore receiving FBLs means email
> are delivered to inbox: you don't get abuse reports for email already
> in spam. That's why everyone was concerned with low FBL volumes from
> Microsoft in the past months. I'm surprised to see how many people
> shared this issue but didn't answer 

Re: [mailop] AOL backing up the queue

[Luke Martinez via mailop]

AOL is having some capacity issues today. Didn't hear an ETA or a proposed
fix.

On Mon, Nov 27, 2017 at 2:46 PM, Josiah Ritchie <
jritc...@churchcommunitybuilder.com> wrote:

> It appears that AOL is having some problems right now in other areas
> regarding mail, but I haven't seen any commentary from mail operators yet.
> Anyone else having intermittent ability to send mail to AOL mail servers?
>
> I'm seeing a lot of this in our logs:
> status=deferred (delivery temporarily suspended: conversation with
> mailin-04.mx.aol.com[152.163.0.67] timed out while receiving the initial
> server greeting)
>
> ​Thanks, ​
> Josiah
>
> ___
> 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] FBL drop for Hotmail/Outlook

[Luke Martinez via mailop]

Our FBLs haven't recovered either. Open rates are fine. No other symptoms I
can see. Just ~60-70% fewer spam reports coming in since October 11th.

On Wed, Oct 18, 2017 at 6:31 AM, Alberto Miscia via mailop <
mailop@mailop.org> wrote:

> We didn't see any drop in open rates, not even a slight decrese. Of course
> no peaks in bounces either.
> Starting from lun 16 everything seems back to normal (actually still fewer
> than past peak days but the gap is minimal).
>
> I would appreciate some feedback from Hotmail on this matter.
>
> Alberto
>
>
> 2017-10-18 11:22 GMT+02:00 Stefano Bagnara :
>
>> On 13 October 2017 at 14:57, Alberto Miscia  wrote:
>> > We usually measure open rates in a 24/48hrs timeframe, but we are not
>> seeing
>> > anything strange yet.
>>
>> Is the FBL level back to normal? Did you now have open rates
>> measurement for those days?
>>
>> I should have added that we saw a (yet unexplained) major drop in FBL
>> at the end of May 2017, but no changes recently.
>>
>> Stefano
>>
>> > Alberto
>> >
>> > 2017-10-13 14:08 GMT+02:00 Stefano Bagnara :
>> >>
>> >> Almost constant FBL levels here in the last days.
>> >> Do you see a drop in open rates, too? or just the FBL?
>> >>
>> >> Stefano
>> >>
>> >> On 13 October 2017 at 12:50, Alberto Miscia via mailop
>> >>  wrote:
>> >> > Hi,
>> >> > Is anybody else experiencing a drop in Feedback Loops from Hotmail?
>> >> > Since yesterday (CET time) we are receiving FBLs but 3 times fewer
>> than
>> >> > what
>> >> > it used to be.
>> >> >
>> >> > We don't see any glitch from our side and I don't believe in a sudden
>> >> > spike
>> >> > of "relevancy" across the board :)
>> >> > We are not seeing any increase in bounces/deferrals either.
>> >> >
>> >> >
>> >> > Thanks.
>> >>
>> >> --
>> >> Stefano Bagnara
>> >> Apache James/jDKIM/jSPF
>> >> VOXmail/Mosaico.io/VoidLabs
>> >>
>> >> ___
>> >> 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
Team Lead | Email Delivery
520.400.5693
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] FBL drop for Hotmail/Outlook

[Luke Martinez via mailop]

We are seeing it too. Spam reports about 40% their normal rates starting on
Wednesday.


Luke



On Fri, Oct 13, 2017 at 12:57 PM, Alberto Miscia via mailop <
mailop@mailop.org> wrote:

> We usually measure open rates in a 24/48hrs timeframe, but we are not
> seeing anything strange yet.
>
> Alberto
>
>
> 2017-10-13 14:08 GMT+02:00 Stefano Bagnara :
>
>> Almost constant FBL levels here in the last days.
>> Do you see a drop in open rates, too? or just the FBL?
>>
>> Stefano
>>
>> On 13 October 2017 at 12:50, Alberto Miscia via mailop
>>  wrote:
>> > Hi,
>> > Is anybody else experiencing a drop in Feedback Loops from Hotmail?
>> > Since yesterday (CET time) we are receiving FBLs but 3 times fewer than
>> what
>> > it used to be.
>> >
>> > We don't see any glitch from our side and I don't believe in a sudden
>> spike
>> > of "relevancy" across the board :)
>> > We are not seeing any increase in bounces/deferrals either.
>> >
>> >
>> > Thanks.
>>
>> --
>> Stefano Bagnara
>> Apache James/jDKIM/jSPF
>> VOXmail/Mosaico.io/VoidLabs
>>
>> ___
>> 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
Team Lead | Email Delivery
520.400.5693
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Help with a header.

[Luke Martinez via mailop]

Forgive me Suresh, but I don't follow.

On Thu, Sep 28, 2017 at 8:25 PM, Suresh Ramasubramanian <ops.li...@gmail.com
> wrote:

> Bounce feature in pine / elm / mutt
>
> The strredwolf guy is an antispammer who used to be regular on nanae so
> old fashioned enough to still use this
>
> --srs
>
> > On 29-Sep-2017, at 5:28 AM, Grant Taylor via mailop <mailop@mailop.org>
> wrote:
> >
> >> On 09/28/2017 04:38 PM, Luke Martinez via mailop wrote:
> >> I'm a little confused as to what is going on here.
> >
> > This is probably one of the weirder message traces I've seen.
> >
> >> The message gets delivered to a tagged gmail address, and then it
> somehow ends up getting forwarded from a hetzner IP
> (2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8) using a bogus Return-Path
> (7eb.ckc) to some other gmail address (strredw...@gmail.com  strredw...@gmail.com>).
> >
> > I replied directly with more details.
> >
> > TL;DR:  It looks like something running on tocs-devices.loveatomic.com
> (2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8) received the message from the
> original Gmail mailbox, med.abattouy+f...@gmail.com, and then forwarded
> the message to the second Gmail mailbox, strredw...@gmail.com.
> >
> >> Maybe its late and I'm missing something, but I can't put together a
> reasonable story from this header. Would appreciate any insights.
> >
> > The biggest clue for me was the gap in time stamps, as if something was
> periodically polling the original Gmail mailbox.
> >
> >> Received: from tocs-devices.loveatomic.com (tocs-devices.loveatomic.com.
> [2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8])
> >>by mx.google.com with ESMTP id 68si2589689wmh.87.2017.09.16.05.09.30
> >>for <strredw...@gmail.com>;
> >>Sat, 16 Sep 2017 05:09:30 -0700 (PDT)
> >
> > I'd be curious to know what you find out.
> >
> >
> >
> > --
> > Grant. . . .
> > unix || die
> >
>
> ___
> 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

[mailop] Help with a header.

[Luke Martinez via mailop]

I'm a little confused as to what is going on here.

The message gets delivered to a tagged gmail address, and then it somehow
ends up getting forwarded from a hetzner IP
(2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8) using a bogus Return-Path (7eb.ckc)
to some other gmail address (strredw...@gmail.com).

Maybe its late and I'm missing something, but I can't put together a
reasonable story from this header. Would appreciate any insights.

Delivered-To: strredw...@gmail.com
Received: by 10.13.211.67 with SMTP id v64csp1578955ywd;
Sat, 16 Sep 2017 05:09:30 -0700 (PDT)
X-Received: by 10.223.142.172 with SMTP id
q41mr25943159wrb.106.1505563770783;
Sat, 16 Sep 2017 05:09:30 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1505563770; cv=pass;
d=google.com; s=arc-20160816;
b=oqf7AGGq9c5xUltVWseH9PpIwvs+ly3yUF3I3SoOVsakZMfc1hlrNZjJ12nRkMFd+r

 gYMFJ+SnhEHlTe2yTogORls2mIRvu5y0XyLnRa6LUmZpNQk37wzWEdTy31iA/0vVc/jd

 6fuT0/bdFrdgBHTvNPsur+JmM0dqUKQ2wua5qZ7y0HixS3eNLlepJDx2C/SvSgWWsVIy

 ch/YaQvvLV07xO3q9q04FeKurwce8mfWP9XDWkMdAyHWX2qr0fQUGGrSl1UauBPW3xXU

 TW0x93/axTIe8TIQc5ImbxMTJSDIfbnCFcTzC2SJJZXB2d/1ZqQX1WUJcyWfarbWxQsw
 di2g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=precedence:auto-submitted:mime-version:subject:references:subject
 :in-reply-to:message-id:to:from:date:dkim-signature:dkim-signature
 :arc-authentication-results:arc-message-signature:delivered-to
 :arc-authentication-results;
bh=U9u8dEfDkoBlKA6fKyVsf3b+4qrArPkEiZMXyINS0QE=;
b=D97uS1WNT8sR8WMi0pzCdY5ktQcqkeo4Q0hS4rXOJ1gYlKQhyBAnR/bxc9h0p1t0rQ

 6VeIe52piNVQu/eT4xbL4Yt3OlY7CoMeUtxnduckLDOkTPveN0ODA9KIsh3KP+y3WUDK

 BcAN7gSFLzMjA8iHyEq7F7VcQvNFP79tRYbV9ecW7TcbSxqD8WKxpj1b/Jab7rNHek3e

 GNGnZwSlX423Q/b1GQetDt28EY61BROOO23Fa8m/hMd/LMtBAmEwR8Xq1+rptwWE6pnQ

 7m+Lxjuk+cFoDgaq+N4gdQq0PY36gzDwbSYQmtJs550AeTxU49fZ3b30PqiRq9yVivdz
 AfNw==
ARC-Authentication-Results: i=2; mx.google.com;
   dkim=pass header.i=@atlassian.net header.s=s1 header.b=rJorZKb8;
   dkim=pass header.i=@sendgrid.info header.s=smtpapi header.b=sXsyk6S0;
   arc=pass (i=1 spf=pass spfdomain=201701confluence.atlassian.net
dkim=pass dkdomain=atlassian.net dkim=pass dkdomain=sendgrid.info);
   spf=neutral (google.com: 2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8 is
neither permitted nor denied by best guess record for domain of
ghzfpm9rujlh...@7eb.ckc) smtp.mailfrom=ghzfpm9rujlh...@7eb.ckc
Return-Path: 
Received: from tocs-devices.loveatomic.com (tocs-devices.loveatomic.com.
[2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8])
by mx.google.com with ESMTP id 68si2589689wmh.87.2017.09.16.05.09.30
for ;
Sat, 16 Sep 2017 05:09:30 -0700 (PDT)
Received-SPF: neutral (google.com: 2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8 is
neither permitted nor denied by best guess record for domain of
ghzfpm9rujlh...@7eb.ckc) client-ip=2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8;
Authentication-Results: mx.google.com;
   dkim=pass header.i=@atlassian.net header.s=s1 header.b=rJorZKb8;
   dkim=pass header.i=@sendgrid.info header.s=smtpapi header.b=sXsyk6S0;
   arc=pass (i=1 spf=pass spfdomain=201701confluence.atlassian.net
dkim=pass dkdomain=atlassian.net dkim=pass dkdomain=sendgrid.info);
   spf=neutral (google.com: 2a01:4f8:151:4061:ed1d:9de7:f8b0:95c8 is
neither permitted nor denied by best guess record for domain of
ghzfpm9rujlh...@7eb.ckc) smtp.mailfrom=ghzfpm9rujlh...@7eb.ckc
Delivered-To: med.abattouy+f...@gmail.com
Received: by 10.2.147.10 with SMTP id d10csp348165jah;
Sat, 16 Sep 2017 04:53:54 -0700 (PDT)
X-Google-Smtp-Source:
AOwi7QA5oGbcc+6xoMQ77pYMUUDcuhsXyHeHir9+i7WUYwCT+yAN0fc1MV4em4aNoZdSpmlxwunZ
X-Received: by 10.107.156.21 with SMTP id
f21mr13034587ioe.226.1505562834166;
Sat, 16 Sep 2017 04:53:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1505562834; cv=none;
d=google.com; s=arc-20160816;
b=VffQOX3OB+T9232z9hlpGct1UpRZGdnTWxVr9aPUVszRqVXUBgAhPXWuKs5Z3yu+M+

 w7DxtK/vKA13d4gOa0vTiaVgStavlktzA9MyNzX7k8sCOA5a+kQLXFfZDvTPxGIqg6Xu

 wXEDRe8gXhqkq+bkvGXl8p9qMEIhxtQJ+VGE0o5+JWR2usDVbpuuX46re7Tk9FHP3dKI

 dWLdvQADrvpxetEwY9whU+VXtiKx3P2Lxvwb1Sy/hEFyVQFIa5+dbF1vkK+yRxbsU3Tu

 jpjrzdllOeSKEOBoZhiX+6PUM5+LkO8KfYujuDs01QNy/xq5argr1vM04+BygwixhL4D
 b/mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=precedence:auto-submitted:mime-version:subject:references
 :in-reply-to:message-id:to:from:date:dkim-signature:dkim-signature
 :arc-authentication-results;
bh=U9u8dEfDkoBlKA6fKyVsf3b+4qrArPkEiZMXyINS0QE=;
b=Qio7n36mXzeV20k9M1IRa6jU7TFH/66EqP8ckEw6asR9sb4GG/+/Yhbho4zgFs9mIw

 KBI3hV+8Ebj3C2Poy5TsiFDJFqOHiIEY2HZXeLCzzdHtzss9wkwcMl0MkrGwBYY4Lemv

 ogumdXVhUEwuWPeWfpu1b3Y+9X0TTkbbgHd5+ULWaFVm5wUrONL3Ce4XB4wwBH8j7EGK

 N7Xx0E+25HUmVZKhTlDIMgXc+cHtu/qac2anzsAPhG9mwqsr5OhCUmrV9u95ZfrUorch

 

Re: [mailop] [RFC 2822] RFC Header Line Length..

[Luke Martinez via mailop]

It was definitely the cause of our mysterious DKIM failures. A lot of
receivers add a new line around 998 characters.

On Thu, Aug 10, 2017 at 9:57 AM,  wrote:

> On Thu, 10 Aug 2017 07:57:14 -0700, Michael Peddemors said:
>
> > Seeing more and more cases of this not being honoured..
> > Surprised that there is not more breakage, but noticed that Yahoo's DKIM
> is
> > now one long line, in addition to Microsoft's VERY long header lines..
>
> I wonder if this is the source of some "never did figure it out" DKIM
> breakage?
>
> ___
> 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] SNDS - Low Inboxing

[Luke Martinez via mailop]

I'm not going to pretend I have an easy explanation for every situation
where mail lands in the spam folder. I'm just sharing some experience. I'll
also say, if spam could be identified by just three metrics, ESPs could
just get rid of their compliance teams.


Luke

On Fri, Jun 30, 2017 at 4:27 AM, Stefano Bagnara <mai...@bago.org> wrote:

> On 30 June 2017 at 00:04, Luke Martinez via mailop <mailop@mailop.org>
> wrote:
> [...]
>
>> I've had senders say they remove all non engaged recipients after 7 days
>> and somehow their overall sending volume never changes by more than 1-2%
>> for weeks or months. Pretty miraculous that they are signing up exactly the
>> same number of recipients who happen to fall out of their insanely
>> aggressive seven day engagement window...No spam reports though...High open
>> rates..Low bounces...Bad inboxing. Almost as if receivers have systems
>> designed to catch this kind of thing. :P
>>
>
> "No spam reports, high open rates, low bounces": isn't this a clear signal
> the email is wanted/solicited? Why should a system be designed to "catch
> this"?
>
> Isn't the whole spam/antispam thing about "wanted"/"unwanted" stuff? How
> "high openrates, low bounces and no spam reports" can be compatible with
> "unwanted" stuff?
> - You can get high open rates with unwanted stuff but then you'll get spam
> reports.
> - You can get low spam reports (because no one open or they already
> receive in spam), but then you will get low open rates.
>
> The only "matching" behaviour I can think is "wanted but not so
> interesting" emails and an antispam that looks at the "skimmed" emails: you
> get a lot of opens but then the emails are only shown for 1 seconds and
> then deleted. They don't mark them as spam, but they don't engage/don't
> reply/don't keep the email for later. Maybe Microsoft track this "negative"
> signal, and use it a lot, while this signal is not exposed in SNDS data.
>
> AFAIK no big provider ever published they track "skimming/trashing"
> behaviour in their antispam strategy, but this could be a very good
> "weapon", generally speaking, and this could lead to the above case (high
> opens, no abuses, no bounces, but considered spam... because
> skimmed/trashed more than expected). But how can an MTA on the "sender
> side" correctly do outbound antispam in absence of data to detect what is
> spammy and what is not?
>
> Once you get "Bad inboxing" you will not be able to do high open rates any
> more: most recipients doesn't even know they have a "spam" folder that
> could contain false positives unless you tell them to look there.
>
> Stefano
>
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
>
> ___
> 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] SNDS - Low Inboxing

[Luke Martinez via mailop]

>
> The sender also has some methods of list cleaning and regularly pulls
> unengaged contacts out of the contact list after a few deliveries.


I hear this wayyy more than I wish I did...It is always a red flag for me.
If you're in a position where it is necessary to remove a recipient after
just a few deliveries, there is a serious problem with address collection
and mail quality. Inbox providers say something like, "Remove non-engaged
recipients after 6 months." Some senders interpret this as, "If 6 months is
good, 6 days must be great!"

I've had senders say they remove all non engaged recipients after 7 days
and somehow their overall sending volume never changes by more than 1-2%
for weeks or months. Pretty miraculous that they are signing up exactly the
same number of recipients who happen to fall out of their insanely
aggressive seven day engagement window...No spam reports though...High open
rates..Low bounces...Bad inboxing. Almost as if receivers have systems
designed to catch this kind of thing. :P


Luke

On Thu, Jun 29, 2017 at 2:52 PM, Steve Atkins  wrote:

>
> > On Jun 29, 2017, at 1:23 PM, Chris Truitt  wrote:
> >
> > Hi Laura,
> >
> > Thanks for your feedback.
> >
> > The email volume overall is not that high. There are many sends in the
> low thousands, some in the low hundreds. It's actually rare to see a single
> delivery to a group of contacts that exceeds 10k. The list is comprised of
> a great deal of hcp (healthcare practitioner) addresses, hospital and
> clinic addresses. Turnover is also a factor that can lead to recycled spam
> traps. I believe that attrition among residents is in part the reason that
> some specialists will use their freebee addresses rather than a hospital or
> some other clinic domain address.
> >
> > The sender also has some methods of list cleaning and regularly pulls
> unengaged contacts out of the contact list after a few deliveries. In our
> world confirmed/double opt-in is a good way to reduce complaints and trap
> hits, but that is a really, really tough sell. Most marketers expect to
> lose over 50% of sign ups. I'm totally with you on this, I just haven' been
> able to sell it.
>
> I don't think Laura mentioned double opt-in (and it's not an approach I'd
> generally suggest blindly applying).
>
> >
> > Smart Screen is about how your recipients are reacting to the message.
> The actual recipients receiving the mail. Not test panels, not trap
> accounts but based on how your recipients are acting with the mail that you
> are sending them. So the folks who are getting the mail from Merck don’t
> want it and Hotmail is reacting to that and filtering based on that. Fix
> the “wantedness” of the mail first.
> >
> > So we know complaints isn't and has never really been an issue. The
> wantedness doesn't seem to be a problem with any other top ISP.
> > How much of a factor is engagement with Smart Screen? Are they
> approaching Gmail levels of sophistication?
> >
> > During the two week stretch of engagement concentration we saw opens
> from 8 - 11%. The tricky part is expanding the list to good and interested
> contacts that have experienced bulk folder placement and probably aren't
> checking the spam folder.
>
> MailChimp's released benchmarks for open rates to their customer's
> subscribers is in the 20-25% range for quality content. Pharmaceuticals:
> 20%, Business or Professional Services: 21%.
>
> Vitamin Supplements: 17%. Even "Daily Deals" open rates hover above 15%.
> Average.
>
> The open rates you're seeing aren't yelling "engaged customers who asked
> for and want to receive your content!" to me. I'd dig further into where
> your clients got these addresses.
>
> Cheers,
>   Steve
>
>
> ___
> 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

[mailop] Juno/UOL Contact?

[Luke Martinez via mailop]

Anyone happen to have a contact at Juno/United Online?

A sender of ours has an Amazon EC2 IP address in a Received Header and the
United Online Feedback Loop is sending abuse reports to EC2. Causing quite
a headache. Trying to determine if this is normal behavior.

Here's a copy of the abuse report and a header of the message that
apparently triggered it.

Hello,

You have outstanding reports against your EC2 instance(s) and we are
notifying you that we have investigated and observed abusive activity. We
last contacted you about this on May 8th and have not received a reply.
Details of the implicated instance(s) are below:

Reported activity: Email Spam
Instance ID: i-00068357cba6bd893
AWS ID: 375581654504

Please review these reports and respond with details of the action(s) you
have taken to stop the abusive activity. If you do not consider the
activity detailed in these reports to be abusive, please let us know why.
The original reports are included at the end of this email for your
convenience.

Please note that your reply is required within 48 hours. According to the
terms of the AWS Customer Agreement (http://aws.amazon.com/agreement/), if
your instances continue to violate AWS's Acceptable Use Policy (
http://aws.amazon.com/aup/), we may take action against your resources or
account to stop the abusive activity, including suspension or termination
of your AWS account.

Please remember that you are responsible for ensuring that your instances
and all applications are properly secured.

Regards,
AWS Abuse

Case Number: 10022499761

--Beginning of forwarded report(s)--

An Automated Feedback Report was received, indicating you were likely
sending spam.
The report and the spam emails follow.

Arrival-Date: 8 May 2017
Source-IP: 52.200.251.210
Version: 1.0
User-Agent: UOL Feedback Loop 1.0
Feedback-Type: abuse

Received: from outbound-bu1.vgs.untd.com (supportmail01.vgs.untd.com
 [10.181.43.21])
by spamdesk02.vgs.untd.com with SMTP id AABNTBAERAR9EPJ2
for (eow-s...@livespamdesk.prod.untd.com) (sender (
scanmail_failu...@mua.nyc.untd.com));
Mon, 8 May 2017 07:28:31 -0700 (PDT)
Received: (qmail 6833 invoked by uid 514); 8 May 2017 14:28:31 -
X-Issue-Tag: .catch_spam_mail
Delivered-To: xxx
Received: from outbound-mail.vgs.untd.com (webmail10.vgs.untd.com
 [10.181.12.150])
by supportmail01.vgs.untd.com with SMTP id AABNTBAC5AL2N862
for (spamdesk-s...@support.juno.com) (sender );
Mon, 8 May 2017 07:27:39 -0700 (PDT)
X-EOW-USER-IP: 108.184.125.235
Received: from mx09.vgs.untd.com (mx09.vgs.untd.com [10.181.44.39])
by maildeliver10.vgs.untd.com with SMTP id AABNTA2JSAFVG7US
for (sender (bounces+3446560-c1ed-meyerl1=juno@email.tumi.com));
Mon, 8 May 2017 05:14:08 -0700 (PDT)
Authentication-Results: mx09.vgs.untd.com; DKIM=PASS
Received-SPF: Pass
Received: from o1678947x49.outbound-mail.sendgrid.net (
o1678947x49.outbound-mail.sendgrid.net [167.89.47.49])
by mx09.vgs.untd.com with SMTP id AABNTA2JRASZGR5J
for (sender (bounces+3446560-c1ed-meyerl1=juno@email.tumi.com));
Mon, 8 May 2017 05:14:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=tumi.com;
h=content-type:from:mime-version:subject:to; s=s1;
bh=kjj4EgQlYTUyMDWTZRx03kEKFN4=; b=KaXGmwxDh0tBNyEQZO5nkEfUE+G1p
3KZx9r7zWX5XFxThjfm6lvtus2l7yHlHGshA8o2bbxbNum4suZU27LTgcUpH3NM4
nL99wiOghpN4ycme+fyE3u3kEV0AD+i4uzOM+XuP3rntv8modZw0/Lk9QNsrqXX+
Ae+4p7BtDh7pHQ=
Received: by filter0471p1mdw1.sendgrid.net with SMTP id
filter0471p1mdw1-1576-59106096-5D
2017-05-08 12:12:06.889869039 + UTC
Received: from MzQ0NjU2MA (ec2-52-200-251-210.compute-1.amazonaws.com
 [52.200.251.210])
by ismtpd0005p1iad1.sendgrid.net (SG) with HTTP id ObvsyN0QT3aKB88L3WUhHw
for (t...@email.tumi.com); Mon, 08 May 2017 12:12:06.864 + (UTC)
Content-Type: multipart/alternative;
boundary="401124c35832be06b345fa59ee39dfcbc3863ba0b94730e9911370b78f20"
Date: Mon, 8 May 2017 12:12:06 +
From: TUMI (t...@email.tumi.com)
MIME-Version: 1.0
To: X
Message-ID: (obvsyn0qt3akb88l3wu...@ismtpd0005p1iad1.sendgrid.net)
X-SG-EID: iruQ7O2ruqJCFfv2S7xGeUWsPUhiQIIsuEqLV32eZcu6gxlVoj2WJhQK6zVR
L5AMbOutkYirDr6uRU
J6wcJEzrVv1TjQbOVxec8SWx1n1Ub/cQZTgR8+GvVhUuWTqsGbSsrdIfl7xsbmaemtbC
8zgn3OsFzj
NZPvZdA5elYB/LuPuYvBg8JLA02n/1EW0UCFL5hjFuU7UwL68ZlAjlsJ1A==
X-SG-ID: peAnPsQhEI4avR03XD4uFeINL/6t6hqqgGVECEYWmIxVCvpQrbja0HB/
g4p0Rk2qJ4WKE0EzCvVTo6
ZO/MHyKUL3Kb/GGPgLxmiClu4rBpHcnB5vR7hF8RiRxFA7yKPmG9GaBDzJAA+R8Cm+
EJNEI41JX4V6
frdiRgT24rpNoT/buKTTLtfzYpXXHdsrqIgNiz0w5cblxbJX+xpm+
DLrrmZatBlznKj1W7Ui3bVoDn
p5Tc7fBwVYEgH0MBBg/NEc0xHrIoYKoLZMQvgQ41J/mNWmqI3Ldmq7fM8iEpbZLpgNYsgJlk
1onujF
UnUJP24PMvD6e8aRYeLIJI3EXSY2xneFwP+SuZ2/ttqNSpLHQhQrH5KgwyOhngGE/iei+
jppBvbBJE
wC9xUSgaF1znPPJQ==
X-UNTD-BPF: 0537efcf9f2ebe9fbb139babaa13d3371adeaade07df1adb13fab73acaaa
cb8aca93dffa37fb732a9f935e33939a5f0f6e5fce7aa357d70f7a7f
X-UNTD-BodySize: 110971
X-UNTD-SPF: Pass
X-UNTD-DKIM: PASS
X-ContentStamp: 3:5:235755003
X-MAIL-INFO: 05373313377ebb77af137e2a2aaf7afb2ee3aabadb97a73b0ede875afabb

Re: [mailop] Do we need a new list for reporting spam? (Was Re: Admin: This is not a place to report Spam. )

[Luke Martinez via mailop]

Isn't this why abuse desks exist? I know its sometimes fun to broadcast
this stuff in a public forum, but if an abuse desk isn't responsive a
friendly ping to this list (or others like it) generally does the trick.
Something like: "Hey! I would love to chat to someone at [insert ESP here]!
Ping me off list!"


On Sun, Apr 9, 2017 at 11:03 AM, Anne P. Mitchell, Esq.  wrote:

>
>
> > A reminder that this is not the correct forum to report spam. This is
> not even the correct forum to report that your previous complaints didn't
> work.
> >
> > There are other forums (I assume, let me know what they are and we'll
> list them somewhere, or start your own) for this.
> >
>
> This brings up a good point...back in 'the day' folks would report spam on
> NANAE;  is there a managed, moderated mailing list to report spam, that has
> the main ESPs and such on it?
>
> If not, would folks like ISIPP to create one? :-)
>
> Anne
>
> Anne P. Mitchell,
> Attorney at Law / Legislative Consultant
> CEO/President,
> SuretyMail Email Reputation Certification and Inbox Delivery Assistance
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
>
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Member, Board of Directors, Asilomar Microcomputer Workshop
> Member, Board of Directors, Greenwood Wildlife Rehabilitation
> Former Chair, Asilomar Microcomputer Workshop
> Ret. Professor of Law, Lincoln Law School of San Jose
>
> Available for consultations by special arrangement.
> amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
> ___
> 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] Another AOL outage?

[Luke Martinez via mailop]

Not seeing anything here.

On Wed, Apr 5, 2017 at 11:51 AM, Michael Rathbun  wrote:

> Clients are reporting massive unsubscribes due to bounces, where accounts
> are
> known to be valid and active.
>
> mdr
> --
> There's a funny thing that happens when you know the correct
> answer.  It throws you when you get a different answer that
> is not wrong.-- Dr Bowman (Freefall)
>
>
> ___
> 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] SendGrid, can you alert intuit customer regarding sending their invoices?

[Luke Martinez via mailop]

Replied.

On Fri, Mar 31, 2017 at 6:54 PM, Spam Auditor 
wrote:

> From: "Customer Name" 
>
> host notification.intuit.com
> (No A or MX Records)
>
> This will quickly get their messages marked as spam..
>
> (NOTE: These are valid invoices, I am sure their customers want them
> delivered)
>
> (Seemed like an appropriate post for the list on a Friday, and a reminder
> to other ESPs)
>
>
> ___
> 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] Curious: Strange NDRs from gmail.

[Luke Martinez via mailop]

Super helpful. Thanks.

This may be a stupid question, but can you help me understand what
"Remote-MTA" means in this context? I'm a little confused as to how that
works.

On Thu, Feb 23, 2017 at 2:04 PM, Brandon Long <bl...@google.com> wrote:

>
>
> On Thu, Feb 23, 2017 at 12:00 PM, Aaron Richton <rich...@nbcs.rutgers.edu>
> wrote:
>
>> On Thu, 23 Feb 2017, Luke Martinez via mailop wrote:
>>
>> Some G Suite domains are returning this response to us long after the
>>> messages are delivered. More of a curiosity than anything else. Wondering
>>> if anyone has seen this behavior before.
>>>
>> [...]
>>
>>> Reporting-MTA: dns; googlemail.com
>>> Received-From-MTA: dns; bounces+2323606-70a0-ccrawford=
>>> spotsylvania.k12.va...@sendmail.joezooapp.com
>>> Arrival-Date: Wed, 15 Feb 2017 05:45:07 -0800 (PST)
>>> X-Original-Message-ID: <EFwvC250TXmBEZae6eaHrw@ismtpd
>>> 0005p1iad1.sendgrid.net>
>>>
>>> Final-Recipient: rfc822; ccrawf...@spotsylvania.k12.va.us
>>> Action: failed
>>> Status: 4.4.2
>>> Remote-MTA: dns; 205.174.120.102 (205.174.120.102, the server for the
>>> domain.)
>>> Diagnostic-Code: smtp; read error: generic::failed_precondition: read
>>> error (0): error
>>> Last-Attempt-Date: Wed, 22 Feb 2017 09:37:18 -0800 (PST)
>>>
>> [...]
>>
>> It sounds like this is a generic "they didn't talk the protocol I wanted"
>> from the G Suite MTA (which presumably is trying to forward/cc/etc. from
>> b...@google.hosted.us --> onpremises@[205.174.120.102] living under
>> spotsylvania.k12.va.us.)
>>
>> Seeing that a connection to 205.174.120.102:25 smells like a PIX, it's
>> quite likely that Google is getting some awful Ciscoized SMTP, which may
>> indeed not be the protocol they want.
>>
>> If you have available bandwidth to Fix The World, pinging
>> spotsylvania.k12.va.us to check their SMTP logs (especially at any
>> middleboxes in the way) might be enlightening. Or in the event my crystal
>> ball is fully functional today just point them to:
>>
>> https://community.spiceworks.com/how_to/42809-cisco-asa-disa
>> ble-smtp-fixup-in-asdm
>
>
> Yeah, that error from us basically means that the remote server hung up
> while we were waiting for data.
>
> And yeah, they get a bunch of errors every day for that, you could try
> mailing postmas...@spotsylvania.k12.va.us
>
> Brandon
>
>


-- 

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

[mailop] Curious: Strange NDRs from gmail.

[Luke Martinez via mailop]

Some G Suite domains are returning this response to us long after the
messages are delivered. More of a curiosity than anything else. Wondering
if anyone has seen this behavior before.

The response is *"smtp; read error: generic::failed_precondition: read
error (0): error"*

Full NDR below.

Received: by mx0029p1mdw1.sendgrid.net with SMTP id FEhZsVcJlh
Wed, 22 Feb 2017 17:37:19 + (UTC)
Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com
[209.85.128.194])
by mx0029p1mdw1.sendgrid.net (Postfix) with ESMTPS id 06D85C7600
for ; Wed, 22 Feb 2017 17:37:19
+ (UTC)
Received: by mail-wr0-f194.google.com with SMTP id 89so1263655wrr.1
for ; Wed, 22 Feb 2017 09:37:18
-0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20161025;
h=from:to:auto-submitted:subject:references:in-reply-to:message-id
 :date;
bh=B0cmoangnsylEsMJDMxBlX4oxo/fpDc7NERzYdaQr9o=;
b=GZA2TY4bFLkaniFZHzrbJ8Jg2LJbU5NfRIBvq92ObxEPlR5lnc5iR3fxEfSml1rJQi

 RZcGsY4TOCfLmaM3xNvRZq31FkPc3pjdtFJO3OWC8jkojp81tCZi6uaTg++yRl6Ft19H

 znkXQAI5sKxioxbD2YjIF/aiqFw0UhV3v6710LOPYrKTXsBPhKuv2ZNPm4SaWUx8qO2z

 9+hykDPs5AxF400VxeYEiimrJFKBbrgkQxp8SDMpbq614yWWMsPMXStfNuipFEkX6+W3

 uClRkxw7CaIIrv705ne1npP/WJLRmNdfSHd3FhDVsgPqWY9j2HgTNCWKLf4v5reOOJ7K
 z19g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:auto-submitted:subject:references
 :in-reply-to:message-id:date;
bh=B0cmoangnsylEsMJDMxBlX4oxo/fpDc7NERzYdaQr9o=;
b=poLW6hXs2ZKttwHgwPlWOXvapEDPvVAJE5YnwpOHsEXxoPzKwcPJ3nXzURPtqFEDum

 EfVbbPzZJSMpVz9WEB7Tny1f7IL9+OFBSOviI9pnj5OL8eb5ffbIZzBnzsx9Ih7LOHlH

 WZL1Ov/bSitq8Y6mpIuuHnh+oY4rgIyjp/yQ15AQaEAzqy4R4EFZEJkmUFe8hg2zKp7a

 tNLAjkT0BH291eAixeWWOC9GtbUXNReV3ICJ+hoA+F2ihaxztBDJ+gn3+x6q5I0lTXPs

 Un17hR4atSSVFQSZUUhPB9yQBarnFFvROujdUePCInB+0upwXnDjNiLNVhGuXp+odRIN
 CssA==
X-Gm-Message-State:
AMke39m79nSUm0eGsGK6JcYg5xhA67ast26z/+cOYVInQzT1usCxBmt4PMkogEMvl04A3GfNU+kTu7wvhi2LccezIPzNUO7b58Siehc=
X-Received: by 10.223.150.209 with SMTP id
u75mr8559788wrb.195.1487785038064;
Wed, 22 Feb 2017 09:37:18 -0800 (PST)
Content-Type: multipart/report; boundary=f403045f5148b2244b054921f209;
report-type=delivery-status
Received: by 10.223.150.209 with SMTP id u75mr9206430wrb.195; Wed, 22 Feb
2017
 09:37:18 -0800 (PST)
From: Mail Delivery Subsystem 
To: bounces+2323606-70a0-ccrawford=
spotsylvania.k12.va...@sendmail.joezooapp.com
Auto-Submitted: auto-replied
Subject: Delivery Status Notification (Failure)
References: 
In-Reply-To: 
Message-ID: <58adcc4e.d196df0a.dbbb6.d348.gm...@mx.google.com>
Date: Wed, 22 Feb 2017 09:37:18 -0800 (PST)

Content-Type: message/delivery-status

Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; bounces+2323606-70a0-ccrawford=
spotsylvania.k12.va...@sendmail.joezooapp.com
Arrival-Date: Wed, 15 Feb 2017 05:45:07 -0800 (PST)
X-Original-Message-ID: 

Final-Recipient: rfc822; ccrawf...@spotsylvania.k12.va.us
Action: failed
Status: 4.4.2
Remote-MTA: dns; 205.174.120.102 (205.174.120.102, the server for the
domain.)
Diagnostic-Code: smtp; read error: generic::failed_precondition: read error
(0): error
Last-Attempt-Date: Wed, 22 Feb 2017 09:37:18 -0800 (PST)

--f403045f5148b2244b054921f209
Content-Type: message/global

X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed;
d=3D1e100.net; s=3D20161025;

h=3Dx-gm-message-state:dkim-signature:date:from:mime-version:reply-to

:subject:to:message-id:list-unsubscribe;bh=3DfbWHX1f2LgX0kUDf0h/X769JommLTchIDXS53Ifa4oI=3D;b=3DVyhyoIE31tLKVwl7VNI+X+qcGv79/BKb0hT5tqG0PdXAWFajodnfjiOrDrnh7PR=
IhRqu8KuK+X6EaKMPGy0ND31sVv+kDkskAnMBY/8mDKQXuoTEOwP8tMgcM7KooJOaW9Kf=
YLt5cJ9vs2xVPodRX3rH1JBjhqFCrSEj8tStIngV9ttalXjZWm6VGV1WKd0cs6aRtxu1amrGqWcOZ5IG7mo1z+UXDuF5ilYiFYKhk2HaMdad1TMK3jrVqEtFZrSittVQXIlPHFKUYh+Zw4cwxA3f5FYR8V5lXJX6Hd7NewK5MCbSoP2SaCJQ1nR3DeS62LLn/V3GiZltIcoAymGadw=3D=3D
X-Gm-Message-State:
AMke39nLS1e8AbpklUtw/OQhEZjdw565qNkV71VXh5C/GS5RukPBFAWFe4epFH9ZfC66jn2wbiRXiXoVtPW2Hq2u9AxC8G0lM+HAIuIfC99TJ4UjPRnOQCh2UpMR9/hxXgQ9IrJ9bz8yWwkYzd4thYl6PwCBJPprB9QSJaK5xJPSN7jI1OfhnoMaaFkJRnAf+2BYNgjKoSspjoY5H7W8B7pepRm6kp8Mxw=3D=3D
X-Received: by 10.223.133.68 with SMTP id 62mr2251926wrh.195.1487166309125;
Wed, 15 Feb 2017 05:45:09 -0800 (PST)
X-Received: by 10.223.133.68 with SMTP id 62mr2251849wrh.195.1487166307990;
Wed, 15 Feb 2017 05:45:07 -0800 (PST)
Return-Path: 
Received: from o1.30nn.fshared.sendgrid.net 

Re: [mailop] How does Sendgrid validate customers (Swisscom Invoice Incident)?

[Luke Martinez via mailop]

If you can post some headers, I can likely tell you how this sender got
onto our system and how quickly they were shut down. I am certain they
didn't tell us "Hey, we are Swisscom."


Luke

On Thu, Feb 16, 2017 at 1:37 AM, Benoit Panizzon 
wrote:

> Hi all
>
> I am wondering how such an incident could happen.
>
> Yesterday several of our customers (and also several of our support
> contact email addresses) got very carefully crafted and very authentic
> looking fake email invoice notifications from Swisscom.
>
> The 'online invoice' link points to a file containing malware. A
> warning has been issued via the medias in switzerland, to inform the
> population not to download that invoice which a swisscom customer can
> hardly distinguish from a real one.
>
> Obviously sendgrid got abused in several ways:
>
> * Hosting the Malware
> * Sending Emails with Valid DKIM Signature
> * Valid SPF Sender
>
> They reacted fast, as of today, they have removed the malware from
> their site.
>
> Is it really that easy to go to sendgrid and tell them 'Hey we are
> Swisscom and want to send email invoices to all our customers, please
> provide mass-email and hosting services to us?
>
> Doesn't anyone at sendgrind raises an eyebrow and think, hey wouldn't
> swisscom send such emails over their own infrastructure? Shouldn't we
> verify with swisscom, if this request is authentic?
>
> Kind regards
>
> -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] SORBS help

[Luke Martinez via mailop]

Receivers rely on RBLs to help prevent unwanted mail from getting through
to recipients. There is (or should be) some understanding that utilizing an
RBL will result in bad mail being blocked, and good mail not being blocked.
In this respect, SORBS is pretty good. Plenty of false positives (by that I
mean good senders getting listed, not erroneous listings), but the reason
for listing is almost always very predictable. Not to mention, as Michelle
said, even by default there is enough info from SORBS to find the source of
the problem.

On another note...Saying "RBLs don't block mail" is a fun thing to say to
win an argument, but it is a lot like interrupting someone to say, "You
know technically, a tomato is a fruit." Yeah yeah. We get it. Very cute.

On Sun, Jan 8, 2017 at 6:53 PM, Jay Hennigan 
wrote:

> On 1/8/17 5:11 PM, David Sgro, Dataspindle wrote:
>
>> I have always hated the argument that "RBL's don’t block email".
>>
>
> Haters gotta hate. :-) Happens to be true, though.
>
> While technically its true, you being listed in the RBL is 100% the cause
>> of your problem and it is not the ISP/receiving server admin's fault. It
>> makes no sense and would be futile to contact everyone you email, see if
>> they use a specific RBL, and then get them to put in an exception for you.
>> I know no one here is advocating that, but im just making my point.
>>
>
> Having a bad credit score is 100% of your problem if you can't get a loan,
> and 99% of the time your bad credit score isn't the fault of the credit
> bureau. You earned that bad credit score (or RBL listing).
>
> And if a particular credit bureau is known for sloppy work, then lenders
> won't use them. On the other hand, if they're mostly accurate, then they
> will. Just like SPEWS vs. SORBS.
>
> Saying RBL's aren’t blocking email is like saying its not the heaters
>> fault your gas bill is higher in winter. Technically you don’t need to turn
>> it on, but that’s not practical.
>>
>
> It's not the heater's fault. The blame clearly lies with the tilt of the
> earth's axis. :-)
>
> You could wear a jacket, or build a fire in the wood stove, or invest in a
> more efficient heater. Or suffer with the cold.
>
> Just as you could write your own filters, use just SpamAssassin, or choose
> a better RBL for your situation. Or suffer with the spam.
>
>
>
> ___
> 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] Mysterious DKIM failure.

[Luke Martinez via mailop]

Dave,

I believe if only one canonicalization tag is specified, the other defaults
to "simple" So in this case, "relaxed" is the header canonicalization, and
the body canonicalization would be "simple" which tolerates no
modification.

Its a good thought though. If this turns out to be a whitespace issue, ESPs
could alleviate some of the pain by specifying c=relaxed/relaxed instead of
c=relaxed. I will do some testing on monday and report back. Really
appreciate all the insights from everyone.

On Sun, Dec 11, 2016 at 9:53 AM, Dave Crocker  wrote:

> On 12/10/2016 8:08 AM, Al Iverson wrote:
>
>> Suggestion...modify the template to remove all the tabs or replace
>> them with spaces, and try again. If it passes on both, then you've
>> found that something in the delivery path is replacing tabs with
>> spaces, invalidating the DKIM signature.
>>
>
>
> The original DKIM header field seems to show use of 'relaxed' which ought
> to make sp/tab transformations transparent.
>
>  "Convert all sequences of one or more WSP characters to a single SP
>   character."
>
> hmmm...
>
> d/
>
>
> --
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>
> ___
> 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] Mysterious DKIM failure.

[Luke Martinez via mailop]

Thanks for the insights Steve,

Any thoughts on why the indentation would be different? As far as I know,
this message was built *once*, and then it was sent to several different
recipients. I can't guess why the results would be different when being
sent to different outlook.com recipients. Also noteworthy...Subsequent test
messages (different content, but same config) sent to the same addresses
produced different results (attached)

On Fri, Dec 9, 2016 at 5:57 PM, Steve Atkins <st...@blighty.com> wrote:

>
> > On Dec 9, 2016, at 3:36 PM, Luke Martinez via mailop <mailop@mailop.org>
> wrote:
> >
> > I've got some DKIM failures I'm having trouble figuring out. Below are
> two identical messages sent to two different outlook.com recipients from
> the same infrastructure. One is failing DKIM, the other isn't.
> >
> > This issue is semi-repeatable, with some addresses failing DKIM and
> others passing seemingly at random.
> >
> > I was wondering if anyone could help me identify the cause of the DKIM
> failure, or let me know if this is just a thing that happens on occasion.
> I've attached the full messages and pasted the two headers.
>
> dkimpass.txt indents some lines (e.g. DECK THE HALLS) with three tabs,
> while dkimfail.txt indents those same lines with six spaces.
>
> For mail that otherwise looks like it's coming from the same template
> that's very suspicious.
>
> Cheers,
>   Steve
>
>


-- 

Luke Martinez
Team Lead | Email Delivery
520.400.5693
Received: from BY1PR13CA0003.namprd13.prod.outlook.com (10.162.107.141) by
 MWHPR13MB1536.namprd13.prod.outlook.com (10.175.140.137) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.1.771.4 via Mailbox Transport; Fri, 9 Dec 2016 23:22:18 +
Received: from inbound.mail.protection.outlook.com (216.32.180.120) by
 BY1PR13CA0003.outlook.office365.com (10.162.107.141) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.1.789.5 via Frontend Transport; Fri, 9 Dec 2016 23:22:18 +
Received: from BN3NAM04FT006.eop-NAM04.prod.protection.outlook.com
 (10.152.92.52) by BN3NAM04HT188.eop-NAM04.prod.protection.outlook.com
 (10.152.93.73) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.6; Fri, 9 Dec
 2016 23:22:15 +
Authentication-Results: spf=pass (sender IP is 167.89.0.244)
 smtp.mailfrom=e.email.silpada.com; outlook.com; dkim=pass (signature was
 verified) header.d=email.silpada.com;outlook.com; dmarc=bestguesspass
 action=none header.from=email.silpada.com;
Received-SPF: Pass (protection.outlook.com: domain of e.email.silpada.com
 designates 167.89.0.244 as permitted sender) receiver=protection.outlook.com;
 client-ip=167.89.0.244; helo= o1.e.email.silpada.com;
Received: from SNT004-MC11F2.hotmail.com (10.152.92.58) by
 BN3NAM04FT006.mail.protection.outlook.com (10.152.92.96) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.1.761.6 via Frontend Transport; Fri, 9 Dec 2016 23:22:14 +
X-IncomingTopHeaderMarker: 
OriginalChecksum:1F3929AE2F421F64D0759B2072B637C65D5AF4E5513CB8339CFC5A1EBEED385F;UpperCasedChecksum:1CC256260B9A51AE7529A9CC4ADA8A78374D893F53BE50BFC6F0D101842205F2;SizeAsReceived:1631;Count:14
Received: from o1.e.email.silpada.com ([167.89.0.244]) by 
SNT004-MC11F2.hotmail.com over TLS secured channel with Microsoft 
SMTPSVC(7.5.7601.23143);
 Fri, 9 Dec 2016 15:22:13 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email.silpada.com; 
h=content-type:from:mime-version:subject:to; s=s1; 
bh=l7Nvk3mH4ILxblffMVyzawXYOcM=; b=XgeUIoznQmsqUw48sfcsq2+FwnMNL
yJPVEhy90/bU3b+7P/gTmRkfd2Z//9X/7S5XIw+4+5ymHdeZMSbL3giRWjInkdbT
/0Jsp0kwRIgj7pp6dtDRO3Y6DO9kz12YmVcIqKmoXq1ZYOL1vlB9ninocVdUagfs
DpsI3F4lq3AaQk=
Received: by filter0974p1mdw1.sendgrid.net with SMTP id 
filter0974p1mdw1-2201-584B3CA3-2D
2016-12-09 23:22:11.650615498 + UTC
Received: from NDAyMzM2NQ (o16789125x224.outbound-mail.sendgrid.net 
[167.89.125.224])
by ismtpd0005p1iad1.sendgrid.net (SG) with HTTP id 
ByTzwSvuSdmKofzSqvl52Q
for <matthew.que...@outlook.com>; Fri, 09 Dec 2016 23:22:11.581 + 
(UTC)
Content-Type: multipart/alternative; 
boundary=de75af6eb0ec36ce29f87fd5ce4e4ccb371b0db3b5bdfe7604c05473375e
Date: Fri, 9 Dec 2016 23:22:11 +
From: silp...@email.silpada.com
Subject: From SendGrid
To: matthew.que...@outlook.com
Message-ID: <bytzwsvusdmkofzsqvl...@ismtpd0005p1iad1.sendgrid.net>
X-SG-EID: 
/4D4wegxXCO+mN92/eWzN4CqIJM27SJeUDkqWNtyz3PaCzoitt8v4Yw940wWRRfStz+ZRR+2jMRyrI
 Drv/wqO3MTwDWvMq3Tf7acVRy2gpnomAnVM5B9jXUne1tRosX++I1tqTzYvPDT/pWNzDPSdbrtvCuX
 HbFxf3wSvBLej9pvd5L645hwXeZnPIhcYlK7Cr869bjbApdWF5Nk6n8qnw==
Return-Path: bounces+4023365-dfaf-matthew.quebec=outlook@e.emai

Re: [mailop] Sending on behalf of PayPal

[Luke Martinez via mailop]

All this makes sense. Thanks for the time everyone.

On Fri, Dec 2, 2016 at 12:14 PM, Laura Atkins <la...@wordtothewise.com>
wrote:

>
> On Dec 2, 2016, at 11:02 AM, Jay Hennigan <mailop-l...@keycodes.com>
> wrote:
>
> On 12/2/16 10:23 AM, Luke Martinez via mailop wrote:
>
> Hey Team,
>
> I've got a sender who is sending surveys on behalf of PayPal. They are
> sending from paypal-survey.com <http://paypal-survey.com>. Their mail is
> fully authenticated and they have a DMARC policy set to reject.
>
> Most of their mail is still getting flagged as a likely phishing attempt
> by gmail for obvious reasons.
>
> Even an innocuous test message sent using their configuration got flagged.
>
> Inline image 1
>
>
> I was wondering if there is any good way to deal with this situation. It
> seems like sending messages littered with the word "PayPal" is just
> going to be a disaster if you aren't sending from paypal.com
> <http://paypal.com>. Any suggestions that might help this mail succeed?
>
>
> It's likely not that the message is littered with the word "PayPal". There
> are a lot of online vendors that send a lot of mail with that word in the
> body of the message. This thread has it in both the body and the subject,
> for example.
>
> It's almost certainly the sending domain. "vendor-survey.com" or "
> payment-survey.com" or their own domain might be a better choice.
>
>
> There are some internet providers that maintain data about domains or
> companies that are frequent phish targets. They’re doing it mostly to
> protect against cousin domains.
>
> What you have is a cousin domain and there’s nothing to distinguish it
> from a well done phish. Sure, it’s legit. But how are the recipients going
> to know that?
>
> Either you need to drop paypal completely from the message, or you need to
> get paypal to step up and authenticate the message. Those are really your
> choices here.
>
> Nothing else will be sufficient, IMO.
>
> laura
>
>
> --
> Having an Email Crisis?  800 823-9674 <(800)%20823-9674>
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> 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] Anyone having issues getting mail to AOL?

[Luke Martinez via mailop]

Nothing here either. Had a little spike of those responses back on Oct
24th, but been clear since then.

On Fri, Nov 11, 2016 at 1:56 AM, Mathias Ullrich 
wrote:

> Hey there, nothing out of the ordinary in the last 24h here.
>
> Cheers,
> Mathias
>
> Am 11.11.2016 um 06:14 schrieb Michael Wise via mailop:
>
>> We’re seeing some refusals saying:
>>
>> 521 5.2.1 : AOL will not accept delivery of this message
>>
>> Aloha,
>>
>> Michael.
>>
>> --
>>
>> *Michael J Wise*| Microsoft| Spam Analysis | "Your Spam Specimen Has
>> Been Processed." | Got the Junk Mail Reporting Tool
>> ?
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
> --
> optivo GmbH
> Deliverability & Abuse Management
> Wallstraße 16
> 10179 Berlin
>
> Telefon: 030 / 76 80 78 269
> Fax: 030 / 76 80 78 499
>
> Email:mailto:mathias.ullr...@optivo.de
> Website:  http://www.optivo.de
>
> Handelsregister: HRB Berlin 88738
> Geschäftsführer: Dr. Rainer Brosch, Thomas Diezmann
>
> Optivo, an Episerver Company
>
>
> ___
> 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

[mailop] Microsoft "554 Transaction failed" this morning

[Luke Martinez via mailop]

About two hours ago, we started seeing a significant uptick in "554
Transaction failed"  responses from Microsoft domains. Across all senders.
Anyone else seeing this? If I remember correctly, this came up back in Feb.
as well.

-- 

Luke Martinez
SendGrid Deliverability Consultant
520.400.5693
___
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

Re: [mailop] Still seeing Microsoft 5.4.0 issues?

[Luke Martinez via mailop]

We are still seeing some.

On Wed, Mar 30, 2016 at 2:53 PM, Joel Beckham  wrote:

> Not seeing any here.
>
> On Wed, Mar 30, 2016 at 7:01 AM, Josh Nason  wrote:
>
>> Hi all -- we continue to see Action: failed/Status: 5.4.0 bounces for
>> emails sent to Hotmail, Outlook, and Microsoft domains. I assume others are
>> seeing the same?
>>
>> Microsoft friends, any idea on a resolution time? This feels like it's
>> taking a while to be resolved.
>>
>> --
>>
>> [image: Dyn logo, Dyn.com] 
>> [image: Dyn
>> facebook account] 
>> [image: Dyn LinkedIn account]
>> 
>>
>> Josh Nason / Email Reputation Manager
>>  +1 603-289-1244 | @JoshNason 
>>
>> Email is hot! This is why
>> 
>> it's the original form of social media.
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
>
> --
> JOEL BECKHAM
> Scalability Architect
> [image: BombBomb | Face to Face with more people, more often]
> W: BombBomb.com 
> [image: BombBomb | Face to Face with more people, more often]
>
> ___
> 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

Re: [mailop] Yahoo DMARC changes

[Luke Martinez via mailop]

That's interesting. From an ESP's prospective, deciding to use a different
domain in the from address is simply not an acceptable option. That being
said, I wish we had a good way to tell senders that they are heading for
trouble. You would be surprised how many senders don't know that there is a
part of their infrastructure that is using these domains in their from
address.

On Tue, Mar 22, 2016 at 7:54 PM, Vick Khera  wrote:

>
> On Tue, Mar 22, 2016 at 7:52 PM, Steve Atkins  wrote:
>
>> So if you've been doing anything special with forwarders or mailing lists
>> for yahoo.com
>>
>> it's probably a good idea to do it for their other domains too in the
>> next few days.
>>
>
> When Y! first set up p=reject on their main domain, we built our system's
> evasive maneuvers to work around it to be domain independent. Our systems
> do a DNS lookup for the DMARC record and if they find p=reject or
> p=quarantine and we do not sign using their From address in the domain, we
> automatically enable the workarounds to avoid falling in the trap. No
> manual configuration necessary.
>
>
> ___
> 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

Re: [mailop] Mail accepted by outlook.com/hotmail.com disappears.

[Luke Martinez via mailop]

Michael,

Could you elaborate on:

"The issue will be highlighted in the SNDS report, however."

Luke


On Thu, Mar 17, 2016 at 6:38 PM, Michael Wise 
wrote:

> Has the customer signed up for JMRP or SNDS?
>
> Because if not, that would be step #0; see below.
>
>
>
> And yes, under certain circumstances, Hotmail/Outlook will 250 the mail,
> and may then if it considers the IP sufficiently toxic, delete it without
> delivering it to the intended recipient’s INBOX or Junk folder with no NDR.
> The issue will be highlighted in the SNDS report, however.
>
>
>
> And there is **NO-ONE** at Microsoft who is a contact who can get things
> running smoothly again.
>
> The policy is cast in ferro-cement, no exceptions:
>
>
>
> 1)  Open a ticket and request mitigation for the IP(s) here:
> http://go.microsoft.com/fwlink/?LinkID=614866
>
> 2)  Wait and see what the machine thinks…
>
> 3)  If the IPs are not mitigated, reply to the email and request it,
> and provide as much detail as possible about:
>
> A)  what happened,
>
> B)  what you did to fix it,
>
> C)  and why it Won’t Happen Again.
>
>
>
> As to the programs that Senders should join, they are:
>
>
>
>
> *Join the Junk Mail Reporting Program (JMRP) *We believe that your
> recipients are the best indicator that the email you are sending is
> wanted.  The JMRP program allows you to see which of your emails
> Outlook.com users have marked as junk or unwanted mail.  Reviewing the
> results in JMRP will provide to the most direct information on what
> characteristics of your email, customers, and ultimately SmartScreen®,
> consider to be unwanted. This helpful feedback mechanism allows you to
> ensure that mails being sent from your IP are not resulting in negative
> feedback that could impact your sending reputation. Being vigilant about
> users who mark your e-mail as unwanted or the types of messages that are
> being marked as unwanted can help you keep mailing lists updated with only
> interested users and modify future campaigns. In addition, monitoring user
> complaints can help you identify unintended mail traffic or detect a
> potentially compromised account sending unwanted mail to your customers.
> Enroll at https://postmaster.live.com/snds/JMRP.aspx?wa=wsignin1.0.
>
>
>
> *Join the Smart Network Data Services program (SNDS)*
>
> The SNDS program provides data about traffic seen originating from your
> registered IP, such as mail volume and complaint rates. The data is built
> from the log files of the inbound mail machines and other servers at
> Outlook.com and Microsoft and represents factual information about the
> traffic from your mail servers to Outlook.com users. For more information
> about this free program refer to https://postmaster.live.com/snds/FAQ.aspx.
> To register, please go to http://postmaster.msn.com/snds/*.* (Tip: As
> part of the enrollment process, you are asked to sign the JMRP program
> agreement and then send a response to Support indicating that it has been
> signed.  It’s not uncommon for that step in the enrollment process to be
> missed.)
>
>
>
> 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 *Aaron C.
> de Bruyn
> *Sent:* Thursday, March 17, 2016 5:12 PM
> *To:* mailop@mailop.org
> *Subject:* [mailop] Mail accepted by outlook.com/hotmail.com disappears.
>
>
>
> A customer complained to me they haven't been able to e-mail
> outlook/hotmail users for "a while".
>
>
>
> I talked with their IT department and they said "A few weeks ago we had a
> virus that spammed a bunch of people.  We cleaned it up and got de-listed
> everywhere, but outlook.com
> 
> is still broken".
>
>
>
> They gave up and turfed the issue to me (an outside consulting company).
>
>
>
> I set up a test account on outlook.com
> 
> and tried sending several messages.  After 30 minutes the messages aren't
> in my outlook.com
> 
> inbox or spam folder.
>
>
>
> I manually dug through the (password protected) archives 

Re: [mailop] Mail accepted by outlook.com/hotmail.com disappears.

[Luke Martinez via mailop]

That's interesting.

I find their ticketing system to be much more reliable and effective than
any other deliverability mitigation channel out there (aside from calling
in a favor with a friend.)

On Thu, Mar 17, 2016 at 7:38 PM, Marc Perkel 
wrote:

> I've had nothing but trouble with MS. Lots of messages delayed for hours.
> No one to contact and complain to. I think their system is broken and they
> don't know how to fix it.
>
>
> On 03/17/16 17:12, Aaron C. de Bruyn wrote:
>
> A customer complained to me they haven't been able to e-mail
> outlook/hotmail users for "a while".
>
> I talked with their IT department and they said "A few weeks ago we had a
> virus that spammed a bunch of people.  We cleaned it up and got de-listed
> everywhere, but outlook.com is still broken".
>
> They gave up and turfed the issue to me (an outside consulting company).
>
> I set up a test account on outlook.com and tried sending several
> messages.  After 30 minutes the messages aren't in my outlook.com inbox
> or spam folder.
>
> I manually dug through the (password protected) archives (which don't have
> a search feature) and gave up after hitting mid 2015.  I only found:
>
> http://windows.microsoft.com/en-us/outlook/not-receiving-email
>
> ...which is totally useless and ends up leading me to a generic support
> page.  (Strangely enough, I can search for "outlook.com unable to
> receive" and I can keep going in a loop forever.)
>
> Is there a better way of contacting Microsoft?
>
> Debug info:
>
> Mar 17 16:30:31 squid postfix/smtp[26744]: EB6401C4127: to=<
> darkpixe...@outlook.com>, relay=mx4.hotmail.com[65.55.92.184]:25,
> delay=0.87, delays=0.02/0/0.45/0.39, dsn=2.0.0, status=sent (250  <
> 20160317233030.eb6401c4...@mail.hamer-electric.com> Queued mail for
> delivery)
>
> Thanks,
>
> -A
>
>
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Marc Perkel - 
> Sales/Supportsupport@junkemailfilter.comhttp://www.junkemailfilter.com
> Junk Email Filter dot com415-992-3400
>
>
> ___
> 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