[mailop] Tiscali / Talktalk Content deferred (TT991)

[Duncan Brannen via mailop]

Afternoon,
Any Talktalk / Tiscali admins about or recommendations for 
contacting?  We're seeing lots of deferred, ( TT991 ) messages when trying to 
deliver email.  ~50% goes straight through and the other 50% is taking 12-24 
hours to be delivered.

Cheers,
Duncan

--
The University of St Andrews is a charity registered in Scotland : No SC013532
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Duncan Brannen via mailop]

I’ll +1 to Jethro’s comments.  NCSC will give you free DMARC reporting.  We’ve 
done as Strathclyde and pushed services out into subdomains.  The top level 
domain is just us and specific suppliers used for official comms. It wasn’t too 
painful in the end but we spent a lot of time in report only mode working out 
who we’d be cutting off.

Cheers,
Duncan

--
The University of St Andrews is a charity registered in Scotland : No SC013532
From: mailop  On Behalf Of Jethro Binks via mailop
Sent: 11 January 2023 14:25
To: mailop@mailop.org
Subject: Re: [mailop] Intentionally vague SPF records.

> +1 to Mark's comments... Without discovery you'll never know if you're over 
> the limits or not.

That's not the point though.  It might be fine today.  But at any time any one 
of those providers could change a record you are including from them, and take 
you over the limit, effectively a DoS on your email which is totally out of 
your hands.

Don't allow yourself to be placed in that situation.  Get some DMARC reporting 
set up, and start working through the data to get a better idea of the scale of 
the issue, and work on the senders to get them to change.  In our case, we tend 
to shuffle them into subdomains for the specific purpose.  But yeah it can be a 
lot of work over a long time, but that time won't get any shorter until you 
start it 🙂.

> (it's a UK University, where there's no obligation for colleges to use IT 
> services).

Your top-level Uni email domain is a central University IT resource not a 
college one, so you get to define the conditions by which it is used, over time 
(yes, easier said than done!).

Jethro.


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

Jethro R Binks, Network Manager,

Information Services Directorate, University Of Strathclyde, Glasgow, UK



The University of Strathclyde is a charitable body, registered in Scotland, 
number SC015263.


From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Matt Vernhout via mailop mailto:mailop@mailop.org>>
Sent: 11 January 2023 13:55
To: mailop@mailop.org 
mailto:mailop@mailop.org>>
Subject: Re: [mailop] Intentionally vague SPF records.

+1 to Mark's comments... Without discovery you'll never know if you're over the 
limits or not.

Setup a p=none policy, and see where the mail is coming from.

You may need to update systems, or change some domains to use subdomains, or a 
different MailFrom: etc... but If massive global corporations like Disney, HP, 
and Oracle, can figure it out you can too.

A lot of DMARC reporting services will likely offer some kind of SPF flattening 
as part of their services without extra cost.

~ MV


On Wed, Jan 11, 2023 at 8:29 AM Mark Alley via mailop 
mailto:mailop@mailop.org>> wrote:

What makes you think you'd go over the limit if you haven't done the discovery? 
You might be surprised that you may not exceed the lookup count, as with 
optimization/analysis and proper SPF design (even without flattening), the 
lookup count can be quite easily managed. This sounds like a prime candidate 
for your mail source discovery with DMARC 
reporting.

Using ?all (neutral) might be best for deliverability's sake while you build 
out this SPF record during discovery. This would have the same effect as your 
current scenario of having no SPF record, while still allowing for positive 
matches of your legitimate known mail-flow until you get to a point you move to 
~all.

- Mark Alley
On 1/11/2023 7:08 AM, Simon Burke via mailop wrote:
All,

This is an odd scenario, but sadly one I find myself in.

Work is a large organisation, and currently does not have an SPF record. The 
reason is that there are a large (and unknown) number of internal and external 
parties that send mail on our domain, as well as sub-domains.

So, even if we do determine who sends email on the domain, we would then have 
an issue with max lookups and record length.

I know we can use an SPF flattening service. However that either has a cost. 
Or, although we can develop something in house, there's a 'bought not built' 
ethos being pushed by management.

As an out the box idea, what would the potential impact be of having an SPF 
record stating just:

"V=spf1 a mx +all"

How bad of an idea would this be? If we also had a DMARC record set to either 
quarantine or reject.

Regards,

Simon








___

mailop mailing list

mailop@mailop.org

https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft SPF failing our email internally against their own servers

[Duncan Brannen]

Morning Jesse,
(mailop CC@d for completeness but it's not mail a mail delivery issue 
really)

You seem to have been spot on with the connector issue.  I hadn't realised that 
the connectors we setup in O356 were not
specific to our hybrid exchange setup and if the certificate on our mailhosts 
also matched the certificates defined in there
then mail seems to be routed into our tenancy first and then back out again, 
causing the SPF fail. (I'm happier in Unix land)

So, restricting the regex in the O365 connector so that it only matches our 
hybrid servers and not our on premise servers
seems to have done the trick.  (I'm still uncertain, there seemed to me to be a 
bit of hand waving going on)

Now can anyone recommend any sendmail milters to restrict outbound send rates 
so we can clamp down on these phished accounts more.

Thanks,
Duncan

-Original Message-
From: mailop  On Behalf Of Jesse Thompson via mailop
Sent: 08 November 2018 17:49
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft SPF failing our email internally against their 
own servers

I would bet it has to do with the way you set up your inbound and outbound 
connectors in your Exchange Online tenant.  You should not need to include EOP 
in your SPF (although IIRC there is no way to set up hybrid routing for OOFs)

We had some tenant-tenant routing issues in 2015 due to the way we had set up 
our connectors for hybrid routing.  We resolved it via some advice obtained 
from a lengthy conversation with someone on the Exchange team who actually 
knows how the EOP/ExO systems are plumbed.

Microsoft's support teams don't like dealing with complex mail flow scenarios, 
but I am encouraged by some comments I've heard lately that they realize that 
enterprise mail flow will always be complex, which is why they're starting to 
address some of the forwarding problem scenarios, adding a capability to fix 
inbound-gateway SPF evaluation, getting on board with ARC, etc.

Jesse

On 11/8/2018 6:14 AM, Duncan Brannen wrote:
> Morning all,
> 
>  Does anyone have any issues delivering to some O365 
> domains due to Microsoft internally SPF failing inbound email against 
> their own servers?
> 
> We’re seeing the email go through our MXs and be delivered to 
> x.protection.outlook.com,
> 
> protection.outlook.com then SPF checks and passes the message, 
> verifies the DKIM signature and passes that.
> 
> then…
> 
> it gets routed internally from protection.outlook.com to 
> outlook.office365.com, back to protection.outlook.com
> 
> and then goes through a second set of SPF and DKIM checks which fail 
> SPF because protection.outlook.com is not a permitted server for 
> st-andrews.ac.uk
> 
> It ‘seems’ to happen for recipients in UK datacentres where their MX 
> records still point at the EU datacentres and I ‘think’ having
> 
> an O365 tenancy but routing all of our outbound email through our 
> onsite MX servers is a contributing factor due to the tenant
> 
> name appearing in the headers. [we’re hybrid on premise, Gmail and 
> O365]
> 
> Our support call is going round in circles, we’ve been told the remote 
> site has blacklisted us, that we need to add the MS servers into our 
> SPF,
> 
> that we need to add our hybrid servers into our SPF, that our DKIM 
> signature is invalid, that our SPF is invalid, that the remote site 
> have errors
> 
> in their EOP configuration and that Barracuda have blacklisted us.
> 
> I can see that adding protection.outlook.com to our SPF record will 
> fix this though protection.outlook.com shouldn’t be sending email for 
> us and
> 
> shouldn’t be in our SPF but it may be that the price of having an O365 
> tenancy is we have to whether we send email that way or not. If anyone
> 
> knows either way and can explain why or knows how we should phrase a 
> request for escalation to a team that understands hybrid setups where
> 
> email is routed through non MS servers I’d appreciate sharing of the 
> knowledge. J
> 
> Example headers below.
> 
> Cheers,
> 
>Duncan
> 
> Received: from LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM 
> (2603:10a6:600:5e::31)
> 
> by LO2P265MB1728.GBRP265.PROD.OUTLOOK.COM with HTTPS via
> 
> LNXP265CA0019.GBRP265.PROD.OUTLOOK.COM; Fri, 26 Oct 2018 08:00:56 
> +
> 
> Received: from CWLP265CA0256.GBRP265.PROD.OUTLOOK.COM 
> (2603:10a6:401:25::28)
> 
> by LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:78::11) with
> 
> Microsoft SMTP Server (version=TLS1_2,
> 
> cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.24; Fri, 
> 26 Oct
> 
> 2018 08:00:56 +
> 
> Received: from VE1EUR01FT055.eop-EUR01.prod.protection.outlook.com
> 
> (2a01:111:f400:7e01:

Re: [mailop] Microsoft SPF failing our email internally against their own servers

[Duncan Brannen]

Thanks all,
   I should probably have been a bit clearer in my description of 
the symptom in that email is not rejected but marked as Spam and delivered to 
Junk.

I know at least one of the two recipient domains we have issues with has hard 
SPF failure on so SPF fail == Junk but need to check with the other.
We don’t seem to have issues with any other folk on O365, just the two and what 
they both have in common is that extra hop and second failing SPF check that I 
don’t see when I get headers back from other institutions.

We don’t publish a dmarc policy yet (soon!)

So far the receivers have whitelisted our domain, solving the issue but I don’t 
like having to whitelist domains myself so would rather get to
the bottom of it. (and I’m curious )

Cheers,
  Duncan



From: mailop  on behalf of Brandon Long via mailop 

Reply-To: Brandon Long 
Date: Thursday, 8 November 2018 at 17:58
To: Steve Dodd 
Cc: mailop 
Subject: Re: [mailop] Microsoft SPF failing our email internally against their 
own servers

When I've seen this, there is usually a big spf bounce explanation, but the 
actual cause is a reject that O365 is giving a very verbose SPF error message 
for but may not involve spf at all.

Ie, I've seen it with messages forwarded through O365 to Gmail, which rejects 
it for failing dmarc.  The forwarding breaks spf and dkim.

The eventual solution is ARC, but of course we're not there yet.

If it is a dmarc issue, then adding them to the SPF might help for you, but is 
unlikely to help for other folks they are having trouble with.

In the past, I know folks who have used a different mx server or service in 
front of Exchange to do forwarding without breaking auth, but I don't know the 
current best solutions here, but they're usually on the receiver side.  I think 
O365 has fixed some forwarding paths to leave dkim intact.

It may also be possible that some other reject is causing this and also being 
interpreted as an SPF failure, usually the real smtp response is in there 
somewhere.

Brandon

On Thu, Nov 8, 2018, 5:28 AM Steve Dodd 
mailto:steved...@gmail.com> wrote:
Can't help with this directly, but I've seen similar happen with mail to 
Facebook, which uses O365..

S.
On Thu, 8 Nov 2018 at 12:25, Duncan Brannen 
mailto:d...@st-andrews.ac.uk>> wrote:

Morning all,
Does anyone have any issues delivering to some O365 domains due 
to Microsoft internally SPF failing inbound email against their own servers?

We’re seeing the email go through our MXs and be delivered to 
x.protection.outlook.com<http://x.protection.outlook.com>,

protection.outlook.com<http://protection.outlook.com> then SPF checks and 
passes the message, verifies the DKIM signature and passes that.
then…
it gets routed internally from 
protection.outlook.com<http://protection.outlook.com> to 
outlook.office365.com<http://outlook.office365.com>, back to 
protection.outlook.com<http://protection.outlook.com>
and then goes through a second set of SPF and DKIM checks which fail SPF 
because protection.outlook.com<http://protection.outlook.com> is not a 
permitted server for st-andrews.ac.uk<http://st-andrews.ac.uk>

It ‘seems’ to happen for recipients in UK datacentres where their MX records 
still point at the EU datacentres and I ‘think’ having
an O365 tenancy but routing all of our outbound email through our onsite MX 
servers is a contributing factor due to the tenant
name appearing in the headers. [we’re hybrid on premise, Gmail and O365]

Our support call is going round in circles, we’ve been told the remote site has 
blacklisted us, that we need to add the MS servers into our SPF,
that we need to add our hybrid servers into our SPF, that our DKIM signature is 
invalid, that our SPF is invalid, that the remote site have errors
in their EOP configuration and that Barracuda have blacklisted us.

I can see that adding protection.outlook.com<http://protection.outlook.com> to 
our SPF record will fix this though 
protection.outlook.com<http://protection.outlook.com> shouldn’t be sending 
email for us and
shouldn’t be in our SPF but it may be that the price of having an O365 tenancy 
is we have to whether we send email that way or not. If anyone
knows either way and can explain why or knows how we should phrase a request 
for escalation to a team that understands hybrid setups where
email is routed through non MS servers I’d appreciate sharing of the knowledge. 
☺

Example headers below.

Cheers,
  Duncan

Received: from 
LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM<http://LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM>
 (2603:10a6:600:5e::31)
by 
LO2P265MB1728.GBRP265.PROD.OUTLOOK.COM<http://LO2P265MB1728.GBRP265.PROD.OUTLOOK.COM>
 with HTTPS via
LNXP265CA0019.GBRP265.PROD.OUTLOOK.COM<http://LNXP265CA0019.GBRP265.PROD.OUTLOOK.COM>;
 Fri, 26 Oct 2018 08:00:56 +
Received: from 
CWLP265CA02

[mailop] Microsoft SPF failing our email internally against their own servers

[Duncan Brannen]

 

Morning all,

Does anyone have any issues delivering to some O365 domains
due to Microsoft internally SPF failing inbound email against their own
servers?

 

We're seeing the email go through our MXs and be delivered to
x.protection.outlook.com, 

 

protection.outlook.com then SPF checks and passes the message, verifies the
DKIM signature and passes that.

then.

it gets routed internally from protection.outlook.com to
outlook.office365.com, back to protection.outlook.com

and then goes through a second set of SPF and DKIM checks which fail SPF
because protection.outlook.com is not a permitted server for
st-andrews.ac.uk

 

It 'seems' to happen for recipients in UK datacentres where their MX records
still point at the EU datacentres and I 'think' having

an O365 tenancy but routing all of our outbound email through our onsite MX
servers is a contributing factor due to the tenant 

name appearing in the headers. [we're hybrid on premise, Gmail and O365]

 

Our support call is going round in circles, we've been told the remote site
has blacklisted us, that we need to add the MS servers into our SPF,

that we need to add our hybrid servers into our SPF, that our DKIM signature
is invalid, that our SPF is invalid, that the remote site have errors

in their EOP configuration and that Barracuda have blacklisted us.

 

I can see that adding protection.outlook.com to our SPF record will fix this
though protection.outlook.com shouldn't be sending email for us and

shouldn't be in our SPF but it may be that the price of having an O365
tenancy is we have to whether we send email that way or not. If anyone

knows either way and can explain why or knows how we should phrase a request
for escalation to a team that understands hybrid setups where

email is routed through non MS servers I'd appreciate sharing of the
knowledge. :)

 

Example headers below.

 

Cheers,

  Duncan

 

Received: from LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::31)

by LO2P265MB1728.GBRP265.PROD.OUTLOOK.COM with HTTPS via

LNXP265CA0019.GBRP265.PROD.OUTLOOK.COM; Fri, 26 Oct 2018 08:00:56 +

Received: from CWLP265CA0256.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:25::28)

by LNXP265MB0905.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:78::11) with

Microsoft SMTP Server (version=TLS1_2,

cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.24; Fri, 26 Oct

2018 08:00:56 +

Received: from VE1EUR01FT055.eop-EUR01.prod.protection.outlook.com

(2a01:111:f400:7e01::206) by CWLP265CA0256.outlook.office365.com

(2603:10a6:401:25::28) with Microsoft SMTP Server (version=TLS1_2,

cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1273.19 via Frontend

Transport; Fri, 26 Oct 2018 08:00:55 +

Authentication-Results: spf=fail (sender IP is 104.47.0.127)

smtp.mailfrom=st-andrews.ac.uk; uhi.ac.uk; dkim=pass (signature was
verified)

header.d=UniversityofStAndrews907.onmicrosoft.com;uhi.ac.uk;

dmarc=bestguesspass action=none header.from=st-andrews.ac.uk;

Received-SPF: Fail (protection.outlook.com: domain of st-andrews.ac.uk does

not designate 104.47.0.127 as permitted sender)

receiver=protection.outlook.com; client-ip=104.47.0.127;

helo=EUR01-HE1-obe.outbound.protection.outlook.com;

Received: from EUR01-HE1-obe.outbound.protection.outlook.com (104.47.0.127)
by

VE1EUR01FT055.mail.protection.outlook.com (10.152.3.104) with Microsoft SMTP

Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id

15.20.1294.14 via Frontend Transport; Fri, 26 Oct 2018 08:00:55 +

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

d=UniversityofStAndrews907.onmicrosoft.com; s=selector1-standrews-ac-uk0e;

h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-Sende
rADCheck;

bh=jmNDk9A9PZk09YI7EoXcC6bpFtKR82SKTANn3/DMLug=;

b=ED9NpX9QKXys3LSbATyd1YMgMQbsPuEcRC92nBMGdPTsmDPO7fHqm7hzMOCCkKw4+1+hnch9Jw
2kVAxit6o/NKsdo66TJ+EM0BDCmmkAefoo/2KSvwKz5cuTTp5lBId6DKAUjUSjoCOqOhIv5yf46D
zflVSY0yr4fy3dIbEe3GI=

Received: from VI1PR06CA0143.eurprd06.prod.outlook.com
(2603:10a6:803:a0::36)

by DB6PR0601MB2389.eurprd06.prod.outlook.com (2603:10a6:4:1f::20) with

Microsoft SMTP Server (version=TLS1_2,

cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.19; Fri, 26 Oct

2018 08:00:53 +

Received: from VE1EUR01FT064.eop-EUR01.prod.protection.outlook.com

(2a01:111:f400:7e01::205) by VI1PR06CA0143.outlook.office365.com

(2603:10a6:803:a0::36) with Microsoft SMTP Server (version=TLS1_2,

cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1273.21 via Frontend

Transport; Fri, 26 Oct 2018 08:00:53 +

Authentication-Results-Original: spf=pass (sender IP is 138.251.6.249)

smtp.mailfrom=st-andrews.ac.uk; uhi.ac.uk; dkim=pass (signature was
verified)

header.d=st-andrews.ac.uk;uhi.ac.uk; dmarc=bestguesspass action=none

header.from=st-andrews.ac.uk;

Received-SPF: Pass (protection.outlook.com: domain of st-andrews.ac.uk

designates 138.251.6.249 as permitted sender)

receiver=prot

[mailop] Any Symantec / Messagelabs contacts on list who can sort the MX record you have cached for us.

[Duncan Brannen]

Hi All,
 We're having trouble getting email from people who send their email via 
messagelabs as
it would seem messagelabs are using MX records for us that are months out of 
date.

Anyone able to fix / know how to get in touch with them to have this fixed

Thanks,
   Duncan



--
The University of St Andrews is a charity registered in Scotland : No SC013532

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

Re: [mailop] Endless spam blowback from Microsoft Office 365

[Duncan Brannen]

Hi Graeme,
I might have misunderstood your use case but we have a hybrid exchange 
setup here (Sendmail -> [on premise exchange <-> O365] ) and we turn off spam
filtering for mail which has gone through specific onsite mail servers by 
setting up a rule under mail flow in the Exchange Admin centre to set the
Spam Confidence Level to -1  .We still get SPF fails, I got no where trying to 
explain to MS they shouldn’t be SPF checking mail passed to O365 through our
on premise exchange but they were adamant that they should because they don’t 
trust email within the hybrid, they regard the on premise part as external.

Cheers,
Duncan



On 21/06/2017, 17:42, "mailop on behalf of Graeme Fowler" 
 wrote:

IMO in a hybrid setup where the MX servers aren’t with MS, they should have 
a switch to turn spam filtering off, because we’ve already evaluated the risk 
of a specific message and whether or not we should deliver it. They don’t have 
one (that I can see).




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

Re: [mailop] Microsoft SNDS

[Duncan Brannen]

 

While I hate to say it,

 

“Me too”  I hadn’t noticed until I saw these messages though so haven’t 
reported it yet.

 

Cheers,

    Duncan

 

 

From: mailop  on behalf of ewald kessler | webpower 

Date: Friday, 5 May 2017 at 14:49
To: mailop 
Subject: Re: [mailop] Microsoft SNDS

 

Same here, no data since May 1.


--

Deliverability & Abuse Management, www.webpower-group.com

ewald.kess...@webpower.nl

t: +31 342 423 262

 

On 5 May 2017 at 15:28, Dickie LaFlamme  wrote:

We're also seeing no data since May 1st in SNDS. 

Thanks,

​Oracle + Dyn

 
Dickie LaFlamme  |  Deliverability Specialist



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

 



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

Re: [mailop] Microsoft/Hotmail discards mails

[Duncan Brannen]

Thanks Michael,
That’s helpful and at least something I can 
give to our admissions people.

Cheers,
Duncan


From: Michael Wise 
Date: Thursday, 9 June 2016 at 14:26
To: Duncan Brannen , "mailop@mailop.org" 

Subject: RE: [mailop] Microsoft/Hotmail discards mails


Separate IPs absolutely help, at least they do now. At some point, separate 
domains will be where it's at. "Canned Responses" are mandated by the Lawyers, 
who have had to deal with ... "Issues".

I have been told that Return Path Sender Score is certainly a factor, and that 
they also have some extra services available, but exactly how they get this 
data I do not know, and can't comment on. I don't know.

The largest factor that drives good reputation is having the Recipients 
safelist the sender. Another huge factor is engaging the recipient in a 
conversation of some sort. Further down the list is making sure that your 
traffic looks as little like spam as possible. If you use tricks that spammers 
do, for instance any kind of hashbuster text, etc... The system *WILL* notice.

Past that, we're not allowed to provide information on why a particular email 
or campaign was sent to junk or silently dropped, and honestly, I have never 
been motivated to figure out the mechanics. Remember that, "Each Sender is 
Unique!", and there's millions of them, and Billions of emails an hour, let 
alone a day.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Duncan Brannen<mailto:d...@st-andrews.ac.uk>
Sent: ‎6/‎9/‎2016 1:16 AM
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: Re: [mailop] Microsoft/Hotmail discards mails

Hi,
Just to throw our tuppence worth in.  We have the same problem.  It seems 
to be noticed when we send out offers of a place of study, a noticeable 
percentage of the emails
are never received despite being accepted by Hotmail / outlook / live.com for 
delivery.  We’re signed up for JMRP / SNDS, have opened tickets but can’t get 
anything
back other than a canned response.  (unusual activity or eligible/not eligible 
for partial mitigation)

Is there a method for feeding back suggestions about this, eg a notification 
along the lines of the Junk report mechanism?  By the sounds of it, there 
really isn’t any way to find out
why emails are silently junked and asking applicants to whitelist the 
University would seem to be the only way to mitigate? Does Returnpath / Sender 
score help in any way here?

One thought is to move all of our ‘business’ (ie official comms to applicants 
and enquirers) to one IP and keep staff/student / bulk email to eg alumni to a 
different IP but if anyone
has any suggestions I’m open to them.

Cheers,
Duncan


On 09/06/2016, 03:08, "mailop on behalf of Michael Wise via mailop" 
 wrote:


At the request of the customer-base, traffic that is classified as sufficiently 
spammy (by various "Black Box" algorithms that I have no knowledge of the inner 
workings...) is deleted even after a successful delivery.

At one point, Hotmail tried to turn off the delete action for sufficiently 
spammy, and just delivered it into Junk; Customers complained. Loudly. So 
whether the system is correctly classifying your traffic or not, I cannot say. 
But the behavior is not unexpected in certain scenarios. Which one of them 
applies to you, I cannot say. Even if I wanted to! But I really have no idea, 
and no way to find out.

This "Delete" action is a well-known mitigation that is not unique to Hotmail.

About the only way around it would be to login to your test account, and safe 
sender the sending email address.
Among other things, that will force the system to reconsider the verdict that 
it has assigned to the IP and the traffic coming from it.

It's possible that the IPs have a left-over bad reputation from a previous 
sender, but that's difficult to tell.

Good luck.

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

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Andreas Ziegler
Sent: Wednesday, June 8, 2016 6:50 PM
To: mailop@mailop.org
Subject: [mailop] Microsoft/Hotmail discards mails

Hi,

a user of my server complained, that some of his mails don't reach mail 
accounts from hotmail/live/outlook etc. that complaint is nothing new, the 
problem exists for months now.

the users mails are dkim signed, the domain has DKIM and SPF TXT DNS records, 
since yesterday there is also a DMARC record.

i investigated further, set up test accounts on both ends and indeed, they are 
accepting the mail with 250 but it doesn't appear in the inbox or even junk 
folder.

According to SNDS, the IP has "normal status" and no events are logged.
i reached

Re: [mailop] Microsoft/Hotmail discards mails

[Duncan Brannen]

Hi,
Just to throw our tuppence worth in.  We have the same problem.  It seems 
to be noticed when we send out offers of a place of study, a noticeable 
percentage of the emails
are never received despite being accepted by Hotmail / outlook / live.com for 
delivery.  We’re signed up for JMRP / SNDS, have opened tickets but can’t get 
anything
back other than a canned response.  (unusual activity or eligible/not eligible 
for partial mitigation)

Is there a method for feeding back suggestions about this, eg a notification 
along the lines of the Junk report mechanism?  By the sounds of it, there 
really isn’t any way to find out
why emails are silently junked and asking applicants to whitelist the 
University would seem to be the only way to mitigate? Does Returnpath / Sender 
score help in any way here?

One thought is to move all of our ‘business’ (ie official comms to applicants 
and enquirers) to one IP and keep staff/student / bulk email to eg alumni to a 
different IP but if anyone
has any suggestions I’m open to them.

Cheers,
Duncan


On 09/06/2016, 03:08, "mailop on behalf of Michael Wise via mailop" 
 wrote:


At the request of the customer-base, traffic that is classified as sufficiently 
spammy (by various "Black Box" algorithms that I have no knowledge of the inner 
workings...) is deleted even after a successful delivery.

At one point, Hotmail tried to turn off the delete action for sufficiently 
spammy, and just delivered it into Junk; Customers complained. Loudly. So 
whether the system is correctly classifying your traffic or not, I cannot say. 
But the behavior is not unexpected in certain scenarios. Which one of them 
applies to you, I cannot say. Even if I wanted to! But I really have no idea, 
and no way to find out.

This "Delete" action is a well-known mitigation that is not unique to Hotmail.

About the only way around it would be to login to your test account, and safe 
sender the sending email address.
Among other things, that will force the system to reconsider the verdict that 
it has assigned to the IP and the traffic coming from it.

It's possible that the IPs have a left-over bad reputation from a previous 
sender, but that's difficult to tell.

Good luck.

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

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Andreas Ziegler
Sent: Wednesday, June 8, 2016 6:50 PM
To: mailop@mailop.org
Subject: [mailop] Microsoft/Hotmail discards mails

Hi,

a user of my server complained, that some of his mails don't reach mail 
accounts from hotmail/live/outlook etc. that complaint is nothing new, the 
problem exists for months now.

the users mails are dkim signed, the domain has DKIM and SPF TXT DNS records, 
since yesterday there is also a DMARC record.

i investigated further, set up test accounts on both ends and indeed, they are 
accepting the mail with 250 but it doesn't appear in the inbox or even junk 
folder.

According to SNDS, the IP has "normal status" and no events are logged.
i reached out to them through their form two times and got the same answer 
twice, that the IP doesn't qualify for mitigation.

the thing is, i can't figure out
a) why they discard the mails
b) why they don't reject them, that would be much better

we're a low volume sender, so i investigated the logs manually and can't find 
any outgoing spam.

all of the users recipients do really want to get these mails and are very 
upset that they don't receive them.
and even if they didn't want to, they could tell via mail or even in person, as 
all of them are at the same university (and are friends).

perhaps someone has an additional idea, another form or contact address or what 
can i try to solve this?

ticket numbers: SRX1342522740ID / SRX1342663522ID.

Regards

Andreas

___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=01%7c01%7cmichael.wise%40microsoft.com%7cb2c91735275742b7b2e408d390093f5c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ccB7YaSdDu3ZN4SrE8MCC6JwpavpsqE9aJz6InPWXPM%3d
___
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