Re: [mailop] Warming IPs throttled at Hotmail

[Benjamin BILLON]

Hi John,

To warm IPs, instead of sending high volumes slowly (yeah, 20K per IP isn't
high, but it might be too high anyway), you'd better send a small volume
per day, for several days.
If you have another pool already warm, you should use cold-virtual-mta in
some of the warm IPs in order to warm the cold IPs. By default,
cold-virtual-mta would take the 1000 first messages of each domain from the
warm vmta, and re-route them by the cold vmta. That makes 1000 @hotmail.com,
1000 @outlook.com, etc., that's enough for a warming.
Warming IPs at hotmail could take a few weeks, and of course depends on the
quality of the traffic, the number of complaints and traps you hit, etc.

You know your IPs are warm when they turn green in SNDS.

Hop that helps,
Benjamin


-- 
[image: SPLIO] https://www.splio.com  Benjamin BILLON
ISP Relations  Deliverability Director
Tel. : +33 (0)1 84 73 11 32
   www.splio.com *Follow us on:*  [image: Facebook]
https://www.facebook.com/spliogroup [image: LinkedIn]
https://twitter.com/Splio [image: LinkedIn]
https://www.linkedin.com/company/splio

2015-05-14 20:35 GMT+02:00 John Little john.lit...@livingsocial.com:

 Hi,

 I have a set of IPs that were throttled at hotmail with the message that
 they only accept a certain amount of email per hour and per day.

 I am using our normal setting for hotmail and have not had this problem
 until recently when warming mail.  I am warming with mail that is sent to
 our cleanest and most responsive list to avoid this situation.

 I have no problem with them wanting me to slow down the delivery for a
 cold IP.  I'm just not sure what that should be.  I use PowerMTA and the
 directive for this is max-msg-rate and can be set for hour, minutes,
 seconds or day.  The default which is where we normally run is unlimited
 with max-rcpt-per-message 1000 and max-smtp-out 500.

 Anyone have any ideas what max-msg-rate should be or what works for you?
 I am only sending 40k per day over 2 IPs for this stage of warming.

 Thanks,
 John


 --
 John Little
 john.lit...@livingsocial.com
 Mail Ops

 ___
 mailop mailing list
 mailop@mailop.org
 http://chilli.nosignal.org/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Mailbox full impact on delvierability

[Benjamin BILLON]

We enforce rules in our system to consider that after X consecutive soft 
bounces over at least Y days, then the email address will be excluded from 
further sending.

A fair example could be with X = 3 and Y = 21, but it depends on your habits 
too.

We consider it as a best practice behavior rather than a technical requirement. 
As you said, it helps keeping a good list hygiene.

Cheers,
--
Benjamin BILLON
Splio
Abuse, Compliance, ISP Relationship, Deliverability

De : mailop <mailop-boun...@mailop.org> De la part de David Hofstee
Envoyé : vendredi 18 mai 2018 17:41
À : Andy Onofrei <andrei.onof...@microsoft.com>
Cc : mailop@mailop.org
Objet : Re: [mailop] Mailbox full impact on delvierability

Hi,

So Gmail will 4xx this error (which is abnormal). I typically convert that into 
a 5xx bounce and be done with it (chances are low that the inbox will be 
emptied later). It gave me queueing issues too, delaying other emails (the 
gmail.com<http://gmail.com> queue was halted until this email was retried again 
in PowerMTA).

Yours,


David

On 18 May 2018 at 11:15, Andy Onofrei via mailop 
<mailop@mailop.org<mailto:mailop@mailop.org>> wrote:
HI,

I wanted for a long to hear some opinions about the impact which “mailbox full” 
soft bounces are having on the reputation.
If that should be treated as a hard bounce ( especially at big 4 Gmail, Yahoo, 
Hotmail ,Aol).

I have seen it retried 30-40 times until transformed into a hard bounce by the 
sending smtp server.

I know that this error is a red flag for a bad list hygiene , however from the 
point of view of the ESP .. its better just not to be retried?

Any thoughts are welcome.

Andrei Onofrei
Dynamics 365 Email Deliverability Engineer
andrei.onof...@microsoft.com<mailto:andrei.onof...@microsoft.com> | +420 720 
359 205
BBC Delta Building, Vyskočilova 1561/4a, 140 00 Prague, The Czech Republic
[cid:image001.jpg@01CE6679.2CA88280]



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



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

Re: [mailop] SNDS Volume Issue

[Benjamin BILLON]

Yes.
Similarly, some IPs sending more than 100 messages per day to Outlook.com don't 
get any line in SNDS.
The drop of volume you're mentioning might be an explanation to it.

--
Benjamin

De : mailop  De la part de Kent McGovern
Envoyé : jeudi 14 juin 2018 02:51
À : mailop 
Objet : [mailop] SNDS Volume Issue

Is anyone else seeing issues with the volume reported in SNDS? One of our 
senders who is on a dedicated IP consistently sends 120-150K/ day to 
Hotmail/Outlook, but starting June 6 SNDS is showing the volume in the low 
hundreds. Their complaint rate shot up in SNDS as well due to the decreased 
volume.

Thanks,

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

Re: [mailop] Hotmail SNDS page down?

[Benjamin BILLON]

It's back to normal for me, thanks!

--
Benjamin

De : mailop  De la part de Krishna Garewal via mailop
Envoyé : jeudi 26 avril 2018 09:36
À : John Stephenson ; Al Iverson 

Cc : mailop ; John Possidente ; 
Michael Wise ; Mohammed Ahmed 
Objet : Re: [mailop] Hotmail SNDS page down?

Thanks, forwarded the issue on.

From: John Stephenson 
>
Sent: Wednesday, April 25, 2018 6:30 PM
To: Al Iverson >
Cc: Krishna Garewal >; 
mailop >; John Possidente 
>; Michael Wise 
>; Mohammed Ahmed 
>
Subject: Re: [mailop] Hotmail SNDS page down?

I'm seeing the exact same thing on Safari on a Mac and on Chrome on a PC 
running Windows 10.  I am able to use the same credentials to login to 
Hotmail.com, but if I switch to the SNDS page, it keeps doing a number of 
redirects, then I get the verbiage Al posted.

Best,

John


On Wed, Apr 25, 2018 at 6:16 PM, Al Iverson 
> wrote:
Hi Krishna,

Still not able to access from here.

Using Safari on Mac (which I have used to access SNDS just fine before this 
issue), I now get stuck in loop pinging between URLs and then it spits out this 
error:
Sign in
Something went wrong and we can't sign you in right now. Please try again later.
The Microsoft account login server has detected too many repeated 
authentication attempts. Please wait a moment and try again.

Perhaps it's a browser issue but I figured I would pass this along since it was 
what was happening to me earlier today as well.

Cheers,
Al Iverson

On Wed, Apr 25, 2018 at 7:42 PM, Krishna Garewal via mailop 
> wrote:
Should all be working again, please let us know if you see any issues.

From: mailop > On 
Behalf Of Michael Wise via mailop
Sent: Wednesday, April 25, 2018 12:37 PM
To: John Possidente >; 
Mohammed Ahmed >
Cc: mailop >

Subject: Re: [mailop] Hotmail SNDS page down?


People are being poked, the issue is being worked. ☹

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

From: John Possidente >
Sent: Wednesday, April 25, 2018 7:28 AM
To: Mohammed Ahmed >
Cc: mailop >; Michael Wise 
>
Subject: Re: [mailop] Hotmail SNDS page down?

The CAPTCHA on the support page seems to be broken as well.

On Wed, Apr 25, 2018 at 9:54 AM, Mohammed Ahmed 
> wrote:
Hello Michael,

Looks like we are getting 503 error when trying to access SNDS data.  Just 
wanted to give you heads up.

[cid:image003.png@01D3DD56.9655D5D0]

Thanks,

--

Mohammed Ahmed
Director, Deliverability


___
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



--
al iverson // wombatmail // miami

Re: [mailop] Outlook - no blocks, but still not delivered

[Benjamin BILLON]

Hi Javed,

Just so you know, we are experience similar issues these days.

Made me re-read some history 
https://www.mail-archive.com/mailop@mailop.org/msg01969.html

Cheers,
--
Benjamin BILLON

De : mailop [mailto:mailop-boun...@mailop.org] De la part de Javed Ali
Envoyé : mardi 23 janvier 2018 06:57
À : Michael Wise <michael.w...@microsoft.com>
Cc : mailop@mailop.org
Objet : Re: [mailop] Outlook - no blocks, but still not delivered

Hi Michael,

Thanks for your quick response.

I've already requested escalations multiple times through the tickets and 
there's been no response after doing so. Our customer has also done the same 
through the ticket they've created. We've attempted to follow the formal 
channels for ~ 5 days but so far we're not having any luck.

The point of this list post was not solely to request an escalation, but to 
also seek advice from the industry to see if anyone else had experienced 
similar issues. I'd greatly appreciate any advice if others have experienced 
this issue before.

Javed Ali
Intergrid Group

On 23 January 2018 at 09:50, Michael Wise 
<michael.w...@microsoft.com<mailto:michael.w...@microsoft.com>> wrote:

This mailinglist is not for Outlook issue escalations.
All such need to be handled thru the tickets you have already opened.
And I make a point of not having any visibility into said tickets until when 
and IFF they are handed to me as escalations.

Any other way lies madness, sorry.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: mailop 
[mailto:mailop-boun...@mailop.org<mailto:mailop-boun...@mailop.org>] On Behalf 
Of Javed Ali
Sent: Monday, January 22, 2018 2:37 PM
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Outlook - no blocks, but still not delivered

Hi all,

Apologies for the list noise.

One of our IaaS customers is having issues with emails to Outlook. Delivery 
logs (via WHM) show that emails are being delivered to Outlook and accepted. 
There are no blacklist or block errors received.

However, emails are not being received in either the inbox or the spam folder 
of the receiver. The issue is isolated to Outlook/Hotmail recipients. These are 
legitimate corporate emails - nothing spammy.

We have tried to use the formal support channels but we either get template 
responses (there are no blocks; use SNDS and JMRP) or no response at all. We 
already use SNDS and JMRP, neither show issues for this IP.

Any assistance or advice would be greatly appreciated. If anyone from Outlook 
is on-list, the ticket numbers are SRX1412590030ID and SRX1412173041ID.

Cheers,

Javed Ali
Intergrid Group



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

[mailop] Gmail's dkim=neutral

[Benjamin BILLON]

Hi there!

I have a case where one sender's message has been abused, reused by someone who 
just added a Subject: line (so now there's two), before sending it.
Apparently the final recipient was at Gmail (given the headers I had access 
to), and logically:

  *   SPF failed: the domain name of the MAIL FROM didn't allow this IP, which 
is not mine, to send. Fine.
  *   dkim=neutral (body hash did not verify): here I'm puzzled. One of the 
purposes of DKIM being to validate the consistency of the content. If the body 
hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure 
fail?

Another question is how come the email hasn't been rejected already, with a 
failed SPF and a, let's say, neutral DKIM.
I don't know if it hit junk folder or not (I like to believe it did, but I 
still receive the complaint).

Side not: the recipient we initially send the first message to was also a Gmail 
user.

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

Re: [mailop] Gmail's dkim=neutral

[Benjamin BILLON]

Thanks for those details,

My understanding is that SPF was primarily conceived against spoofing, and not 
for reputation purposes.
It doesn't mean that spammers can't have a proper SPF. It doesn't mean that 
legitimate senders can't have no SPF.
On the other hand, there could be false positives (like automatic forwarding), 
but in this case DKIM should remain ok.

So when there's SPF, and it fails, AND there's DKIM, and it fails too, I guess 
we can consider that the trap is working as intended, and try to prevent a 
spoofing attempt from being successful.

But yeah, DMARC could help. With ISPs which actually check it.

Best,
--
Benjamin


From: Vladimir Dubrovin [mailto:dubro...@corp.mail.ru]
Sent: Friday, 26 January, 2018 19:32
To: Benjamin BILLON <bbil...@splio.com>
Cc: mailop@mailop.org
Subject: Re: [mailop] Gmail's dkim=neutral

26.01.2018 13:07, Benjamin BILLON пишет:
Hi there!

I have a case where one sender's message has been abused, reused by someone who 
just added a Subject: line (so now there's two), before sending it.
Apparently the final recipient was at Gmail (given the headers I had access 
to), and logically:

  *   SPF failed: the domain name of the MAIL FROM didn't allow this IP, which 
is not mine, to send. Fine.
  *   dkim=neutral (body hash did not verify): here I'm puzzled. One of the 
purposes of DKIM being to validate the consistency of the content. If the body 
hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure 
fail?


none:
The message was not signed.
fail:
The message was signed and the signature(s) is (were) acceptable to the 
verifier, but it (they) failed the verification test(s).
neutral:
The message was signed but the signature(s) contained syntax errors or were not 
otherwise able to be processed. This result SHOULD also be used for other 
failures not covered elsewhere in this list.
permerror:
The message could not be verified due to some error which is unrecoverable, 
such as a required header field being absent. A later attempt is unlikley to 
produce a final result.

There is no much difference between these states, any state different from 
"pass" and "temperror" means message is not actually signed correctly. Invalid 
hash means DKIM-Signature header doesn't match the message. Verifier can treat 
it as either invalid DKIM-Signature header (neutral) or verification failure 
(fail), there is no strict requirements and there is no practical difference.



  *

Another question is how come the email hasn't been rejected already, with a 
failed SPF and a, let's say, neutral DKIM.
I don't know if it hit junk folder or not (I like to believe it did, but I 
still receive the complaint).


Spammer can publish SPF and sign messages with DKIM.  The fact of DKIM presence 
or absence means nearly nothing. DKIM can be used by itself to use DKIM 
domain's reputation to validate message. Same goes to SPF. In the absence of 
DKIM or SPF, or if DKIM/SPF domains lacks reputation data, verifier can use 
reputation of IP address.

An exception is if SPF and DKIM are used as authentication method within DMARC 
policy. If you want message with your From address to be rejected in the 
absence of both valid DKIM and SPF authentication you have to publish 
restrictive DMARC policy.



Side not: the recipient we initially send the first message to was also a Gmail 
user.

Cheers,
--
Benjamin




___

mailop mailing list

mailop@mailop.org<mailto:mailop@mailop.org>

https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



--

Vladimir Dubrovin

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

Re: [mailop] Weird problems with mitigation at Hotmail/Outlook

[Benjamin BILLON]

Hi,

A reputation has to be evaluated on the long term of course, however the older 
the "action" was, the less importance it should have.

Another tricky part of "reputation", that we witnessed recently with Microsoft 
particularly, is that there are "links" created along with the reputation.
We know that Gmail takes into account a lot of things, not just headers, and 
keywords, and domain names, and IP addresses, and behavior of users, but also 
interactions between those, and other stuff.
We guess Microsoft does something similar.
So these "links" could be tricky, as we recently had Brazilian clients moving 
out to another ESP. They had dedicated IPs. We forbid them to send crap (that 
might be a reason why the left), but now they're free again, so crap it is.
The dedicated IPs, not sending anything anymore, have been blocked, as noticed 
in SNDS.
We suspect that because they are using the same domain name now with the new 
provider, than they did with us previously, and that now they are spamming from 
totally unrelated IPs, our IPs have been impacted. The fortunate part is that 
there's nothing going out of these IPs, because if we immediately re-attributed 
them to another client, maybe this client would have issues, and we would be 
investigating what he was doing wrong while it could be not his fault at all.

Maybe that could be solved after a few insistent tickets to the support.

Cheers,
--
Benjamin


From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Wise via 
mailop
Sent: Friday, 12 January, 2018 06:17
To: paul+mai...@oxygennetworks.com.au; 'Edgaras | SENDER' 
Cc: mailop@mailop.org; 'Tim Starr' 
Subject: Re: [mailop] Weird problems with mitigation at Hotmail/Outlook


Our reputation system has a *LONG* memory.
And I'm sure it's not alone.

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

From: Paul Julian [mailto:p...@oxygennetworks.com.au] On Behalf Of 
paul+mai...@oxygennetworks.com.au
Sent: Thursday, January 11, 2018 1:45 PM
To: Michael Wise 
>; 'Edgaras | 
SENDER' >
Cc: mailop@mailop.org; 'Tim Starr' 
>
Subject: RE: [mailop] Weird problems with mitigation at Hotmail/Outlook

Hi Michael,

Is there a reason why unused or newly allocated blocks seem to be automatically 
blocked for Outlook/Hotmail ?
We were recently allocated a new /22 for customers and every one of the 
customers who uses their own mailserver is getting blocked by MS, no spamming 
no history just blocked.
I realise that some systems work on reputation, but how can you get a good 
reputation if you can’t send the email in the first place ?

Is there some reason why whole blocks are just blocked by MS ? this seems to be 
the case with us.
What can network operators do to alleviate this problem for our customers ?
The customers look to us for a resolution as their provider, but apart from 
request that an address gets unblocked there is nothing more we can do, and 
unfortunately they don’t see it that way.
It’s unreasonable for us to think that we have to put in 1024 requests to get 
IP’s unblocked, which would all be rejected for mitigation initially, then you 
have to reply to the email and request again to have a chance of it being 
unblocked, that seems to be about a 50% hit rate for us.

Any thoughts on how to resolve this issue in a more efficient way would really 
be greatly appreciated.

Thanks
Paul

From: Michael Wise [mailto:michael.w...@microsoft.com]
Sent: Friday, 12 January 2018 6:31 AM
To: Edgaras | SENDER; Paul Julian
Cc: mailop@mailop.org; Tim Starr
Subject: RE: [mailop] Weird problems with mitigation at Hotmail/Outlook


"Pre-emptive Accommodation" is, I believe, the correct term.
And yes, it does help if it's before traffic actually starts.

Glad it got unblocked.

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

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Edgaras | SENDER
Sent: Thursday, January 11, 2018 12:18 AM
To: Paul Julian >
Cc: mailop@mailop.org; Tim Starr 
>; Edgaras | 

Re: [mailop] Delisting an IP Address from Outlook 365

[Benjamin BILLON]

AS16012609

Do they have that many different internal codes? =D

I got an IP suffering deferral, with the following number of codes:
293 AS843
249 AS844
  8 AS760
  7 AS3113
  6 AS3114
  2 AS761

One day, we'll figure it out :D

--
Benjamin


-Message d'origine-
De : mailop [mailto:mailop-boun...@mailop.org] De la part de Benoit Panizzon
Envoyé : vendredi 12 janvier 2018 17:44
À : Michael Wise via mailop 
Objet : [mailop] Delisting an IP Address from Outlook 365

Dear Michael

2018-01-12 09:59:11 SMTP error from remote mail server after RCPT
TO:: host 
nyfelermetallbau-ch01i.mail.protection.outlook.com [213.199.154.106]:
550 5.7.606 Access denied, banned sending IP [87.102.181.130]. To request 
removal from this list please visit https://sender.office.com/ and follow the 
directions. For more information please go to
http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) 2018-01-12
09:59:11 niklaus.blun...@nyfeler-metallbau.ch
P= R=dnslookup T=remote_smtp: SMTP error from remote 
mail server after RCPT
TO:: host 
nyfelermetallbau-ch01i.mail.protection.outlook.com [213.199.154.106]:
550 5.7.606 Access denied, banned sending IP [87.102.181.130]. To request 
removal from this list please visit https://sender.office.com/ and follow the 
directions. For more information please go to
http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609)

This static IP Address of one of our customers got blocked by Outlook 365.

We never got abuse complaints about that IP. Nor does our customer have a clue 
why his IP could be blocked.

Our customer did go thorugh the delisting process under 
https://sender.office.com/ and also I did the same proccess for his ip and I 
get confirmation:

The IP address in question is not currently blocked in our system.

But our customer tells me he still faces the same error message.

Could you enlighten me on why his IP is still blocked despite your tool telling 
it's not?

Mit freundlichen Grüssen

-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
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Trulia / Zillow contact

[Benjamin BILLON]

@Jaren, what action do you expect an ESP to take when their domain is being 
abused?

--
Benjamin

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Will Boyd via 
mailop
Sent: Saturday, 3 February, 2018 05:33
To: Jaren Angerbauer 
Cc: mailop 
Subject: Re: [mailop] Trulia / Zillow contact

I just came to the same conclusion as Steve. I don't work with that mailstream 
or domain, but I do work a bit with some folks at Zillow. I'm responding 
offline to Jaren.

Will

On Fri, Feb 2, 2018 at 2:26 PM, Steve Atkins 
> wrote:

> On Feb 2, 2018, at 12:22 PM, Jaren Angerbauer 
> > wrote:
>
> Hi,
>
> Looking for a contact Zillow, or even possibly their ESP.

That'd be mailgun, for this domain anyway, for anyone following along at home.

>  We are seeing one of their domains 
> (email.zillow-mail.com) being abused by 
> affiliate spammers.

Cheers,
  Steve


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



--
[sendgridlogo2.png]
Will Boyd
Email Deliverability Consultant
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Invalid address ratio?

[Benjamin BILLON]

> Yes, inbound. I'm wondering why there are so many mails to not-existing 
> recipients.
...
> Anything more than 5% bad recipients in mail sent by a given IP address will 
> land you in hot water with ... certain ISPs. 

Here's the explanation I give when I have to explain why high hard bounce rate 
= bad: once upon a time, spammers thought that maybe they'll manage to reach an 
existing email address if they tried to contact every combination of accepted 
characters in the user part of email addresses. Starting with a@, aa@, aaa@ to 
z@, with numbers or without. At some point they thought that 
using a dictionary of firstnames and/or lastnames could spare some time, as a 
lot of email addresses are built this way.
That was spam.
That generated a lot of hard bounces.
Receivers started to consider that lot of hard bounces = spam.


--
Benjamin

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Wise via 
mailop
Sent: Saturday, 3 February, 2018 04:29
To: ComKal Networks ; mailop@mailop.org
Subject: Re: [mailop] Invalid address ratio?




Anything more than 5% bad recipients in mail sent by a given IP address will 
land you in hot water with ... certain ISPs. 

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



-Original Message-
From: mailop > On 
Behalf Of ComKal Networks
Sent: Friday, February 2, 2018 9:02 AM
To: mailop@mailop.org
Subject: Re: [mailop] Invalid address ratio?



> I'm a bit surprised, that on a small mail server, 77 % of the rejected

> mails are rejected because of invalid recipient adresses. 22 % because

> of DNSBL.



> Is this ratio normal?



There abouts, email is free, for a certain class, so adding a lot of names to 
the left of the @ is very old school but also a lot of the scrappers end up 
with all those weird usernames like 
4ffb8ac-a0a-3cc0-e87c-65a3df124...@example.net

that appear in email headers as part of references in mailing lists etc.



The ratio does vary depending on age and usage a domain has had so I'm serious 
when I say it could vary as much as +10 -50%.







___

mailop mailing list

mailop@mailop.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop=02%7C01%7Cmichael.wise%40microsoft.com%7Cffc6c6cc14b5457f9bab08d56a5f8aa8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636531880955379727=bKGga8FuHuTWEXSkkYnAvJ%2BHhCuAfMrlXyh7OEdzDTM%3D=0
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mail Transfer Agent Alternatives

[Benjamin BILLON]

Hello,

Everything is always too expensive! However I can't say which of the software 
you mentioned is more expensive.

It doesn't seem GreenArrow and PowerMTA are providing the same thing. PowerMTA 
is an enhanced MTA, GreenArrow seems to have that, somewhere, but sells 
services too?
What features are you comparing exactly?
Are you looking for SparkPost instead of on-promise PMTA?

Anyway I believe another competitor would be MailerQ https://www.mailerq.com/

--
Benjamin


De : mailop [mailto:mailop-boun...@mailop.org] De la part de Emre Üst 
|euro.message|
Envoyé : lundi 5 février 2018 15:23
À : mailop@mailop.org
Objet : [mailop] Mail Transfer Agent Alternatives

Hello everyone ,
We are using Powermta(Port25) but their support service fee is rediciously high 
. We are looking for new mta . Could anyone recommend to Port25 altenatives ?
What are you thinking about GreenArrow - drh.net  ?
Thank you

--
[http://clients.euromsg.com/i/euromsg/2016/06/1/1_01.png]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

EMRE ÜST

Deliverability Specialist



t.   +902123430739
f.   +902123430742

email: emre@euromsg.com
skype: user_name
web: 
euromsg.com
Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul





[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_02.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_03.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_04.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_05.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_06.jpg]


[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

[http://clients.euromsg.com/i/relateddigital/sign/bnr.jpg]


[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_01.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_02.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_03.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_04.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_06.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_06.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_07.jpg]


[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]



This e-mail message may contain confidential or legally privileged information 
and is intended only for the use of the intended recipient(s). Any unauthorized 
disclosure, dissemination, distribution, copying or the taking of any action in 
reliance on the information herein is prohibited. E-mails are not secure and 
cannot be guaranteed to be error free as they can be intercepted, amended, or 
contain viruses. Anyone who communicates with us by e-mail is deemed to have 
accepted these risks. Related Digital is not responsible for errors or 
omissions in this message and denies any responsibility for any damage arising 
from the use of e-mail. Any opinion and other statement contained in this 
message and any attachment are solely those of the author and do not 
necessarily represent those of the company.




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

Re: [mailop] Trulia / Zillow contact

[Benjamin BILLON]

Ha yes, if you don't know if it's abused or just spam, the ESP must be in the 
loop, sure.

I understand nobody has the answer when this _is_ an abuse of domain use, so at 
least I'm not alone.
Good thing we'll discuss this in a few weeks.

--
Benjamin

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Jaren Angerbauer
Sent: Tuesday, 6 February, 2018 02:17
To: mailop <mailop@mailop.org>
Subject: Re: [mailop] Trulia / Zillow contact


On Fri, Feb 2, 2018 at 9:19 PM, Benjamin BILLON 
<bbil...@splio.com<mailto:bbil...@splio.com>> wrote:
@Jaren, what action do you expect an ESP to take when their domain is being 
abused?


Pretty much what Steve said, but to clarify further, if domain abuse is 
identified, and proactive communications are made to help raise awareness, the 
expectation is that the domain owner and/or their ESP work to stop said abuse, 
either intended or unintended.

From an outsider standpoint, it is sometimes hard to tell from just email 
headers if the abuse is originating from the client, or the ESP, and bringing 
both sides (sender and receiver) together to collaborate usually results in 
greater visibility on the problem and a quicker resolution.

Thanks,

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

Re: [mailop] Best practices for Google Postmaster Tools?

[Benjamin BILLON]

Hello,


> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far



> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/

https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/

https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/

no ETA, we tried to make some noise to raise priority, and hope to get some 
news in the coming weeks, but no guarantee



3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

Some big ESPs do it. They still seem alive today.

> We'd like to make more use of it, but the support around it is sparse right 
> now, and the information I've been able to find on how other ESPs are 
> implementing the data is also quite limited.

You might want to consider joining M3AAWG


Cheers,
--
Benjamin

De : mailop [mailto:mailop-boun...@mailop.org] De la part de David Carriger
Envoyé : vendredi 9 février 2018 11:19
À : mailop@mailop.org
Objet : [mailop] Best practices for Google Postmaster Tools?


The Google Postmaster Tools knowledge base is a bit light on information. I'm 
wondering if any of you have experience with the following:

1) Is there an upper limit on how many authenticated domains can be added for 
tracking?

2) Does anyone know if an API is planned/in the works for GPT?

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

We'd like to make more use of it, but the support around it is sparse right 
now, and the information I've been able to find on how other ESPs are 
implementing the data is also quite limited.



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com

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

Re: [mailop] Best practices for Google Postmaster Tools?

[Benjamin BILLON]

Hey Ryan,

I recall that when the errors happened at the end of last year 
(https://www.mail-archive.com/mailop@mailop.org/msg05260.html) I thought to 
myself how the heck of a job that would be to clean the mess for people who are 
scrapping the data.
That, and the not-so-huge need of doing it decreased the priority (and 
increased the innocent hope of the API) on my side.

--
Benjamin


De : Ryan Harris [mailto:r...@sendgrid.com]
Envoyé : vendredi 9 février 2018 12:12
À : Benjamin BILLON <bbil...@splio.com>
Cc : David Carriger <david.carri...@infusionsoft.com>; mailop@mailop.org
Objet : Re: [mailop] Best practices for Google Postmaster Tools?

Hello,

> 1) Is there an upper limit on how many authenticated domains can be added for 
> tracking?

I have 160+ domains and didn't hit a limit so far
Consider also applying dual dkim. It can be helpful to see all of your IPs 
reputation under a single, or handful of domains.


> 2) Does anyone know if an API is planned/in the works for GPT?

Yes

https://wordtothewise.com/2017/10/tell-us-use-gmail-postmaster-tools/

https://wordtothewise.com/2017/10/google-postmaster-tools-last-chance/

https://wordtothewise.com/2017/11/gmail-survey-rough-analysis/

no ETA, we tried to make some noise to raise priority, and hope to get some 
news in the coming weeks, but no guarantee
Every year it sounds like an API is "just around the quarter." At this point I 
think it's a story in a backlog that wont see the light of day for a long time.

3) Given the current lack of an API, does Google frown on scraping data from 
GPT?

Some big ESPs do it. They still seem alive today.

> We'd like to make more use of it, but the support around it is sparse right 
> now, and the information I've been able to find on how other ESPs are 
> implementing the data is also quite limited.

You might want to consider joining M3AAWG
Scraping is doable and allowed (I assume so long as you don't hammer away at 
their site), but it's scraping and can be painful at times. How senders are 
using postmaster.google.com<http://postmaster.google.com> data is a discussion 
that frequently happens at MAAWG.


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

Re: [mailop] Trulia / Zillow contact

[Benjamin BILLON]

> they know at least one person there with some interest in their email 
> reputation
That's quite a shortcut as they certainly know someone who's interested in good 
deliverability but that doesn't make know how it works. 
There _should_ be something who cares about the topic, yes.
But in the case of abuse I'd rather contact the legal department or something 
like this, although I don't see what they could do.

> Also, if they control the servers (as they do in this case, it being a CNAME 
> to mailgun.org) they are the responsible party, and likely the party that can 
> mitigate or fix the issue, if anyone can.
I don't get this point; if someone else abuses the domain name, how could the 
person responsible for the domain name take any action?

> Also, also if it's an affiliate issue that's generally a sign that the 
> customer has some serious problems that'll spill over into their legitimate 
> mail streams, so their ESP might want to be aware of that.
Yeah but that's not abusing a domain name, it's doing dumb things with expected 
consequences.

--
Benjamin


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Steve Atkins
Sent: Sunday, 4 February, 2018 00:39
To: mailop@mailop.org
Subject: Re: [mailop] Trulia / Zillow contact


> On Feb 2, 2018, at 8:19 PM, Benjamin BILLON <bbil...@splio.com> wrote:
> 
> @Jaren, what action do you expect an ESP to take when their domain is being 
> abused?

They can typically pass information on to someone appropriate at the client, as 
they know at least one person there with some interest in their email 
reputation.

Also, if they control the servers (as they do in this case, it being a CNAME to
mailgun.org) they are the responsible party, and likely the party that can 
mitigate or fix the issue, if anyone can.

Also, also if it's an affiliate issue that's generally a sign that the customer 
has some serious problems that'll spill over into their legitimate mail 
streams, so their ESP might want to be aware of that.

Cheers,
  Steve

>  
> --
> Benjamin
>  
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Will Boyd 
> via mailop
> Sent: Saturday, 3 February, 2018 05:33
> To: Jaren Angerbauer <jangerba...@proofpoint.com>
> Cc: mailop <mailop@mailop.org>
> Subject: Re: [mailop] Trulia / Zillow contact
>  
> I just came to the same conclusion as Steve. I don't work with that 
> mailstream or domain, but I do work a bit with some folks at Zillow. I'm 
> responding offline to Jaren.
>  
> Will
>  
> On Fri, Feb 2, 2018 at 2:26 PM, Steve Atkins <st...@blighty.com> wrote:
> 
> > On Feb 2, 2018, at 12:22 PM, Jaren Angerbauer <jarenangerba...@gmail.com> 
> > wrote:
> >
> > Hi,
> >
> > Looking for a contact Zillow, or even possibly their ESP.
> 
> That'd be mailgun, for this domain anyway, for anyone following along at home.
> 
> >  We are seeing one of their domains (email.zillow-mail.com) being abused by 
> > affiliate spammers.
> 
> Cheers,
>   Steve
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 
> 
>  
> --
> 
> Will Boyd
> Email Deliverability Consultant
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


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

Re: [mailop] Yahoo Support Page

[Benjamin BILLON]

How would you see it happen? 
HTTP forms can require certain information, and if bombing isn't totally 
impossible, captcha still can help greatly.

This thread is about Support and not Abuse, but both would be similar for big 
operators.
I believe that if you complain by email, your email will be parsed to enter a 
ticketing tool anyway, as the web form would have done. 

--
Benjamin

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Philip Paeps
Sent: Wednesday, 14 February, 2018 02:49
To: mailop@mailop.org
Subject: Re: [mailop] Yahoo Support Page

On 2018-02-13 15:07:33 (+0100), David Hofstee wrote:
>Ok... So this is the clue with the Yahoo form... There is a contact 
>form with a number of questions. One of the questions is
>
>
>*Copy the entire message which triggered the errorPlease remove < and > 
>characters around important information (e.g. IP addresses and email
>addresses).*
>
>*Don't do that*. Just paste the headers and maybe the text version. 
>Because the form is not POST-ed but GET-ed. This means that if you 
>message is too long for a URL (most cases in email marketing) then 
>stuff gets cut off at the end (and the processing fails).

Oh groan!

I really wish people would stop putting their abuse desks (etc) behind web 
forms.  The abuse came in via email.  Let us complain about it via email please.

The "everything over HTTP" culture is getting out of hand.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

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

Re: [mailop] VERP in 2018 (Was: RoadRunner Help?)

[Benjamin BILLON]

My 2cents: some ISPs require a manual registration based on the MAIL FROM email 
address (not just the domain name), hence VERP can't be used for them.

--
Benjamin Billon

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Stefano Bagnara
Sent: Saturday, 17 February, 2018 18:48
To: mailop <mailop@mailop.org>
Subject: [mailop] VERP in 2018 (Was: RoadRunner Help?)

On 17 February 2018 at 02:19, Michael Peddemors <mich...@linuxmagic.com> wrote:
> [...]
> And since the direction most MTA's go is to reduce any form of 
> 'bounce' or backscatter, the idea of using the VERP to detect 
> 'bounces' is probably not as important as it once was, unless the 
> emails are forwarded or client side
> bounces)

"Non as important as it once was" does not mean the same of "it is harmful".
I can agree that VERP is less effective than 10 years ago, but still it is the 
best way to detect some non deliverable email address.
Without VERP a small percentage of underliverable keep generating bounces that 
you can't associate to any address.
The main reasons for VERP to be less important today are:
1) much more receivers try to fail "in protocol" (but there are still many that 
do not)
2) much more bounces include the headers for the bounced message (and if you 
have the headers and you can parse them then VERP is not needed anymore.

Unfortunately there are still some server accepting everything and sending 
bounces without headers or malformed bounces.

> I personally believe that verp_respo...@esp.com is 'not' what good 
> ESP's should be doing, they should clearly reflect whom they are 
> sending for in the MAIL FROM, whether that be distinctive domain 
> representing whom the emails are for, or even better the person that it is 
> sending for.
>
> When a large operator sends millions of emails all with the same VERP 
> style/pattern, it does a disservice.
>
> Now, of course some (and not going to point out names here) ESP's 
> actually like the VERP method, because if they have ONE too big to 
> block company they represent, they can use that as an excuse to have 
> companies whitelist their @esp.com domain, allowing a higher delivery 
> account for all the other less clean lists and senders..

I don't think it is fair to think the reason ESPs use VERP is this one.
Neither they use @esp.com for this reason.

Most ESP put "per customer identifications" in the headers (most time it is 
List-ID, some have their own header.. but they don't try to hide the sending 
customer): you can block the mime from, or you can block via list-id.. so the 
"too big to block" doesn't see a very strong argument.

Using a return-path in the domain of your customer can be easy when you have a 
multi-thousands-dollars contract for each customer. But when you have "free" 
users or "few dollars per year" customers, you can't afford manually helping 
people to configure their domains so that you can use that in the return-path 
and then deal with major issues when the domain is "misconfigured" during a 
send.

AFAIK, VERP has been introduced to deal with mailing lists issues and not by 
some evil-ESP group.

> I think that transparency is important, and allows for the recipient 
> to make more informed choices as to the emails they want and don't want.

Have you ever tried to look at the List-ID header and other headers?
Also, most ESP don't alter the "mime from", so you can work on that for your 
reputation/spam.. if an ESP customer changes the mime from at every send and 
their ESP let them doing that to avoid spam filters then I suggest to ban the 
ESP. In the end, like any other sender (ESP are not so special), you will 
monitor some "rates" and decide if the sender is doing his antispam/antiabuse 
duties or not.

> Of course, this is ONLY my personal opinion.. The world is not 
> perfect, but the ESP's who are sending with clear transparency are 
> going to enable their legitimate email to have a lot higher success rates.

I'm not sure this would really happen to be true. Real world antispam filters 
are not that perfect too ;-) BTW I don't think that "ESP" in your arguments are 
worse than "any
sender": doesn't the transparency argument apply to non-ESP senders?

Do you manage any bulk sending service? Even a mailing lists would apply. If 
you don't use VERP, don't you see that kind of unidentifiable bounces I 
described above? How do you deal with them?
Do you force re-confirmation of each recipient every few months? (are your 
sending-customers happy with that?).

Stefano

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

Re: [mailop] Email issues to outlook.com and hotmail.com this afternoon/evening

[Benjamin BILLON]

Hi Frank, 

To answer the question: "not me", but any STMP reply that includes (AS[0-9]+) 
is related to spam detection/reputation issues.
Those "Server busy" without such codes can perfectly is that servers are, in 
fact, busy (so you should try again, maybe fallback a bit).

When talking with the support a few weeks back, we provided the proportion of 
each ASXXX numbers in our logs for a given IP/pool/client, as although I don't 
know what each code is about, that could help them spot something specific on 
their side (for the cases where I _know_ that there's no reason to consider the 
emails as spam).

Are you seeing many more "Server busy" without than with ASXXX ?

Hope that helps, 
--

Benjamin Billon

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of frnk...@iname.com
Sent: Thursday, 22 February, 2018 18:28
To: mailop@mailop.org
Subject: [mailop] Email issues to outlook.com and hotmail.com this 
afternoon/evening

Anyone else see email queued up to outlook.com and Hotmail.com domains?  It 
started around 5:30 pm U.S. Central and we're still seeing some issues.  

Here are some just some status logs from our email servers:

@outlook.com Site outlook.com (104.47.38.33) said after data sent:
452 4.3.1 Insufficient system resources (TSTE) 
[BL2NAM02HT002.eop-nam02.prod.protection.outlook.com]
[BL2NAM02FT001.eop-nam02.prod.protection.outlook.com]
@outlook.com ubad=-1386839216, Site (outlook.com/104.47.38.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.27].
(AS843) [BL2NAM02FT028.eop-nam02.prod.protection.outlook.com]
@hotmail.com ubad=-1678146736, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.28].
(AS843) [BN3NAM01FT001.eop-nam01.prod.protection.outlook.com]
@hotmail.com ubad=-1390394544, Site (hotmail.com/104.47.45.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.20].
(AS843) [CO1NAM04FT040.eop-NAM04.prod.protection.outlook.com]
@hotmail.com ubad=-1386839216, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.26].
(AS761) [BN3NAM01FT029.eop-nam01.prod.protection.outlook.com]
@msn.com ubad=-1386839216, Site (msn.com/104.47.6.33) said: 451
4.7.500 Server busy. Please try again later from [96.31.0.27]. (AS843) 
[VE1EUR02FT061.eop-EUR02.prod.protection.outlook.com]
@msn.com ubad=-1386839216, Site (msn.com/104.47.6.33) said: 451
4.7.500 Server busy. Please try again later from [96.31.0.20]. (AS843) 
[VE1EUR02FT047.eop-EUR02.prod.protection.outlook.com]
@outlook.com ubad=-1380134064, Site (outlook.com/104.47.38.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.27].
(AS843) [BL2NAM02FT023.eop-nam02.prod.protection.outlook.com]
@hotmail.com ubad=-1380134064, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.28].
(AS843) [BN3NAM01FT045.eop-nam01.prod.protection.outlook.com]
@hotmail.com ubad=-1402289328, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.27].
(AS843) [BN3NAM01FT056.eop-nam01.prod.protection.outlook.com]
@outlook.com ubad=-1537227952, Site (outlook.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.28].
(AS761) [BN3NAM01FT003.eop-nam01.prod.protection.outlook.com]
@hotmail.com ubad=-1537227952, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.20].
(AS843) [BN3NAM01FT047.eop-nam01.prod.protection.outlook.com]
@hotmail.com ubad=-1377012912, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.20].
(AS843) [BN3NAM01FT006.eop-nam01.prod.protection.outlook.com]
@outlook.com ubad=-1514519728, Site (outlook.com/104.47.38.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.20].
(AS843) [BL2NAM02FT017.eop-nam02.prod.protection.outlook.com]
@hotmail.com ubad=-1396481200, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.27].
(AS843) [BN3NAM01FT033.eop-nam01.prod.protection.outlook.com]
@msn.com ubad=-1495354544, Site (msn.com/104.47.6.33) said: 451
4.7.500 Server busy. Please try again later from [96.31.0.27]. (AS843) 
[VE1EUR02FT056.eop-EUR02.prod.protection.outlook.com]
@msn.com ubad=-1380134064, Site (msn.com/104.47.6.33) said: 451
4.7.500 Server busy. Please try again later from [96.31.0.28]. (AS843) 
[VE1EUR02FT036.eop-EUR02.prod.protection.outlook.com]
@hotmail.com ubad=-1398660272, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.27].
(AS843) [BN3NAM01FT058.eop-nam01.prod.protection.outlook.com]
@hotmail.com ubad=-1678146736, Site (hotmail.com/104.47.33.33)
said: 451 4.7.500 Server busy. Please try again later from [96.31.0.20].
(AS843) [BN3NAM01FT001.eop-nam01.prod.protection.outlook.com]
@outlook.com ubad=

Re: [mailop] Issue with Gmail Postmaster

[Benjamin BILLON]

Yes, same here.

IPs shown are mostly ours (although not used at all by the domain name), but 
also not ours (and potentially related to the given domain name, but I can't 
verify that)

This seems to be retroactive, as even data of beginning of September display 
this behavior.

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Vaibhav
Sent: Thursday, 28 December, 2017 12:23
To: mailop@mailop.org
Subject: [mailop] Issue with Gmail Postmaster

Hey,
Since past few days we observed that Gmail postmaster showing random IP's in IP 
reputation where same IP's is not used to sent out emails.
Gmail Postmaster showing random large no. of IP in IP reputation. Does anyone 
observed that the same ?
--Vaibhav
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Issue with Gmail Postmaster

[Benjamin BILLON]

Yes, fixed for me too.
It went from a lot of IPs, to just the dedicated one (for a given domain). 
Unfortunately I messed my screenshot so I can't illustrate the before/after ...

--
Benjamin

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Mark DiMaio via 
mailop
Sent: Friday, 29 December, 2017 09:41
To: Luke Martinez 
Cc: mailop@mailop.org; Mohammed Ahmed 
Subject: Re: [mailop] Issue with Gmail Postmaster

Google seems to have fixed the issue causing the reporting anomaly.  As of this 
evening things look back to normal across all monitored domains and IPs in our 
Google Postmaster account.  Anyone else seeing the same?


On Dec 28, 2017, at 12:44 PM, Luke Martinez via mailop 
> wrote:

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 
> wrote:
Google changed something early yesterday afternoon as this was fine up until 
then.  Observing this across the board here as well.


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



--
[https://sendgrid.com/brand/sg-logo-email.png]
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 mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft inbox placement issues

[Benjamin BILLON]

Hi David,

Can you share the headers such as X-Forefront-Antispam-Report:, 
X-Microsoft-Antispam:, X-Exchange-Antispam-Report-Test:, 
X-Exchange-Antispam-Report-CFA-Test:, X-Microsoft-Antispam-Mailbox-Delivery:, 
and whatever else relevant?

BTW this tool https://testconnectivity.microsoft.com/ could help visualize the 
headers more easily

In my cases of undoubtedly misplaced emails (in junk folder instead of inbox), 
I have some funky things such as:
-  BCL:8 (all indicators of complaints, including those provided by 
SNDS and JMRP, being at the lowest for months, I don't explain this score)
-  SFV:NSPM (so the content filter said "non-spam")
-  PCL:0 (nothing weird here)
-  SCL:1 ("Non-spam because the message was scanned and determined 
to be clean")
-  SPF, DKIM and DMARC results are "pass", MAIL FROM:, From: and d= 
domains are aligned
-  X-Microsoft-Antispam-Mailbox-Delivery: contains 
"RF:JunkEmail;OFR:SpamFilterAuthJ;" for the case when it's in junk folder

When these emails reach inbox (because they sometimes do), the _only_ notable 
difference is that this last header doesn't contain these RF: and OFR: 
information. There's just no mention of it. The rest is identical, even the 
BCL:8.

I'd be happy to gather similar cases so we could build a bigger and better 
argumentation (the objective being to ease Microsoft's job in fixing this), so 
don't hesitate to share on or off list.

Cheers,
Benjamin

De : mailop [mailto:mailop-boun...@mailop.org] De la part de David Carriger
Envoyé : mercredi 27 décembre 2017 05:27
À : mailop@mailop.org
Objet : [mailop] Microsoft inbox placement issues


Hi everyone,



I'm hoping someone here might be able to help. We're a small ESP that focuses 
on serving the small business market. In Return Path, we're seeing great inbox 
placement at Gmail, Yahoo and AOL, and terrible inbox placement at Microsoft. 
We use SNDS and JMRP already and neither seem to help. It doesn't matter 
whether I do a seed test from a green IP, yellow IP, or red IP, they all run 
into the same filtering issues. Even my seed test emails going out of 
transactional-only, always green IPs run into filtering problems.



I've opened several support tickets with Microsoft - SRX1407027597ID is the 
latest - but they seem completely unable to help. They just tell me that 
there's nothing wrong with the IPs, or that the filtering is due to 
SmartScreen, etc but provide nothing actionable that would help us fix the 
issue and improve our inbox placement.



We already monitor things like hard bounce rates, complaint rates, spam filter 
analysis, spam trap hits, etc. for all of our customers and take action on bad 
actors in our network. So far that's been working for us everywhere else, but 
not at Microsoft.



Any ideas of what we can do, or who to talk to, to get better inbox placement 
at Microsoft?



Small Business Growth Expert
DAVID CARRIGER
Linux Systems Administrator

--
david.carri...@infusionsoft.com

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

Re: [mailop] Microsoft inbox placement issues

[Benjamin BILLON]

I forgot to tell that besides the "RF:JunkEmail;OFR:SpamFilterAuthJ;" part, 
there's also "dest:J" (instead of "dest:I") that is different. However I'm not 
sure if this is the result of the filtering written here, or the result of the 
placement.

In my case (real campaign & all), I also clicked on "not a junk", but still 
receive it in junk folder most of the time.

I didn't check for transactional though, I'll give it a try too.

--
Benjamin

From: David Carriger [mailto:david.carri...@infusionsoft.com]
Sent: Wednesday, 27 December, 2017 23:54
To: Benjamin BILLON <bbil...@splio.com>; mailop@mailop.org
Subject: Re: Microsoft inbox placement issues


Thanks for the replies everyone. To clarify:

1) I am seeing the issue with seed tests.

2) I am seeing the issue with Return Path panel data.

3) I am seeing the issue when testing to personal mailboxes that I control.

So it is not an issue solely limited to seed testing, it is a real issue that I 
can confirm is happening to our customers with their mail. Microsoft tier 1 
support in India would have me believe that Microsoft's spam filters are the 
best in the world and everyone else is getting it wrong. Anecdotally, I've 
created a brand new Hotmail account, and sent an email from that account to 
itself, using their own webmail infrastructure, and had that email go to the 
spam folder. I've also spoken to people who have sent someone an email, had the 
recipient REPLY to that email, and that reply went to junk. It may be 
anecdotal, but if Microsoft can't get basic things like these right, they're 
not geniuses who are better at filtering spam than the rest of us. My hope is 
that if we could actually reach an engineer at the company and show them the 
cases where we believe their filtering is applying a wrong verdict, they would 
either agree and fix the filtering, or at least provide us information on how 
we need to treat their platform differently than everyone else's to avoid the 
issue.

Here are the headers from a transactional IP (SNDS green):

X-Forefront-Antispam-Report:
EFV:NLI;SFV:NSPM;SFS:(98901004);DIR:INB;SFP:;SCL:1;SRVR:BY2NAM03HT072;H:mta-c-24-30.infusionmail.com;FPR:;SPF:None;LANG:;

We have a good SCL and SFV verdict here.

X-Microsoft-Antispam:
BCL:2;PCL:0;RULEID:(5000109)(4604075)(4605076)(610169)(650170)(8291501071);SRVR:BY2NAM03HT072;

BCL and PCL are fine.

X-Exchange-Antispam-Report-Test:
UriScan:;

It was a plain text email with no URIs so nothing much to report here.

X-Exchange-Antispam-Report-CFA-Test:
BCL:2;PCL:0;RULEID:(444111537)(595095)(82015058);SRVR:BY2NAM03HT072;BCL:2;PCL:0;RULEID:(10803101)(100110400095);SRVR:BY2NAM03HT072;

The BCL and PCL still look good here.

X-Microsoft-Antispam-Mailbox-Delivery:
abwl:0;wl:0;pcwl:0;kl:0;iwl:0;dwl:0;dkl:0;rwl:0;ex:0;auth:1;dest:J;ENG:(41000128)(40012595)(5062000261)(5061607266)(5061608174)(4900095)(4920089)(6370004)(4950112)(4990090)(9140004);RF:JunkEmail;OFR:SpamFilterAuthJ;

Here we see the same behavior that you are, Benjamin, where we can see it's 
filtered to the junk folder. If I click "This isn't spam" and send again, it 
delivers to my inbox, but as an ESP we can't expect our customers to tell their 
customers "Our emails to you, including our transactional emails, will go to 
spam, and you have to click the button to tell Microsoft it's not spam."

From: Benjamin BILLON <bbil...@splio.com<mailto:bbil...@splio.com>>
Sent: Tuesday, December 26, 2017 11:28 PM
To: David Carriger; mailop@mailop.org<mailto:mailop@mailop.org>
Subject: RE: Microsoft inbox placement issues


Hi David,



Can you share the headers such as X-Forefront-Antispam-Report:, 
X-Microsoft-Antispam:, X-Exchange-Antispam-Report-Test:, 
X-Exchange-Antispam-Report-CFA-Test:, X-Microsoft-Antispam-Mailbox-Delivery:, 
and whatever else relevant?



BTW this tool https://testconnectivity.microsoft.com/ could help visualize the 
headers more easily



In my cases of undoubtedly misplaced emails (in junk folder instead of inbox), 
I have some funky things such as:

-  BCL:8 (all indicators of complaints, including those provided by 
SNDS and JMRP, being at the lowest for months, I don't explain this score)

-  SFV:NSPM (so the content filter said "non-spam")

-  PCL:0 (nothing weird here)

-  SCL:1 ("Non-spam because the message was scanned and determined 
to be clean")

-  SPF, DKIM and DMARC results are "pass", MAIL FROM:, From: and d= 
domains are aligned

-  X-Microsoft-Antispam-Mailbox-Delivery: contains 
"RF:JunkEmail;OFR:SpamFilterAuthJ;" for the case when it's in junk folder



When these emails reach inbox (because they sometimes do), the _only_ notable 
difference is that this last header doesn't contain these RF: and OFR: 
information. There's just no ment

Re: [mailop] Microsoft contact form has stopped working

[Benjamin BILLON]

This link works for me; however we're experiencing delays in answers after the 
first acknowledgment, automatic, answer.

One of my colleagues just told me he didn't get any news of his ticket since 
... June 14th.
I have two tickets opened yesterday, I'm patiently waiting for a bit more than 
the 24h of the SLAs I'm aware of.

--
Benjamin

De : mailop  De la part de Syed Alam
Envoyé : jeudi 21 juin 2018 16:24
À : mailop@mailop.org
Objet : [mailop] Microsoft contact form has stopped working

Some of IPs got blocked, both IPs have good mailing history,(>1 year) 
reputation is GREEN but on Tuesday it suddenly got blocked. The customer has 
requested mitigation 3 times in 48 hours but nothing heard back apart from 
ticket confirmation. Normally we see a reply that says qualified/not qualified 
for mitigation etc.

The following link as stopped working too.

http://go.microsoft.com/fwlink/?LinkID=614866

Does anyone have another link for mitigation? Appreciated.

--
Syed Alam

Postmastery
Amsterdam, NL
Skype: alam50
T: +31 20 261 0438
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Gmail's "Why is this message in Spam?"

[Benjamin BILLON]

Hello there, 

This is prone to change overtime, as my Internet research showed me some "spam 
reasons" visible in 2012, but I wonder about the little hint provided by Gmail 
these days.

The official help page (https://support.google.com/mail/answer/1366858) 
categorizes a few reasons, and I would regroup them this way:
Failing or missing authentication:
- Spoofed email addresses
- Phishing scams
- Messages from an unconfirmed sender

Some policy from receiver's side:
- Administrator-set policies
- You tried to unsubscribe from this sender
- Messages you sent to Spam

Spammy behavior:
- Messages content is empty

I (fortunately) rarely see any of those in my mailbox, most of the time the 
reason given (in a dark grey box, not the red one) is "It is similar to 
messages that were identified as spam in the past", which is rather vague but 
could be put in the "Spammy behavior" above category. Some of my own tests 
ended up in Spam folder with this reason, or used to. My guess is that the main 
issue is content related, the same or similar content sent by different senders 
having generated a lot of complaint.

However recently I'm getting significantly more "Lots of messages from 
[(sub)domain name] were identified as spam in the past", especially when 
sending from a (sub)domain for the first time, in an attempt to warm it up. And 
that confuses me because "lots" of messages "in the past" don't really fit with 
the actual traffic sent. 
GPT says the domains have "bad" or "low" reputation, so I guess this, plus the 
lack of history, is what this message is about.
And now, I can only hope it gets better at some point :D

Any similar experience over there? Other "spam reasons" worth mentioning? 

Cheers, 
--

Benjamin


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

Re: [mailop] DKIM headers - which do you sign and why?

[Benjamin BILLON]

Maybe it's not a coincidence, but Steve Atkins just made a post about that: 
https://wordtothewise.com/2018/07/minimal-dmarc/

I would tend to say that the more headers are included in the signature, the 
"safer" it gets (any change would be suspicious), but this is challengeable and 
it makes sense to look a bit closer at the detail of each header individually.

Some headers might be required to be added, such as X-CSA-Complaints and 
List-Unsubscribe, for CSA members: 
https://certified-senders.org/wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf.

--

Benjamin
From: mailop  On Behalf Of Autumn Tyr-Salvia
Sent: Friday, 20 July, 2018 07:18
To: Mailop 
Subject: [mailop] DKIM headers - which do you sign and why?

Hello Email Folks,

I work at Agari, where I guide large organizations through the process of 
getting their email to pass DMARC. I have lately had some customers with 
greater-than-usual issues relating to aligned authenticated messages that get 
forwarded, where the forwarding system is changing headers to the point that 
they break DKIM, and thus the messages fail and get rejected. The messages 
they're having trouble with are being sent from servers under their own control 
(and not third party vendors), and I have a sneaking suspicion that the issue 
is related to the specific headers they have chosen to sign.

I know signing the From: field is required by spec, but I think everything else 
is technically optional. For those of you who have been in the position of 
choosing which headers to sign and which not to, would you be open to sharing 
your reasoning with me? Any words of wisdom around headers they really should 
or should not sign?

Insight much appreciated!


Thanks,

Autumn Tyr-Salvia
tyrsalvia@gmail
atyrsalvia@agari
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AWS bring your own IP

[Benjamin BILLON]

Not sure of the detail of the implementation, but it's named "Bring Your Own 
IP", not "Bring your ranges", so it could not fit with ESPs' needs.
If it's about BGP announcement, it would probably still be announced by 
Amazon's ASN (being 16509, 14618 or another one), so the footprint is still 
there. Maybe OVH has a "bring your own IP" feature too, but I doubt many 
senders would use it if it was the case.

Note: I don't know much about AWS in general; also, we have our own ASN and 
we're LIR, that might not be the case for all ESPs.
--

Benjamin

From: mailop  On Behalf Of Alexander Burch
Sent: Thursday, 19 July, 2018 19:28
To: mailop@mailop.org
Subject: [mailop] AWS bring your own IP

Traditionally, ESPs have been unable to use AWS for sending mail because AWS 
IPs have very bad histories of being used for spam (among other reasons). I 
believe most ESPs are running their own servers for email or using a managed 
hosting service of some kind that allows them to use private IPs/rent private 
IP ranges. However, AWS just announced a "bring your own IP" program that 
caters to ESPs. This lets you use your privately owned IPs on AWS infra:

https://aws.amazon.com/about-aws/whats-new/2018/07/announcing-bring-your-own-ip-for-amazon-virtual-private-cloud-preview/

I think this could cause cause a shift in the way ESPs manage their mailing 
infrastructure. This makes it much more viable to send mail from AWS, which in 
turn is much more scalable than managing a colo machine or paying a managed 
hosting service and probably a lot cheaper.

I'd love to hear opinions on what negative effects anyone anticipates of using 
AWS + private IPs for their mail infrastructure.

Thanks,
Alex

--

[http://d226aj4ao1t61q.cloudfront.net/bdhmp3e9_email-logo.png]

Alexander Burch
ActiveCampaign / Deliverability Lead
abu...@activecampaign.com
1 North Dearborn Street, Suite 500, Chicago, IL 60602
[http://d226aj4ao1t61q.cloudfront.net/db8cckwrw_facebook.png]
 [http://d226aj4ao1t61q.cloudfront.net/bi4o8ru9u_twitter.png] 
  
[http://d226aj4ao1t61q.cloudfront.net/tambvza73_linkedin.png] 



[https://www.activecampaign.com/sig/?u=aburch]


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

Re: [mailop] AWS bring your own IP

[Benjamin BILLON]

As John said, the signup form mentions the minimum /24 requirement, so that 
seems better. Also, that would work with the theory of BGP announcement, as 
anything smaller than /24 would be filtered out by many networks.
I guess the requirement of having IPs provided by ARIN is related to the beta 
(otherwise only North America could use the feature).

> I wonder if this is true. If we own the IPs and have our own ASN wouldn't our 
> ASN be used?
No; the ASN announcing the range would be the one used. You could technically 
have your own ASN with no announcement.
A sub-allocation (see 
https://www.ripe.net/publications/docs/ripe-553#sub-allocations) would make 
that the ASN beneficiating from it will announce the range.

> However, that page explicitly lists email senders like ESPs as a use case:
> "Bring Your Own IP is also useful for applications such as commercial email 
> services that rely on IP address reputation to allow traffic from your 
> endpoints to reach intended recipients."
AWS announcing that their service is good for sending emails is nothing new, 
but it's also not an argument. For some reason, they seem to be insisting on 
this direction (having ESPs as clients). I guess that's what the boss said he 
wants.

--

Benjamin

From: Alexander Burch 
Sent: Friday, 20 July, 2018 00:30
To: Benjamin BILLON 
Cc: mailop@mailop.org
Subject: [mailop] AWS bring your own IP


I had the same initial concern that "bring your own Ip" != "bring thousands of 
your own IPs"



However, that page explicitly lists email senders like ESPs as a use case:

"Bring Your Own IP is also useful for applications such as commercial email 
services that rely on IP address reputation to allow traffic from your 
endpoints to reach intended recipients."



I can't say for sure without speaking to an AWS rep first.



The concern about ASN announcement is a good question. That's what I'm hunting 
after - "what traces of AWS would still be in the message fingerprint and how 
toxic would they be?"



I wonder if this is true. If we own the IPs and have our own ASN wouldn't our 
ASN be used?


On Thu, Jul 19, 2018 at 5:19 PM Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:
Not sure of the detail of the implementation, but it's named "Bring Your Own 
IP", not "Bring your ranges", so it could not fit with ESPs' needs.
If it's about BGP announcement, it would probably still be announced by 
Amazon's ASN (being 16509, 14618 or another one), so the footprint is still 
there. Maybe OVH has a "bring your own IP" feature too, but I doubt many 
senders would use it if it was the case.

Note: I don't know much about AWS in general; also, we have our own ASN and 
we're LIR, that might not be the case for all ESPs.
--

Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Alexander Burch
Sent: Thursday, 19 July, 2018 19:28
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] AWS bring your own IP

Traditionally, ESPs have been unable to use AWS for sending mail because AWS 
IPs have very bad histories of being used for spam (among other reasons). I 
believe most ESPs are running their own servers for email or using a managed 
hosting service of some kind that allows them to use private IPs/rent private 
IP ranges. However, AWS just announced a "bring your own IP" program that 
caters to ESPs. This lets you use your privately owned IPs on AWS infra:

https://aws.amazon.com/about-aws/whats-new/2018/07/announcing-bring-your-own-ip-for-amazon-virtual-private-cloud-preview/

I think this could cause cause a shift in the way ESPs manage their mailing 
infrastructure. This makes it much more viable to send mail from AWS, which in 
turn is much more scalable than managing a colo machine or paying a managed 
hosting service and probably a lot cheaper.

I'd love to hear opinions on what negative effects anyone anticipates of using 
AWS + private IPs for their mail infrastructure.

Thanks,
Alex

--

[http://d226aj4ao1t61q.cloudfront.net/bdhmp3e9_email-logo.png]

Alexander Burch
ActiveCampaign / Deliverability Lead
abu...@activecampaign.com<mailto:abu...@activecampaign.com>
1 North Dearborn Street, Suite 500, Chicago, IL 
60602<https://maps.google.com/?q=1+North+Dearborn+Street,+Suite+500,+Chicago,+IL+60602=gmail=g>
[http://d226aj4ao1t61q.cloudfront.net/db8cckwrw_facebook.png]<https://www.facebook.com/activecampaign>
 [http://d226aj4ao1t61q.cloudfront.net/bi4o8ru9u_twitter.png] 
<http://www.twitter.com/activecampaign>  
[http://d226aj4ao1t61q.cloudfront.net/tambvza73_linkedin.png] 
<https://www.linkedin.com/company/activecampaign-inc->


[https://www.activecampaign.com/sig/?u=aburch]<https://www.activecampaign.com/sig/?u=aburch=1>


--
Thanks,
Alex

--

[http://d226aj4ao1t61q.cloudfront.net/bdhmp3e9_email-logo.png]

Alexander 

Re: [mailop] QQ Postmaster

[Benjamin BILLON]

There's no "QQ postmaster contact" anymore. They out-humanized their support 
service (for a reason) and now only reply (sometimes) through an impersonal 
email address, if you write in Chinese.

If you got issues recently it's normal, they rebooted their quota/reputation 
system, back to 5K inbox emails a day. They apparently now make use of DKIM 
though, so there's that.

See http://openmail.qq.com/

--

Benjamin Billon

From: mailop  On Behalf Of Udeme Ukutt
Sent: Monday, 16 July, 2018 20:44
To: mailop 
Subject: [mailop] QQ Postmaster

Please can a QQ (China) postmaster (or someone that knows one) contact me 
off-list? Thanks.

Udeme
Postmaster at Wish

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

Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

[Benjamin BILLON]

(not Brooklyn? I'd gladly share a frosty beverage too)

--
Benjamin

From: mailop  On Behalf Of Laura Atkins
Sent: Wednesday, 29 August, 2018 22:29
To: Michael Wise 
Cc: mailop 
Subject: Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist 
with strange reputation issue


On Aug 29, 2018, at 12:10 PM, Michael Wise via mailop 
mailto:mailop@mailop.org>> wrote:


Agreed.
There are other ways of checking list sanity when a new customer presents it to 
you.
But many of the most promising ways to my mind are actively frowned upon.

We should sit down over cold frosty beverages next time we’re in the same town. 
(SF next feb? Budapest next June?)

laura


--
Having an Email Crisis?  We can help! 800 823-9674

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741

Email Delivery Blog: https://wordtothewise.com/blog






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

Re: [mailop] Issues delivering to Hotmail addresses

[Benjamin BILLON]

Some thingS are, but solely complaining here is not going to help them solve 
their (various) issues.

> 452 4.5.3 Recipients belong to multiple regions ATTR38 
> [CO1NAM03FT062.eop-NAM03.prod.protection.outlook.com]
Given the reply, I'd say it's related to the fact they have distinct nodes / 
regions, and that's a big oopsie. 
For O365, although not convenient, I understand the principle of having 
multiple tenants. (Who wants to use a single, integrated collaborative system 
for all worldwide offices, anyway? Yes, it is said in a sarcastic way)
For Hotmail, which is by essence a "global" service, it would lead to this kind 
of issues indeed 

--
Benjamin

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Charles McKean
Sent: Wednesday, 24 January, 2018 11:39
To: mailop@mailop.org
Subject: Re: [mailop] Issues delivering to Hotmail addresses

On Tue, Jan 23, 2018 at 9:41 PM, Joe Hamelin  wrote:
> It means they should have stuck to BSD and sendmail. ;)

Now somebody else will pop up and tell them to submit a ticket and they will 
reply that they have submitted 6 tickets and Microsoft isn't responding to them.

SOMETHING IS BADLY BROKEN OVER AT MICROSOFT, FOLKS.

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

Re: [mailop] Issues delivering to Hotmail addresses

[Benjamin BILLON]

Although indeed comical, I think we should all appreciate the level of details 
we have access to. It’s the kind of transparency which can help solve issues 
faster.

--
Benjamin

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Emre Üst 
|euro.message|
Sent: Wednesday, 24 January, 2018 17:47
To: mailop@mailop.org
Subject: [mailop] Issues delivering to Hotmail addresses

Hi Brad,
We are seeing lots of temporary errors ;

the funniest error is;

**  Error: "452 4.3.1 Insufficient system resources 
(UsedVersionBuckets[D:\Queue]) 
[AM5EUR03HT002.eop-EUR03.prod.protection.outlook.com]
 
[AM5EUR03FT002.eop-EUR03.prod.protection.outlook.com]"
 while connected from eg-c-5-031.euromsg.net 
(185.11.212.31) to 
hotmail-com.olc.protection.outlook.com
 (104.47.8.33)   *


Error: "451 4.4.0 Message failed to be made redundant due to A shadow copy was 
required but failed to be made with an AckStatus of Retry 
[DB5EUR03HT243.eop-EUR03.prod.protection.outlook.com]
 
[DB5EUR03FT029.eop-EUR03.prod.protection.outlook.com]"
 while connected from ) to 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33)

SMTP service unavailable: "421 4.4.1 Connection timed out. Total session 
duration: 00:14:19.6338392 
[DB5EUR03FT041.eop-EUR03.prod.protection.outlook.com]"
 received from 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33) while connected from eg- to 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33)


Error: "451 4.7.0 Temporary server error. Please try again later. PRX5 NextHop: 
DB5-EUR03b.hub.protection.outlook.com
 
[DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com]"
 while connected from  to 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33)


SMTP service unavailable: "421 4.3.2 The maximum number of concurrent server 
connections has exceeded a limit, closing transmission channel 
(DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com)
 
[DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com]"
 received from 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33) while connected from ) to 
hotmail-com.olc.protection.outlook.com
 (104.47.10.33)

SMTP service unavailable: smtp;451 4.7.0 Timeout waiting for client input 
[VE1EUR02FT032.eop-EUR02.prod.protection.outlook.com]

Error: "452 4.3.1 Insufficient system resources 
[AM5EUR03HT002.eop-EUR03.prod.protection.outlook.com]
 
[AM5EUR03FT002.eop-EUR03.prod.protection.outlook.com]"
 while connected from  to 
hotmail-com.olc.protection.outlook.com
 (104.47.8.33)














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

Re: [mailop] Hat color of list washers / validators

[Benjamin BILLON]

Wow, what did the CampaignMonitor folks eat? 
"Verifying emails is an email marketing best practice": guys, CONTEXT, please. 
Dropping catchy headlines like bombs is not making you any good. 
Then quoting someone about real-time verification in a part about "List decay" 
either his a badly orchestrated communication stunt, or pure stupidity.

> There *are* valid times to *validate* an email address in that manner
Yes, yes and yes. The only moment email validation is ok is real-time at the 
collection.
I've seen, to prevent typo domains, auto-completion or dropdown lists, first 
with most common domain names, then narrowing down to known domain names based 
on what the user it typing. No need to connect to anything to validate, here.
Then, to validate that the address is the right one, and that you're adding in 
your database the email address of the owner of the email address: confirmed 
opt-in. 
It's as simple as that. No need to think any further.

To me the list-validators are dark grey hats. Their real-time service can be 
legit. The rest, I don't see how.

--

Benjamin Billon

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Stefano Bagnara
Sent: Wednesday, 7 March, 2018 17:13
To: mailop <mailop@mailop.org>
Subject: Re: [mailop] Hat color of list washers / validators

On 2 March 2018 at 21:45, John Johnstone <jjohnstone-mai...@tridentusa.com> 
wrote:
> [...]
> It seems somebody gave some fairly purposeful thought into coming up 
> with the algorithms to generate these.  I'm curious to know what 
> peoples thinking is as to the hat color of these attempts.  
> Particularly if there are any opinions on the risk / need to block them.

Tools like hunter.io try to suggest you the "pattern" used by a company so that 
you can guess email address for named people, but they mainly use crawled data, 
so I think your suspect is findanyemail.net:
put a name and surname and your domain and it will try to guess the patterns 
and "verify" them.

That said, about the hat color

We're a small ESP and I think email validators/cleaners are making OUR life 
harder.

We can identify bad clients/customers as soon as they load their list if it 
contains very old expired domains, spamtraps, fake domains, emails like 
"e...@ail.jpg" or some .pdf TLD. Or we can identify "non confirmed" lists 
because of the presence of many typos domains. This let us block and vet the 
senders BEFORE they abuse our tool (and send spam).

But if they come with a cleaned list then it is harder for us and we have to do 
the first send in order to understand they are spammer, and sometimes when they 
have mostly b2b addresses it is hard because of missing FBLs from the providers 
and very low feedback from recipients that know it is spam.

I think that from a receiving MTA point of view, this is the same: if they hit 
your spamtraps (or simply invalid recipients) you have more chance to deal with 
them "correctly" and early.

So, from our point of view, bulk list validators are bad and I can't see a 
valid point to use them, but trying to trick the game (for short term spamming 
results).

That said, some ESP have a different opinion from me, as I just read this 
recent post:
https://www.campaignmonitor.com/blog/email-marketing/2018/03/verifying-emails-win-win-email-marketing/

I'm interested in how receivers see this email verification tools and how many 
of them deployed protections from them (e.g: identify their IPs and refuse or 
fake the answers to their requests or anything else).

Stefano

PS: between the many email verification tools, Kickbox
(https://kickbox.com/about) have a claim "Kickbox is a white hat service 
provider".

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

Re: [mailop] Hat color of list washers / validators

[Benjamin BILLON]

Good point.
However, things change, and this norm should evolve with the involved 
technologies; also, maybe this data quality process, if abusing third-parties 
resources (like RCPT TO: for nothing), is not an acceptable process.
Offline acquisition of online-related data (an email address, for instance) 
definitely is odd by definition. I don't know, just from the top of my head, 
print a QR code printed on the paper so users could register online, from their 
smartphone.

Also, if I'm not mistaking, list-validation services are mainly targeting 
online businesses, so even if the there might be legit cases, I doubt the 
biggest part of their revenues is.

--

Benjamin Billon

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Ken O'Driscoll via 
mailop
Sent: Wednesday, 7 March, 2018 20:20
To: mailop@mailop.org
Subject: Re: [mailop] Hat color of list washers / validators

On Wed, 2018-03-07 at 11:21 +, Benjamin BILLON wrote:
> To me the list-validators are dark grey hats. Their real-time service 
> can be legit. The rest, I don't see how.

There are some industries where offline data acquisition is the norm and 
validation is seen as part of the data quality process.

Insurance claim forms or change of contact details for $LEGACY_PROVIDER spring 
to mind.

Ken. 

--
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
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] Rambler.ru 20 seconds connection delay

[Benjamin BILLON]

Hello, 

I see delays in connections to @rambler.ru, with 20 seconds between the 
connection and ">>> 220 resmtp1.mail.rambler.ru Ok"

I guess I'm not the only one, but I don't know if it's the same for everyone, 
or if there are "reasons" for that to happen in some conditions.

Do you folks witness the same behavior? 

--
Benjamin

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

Re: [mailop] Rambler.ru 20 seconds connection delay

[Benjamin BILLON]

Thanks all for the feedback,

Same as you Andris, nobody is complaining, I was just putting my nose in my 
stats of time messages spend in queues and the difference with other domains 
struck me.

Cheers,
--
Benjamin

From: mailop  On Behalf Of Andris Reinman
Sent: Monday, 9 April, 2018 16:10
To: Dan Malm 
Cc: mailop 
Subject: Re: [mailop] Rambler.ru 20 seconds connection delay

Hi,
On our case I think we have always had a 20 sec delay between *every* SMTP 
command when sending to Rambler, so every message takes at least 60 seconds to 
deliver. Haven't been a problem, even though messages to Rambler might pile up 
temporarily if there's lot of trafic to this destination. Not enough traffic 
that anyone would complain, enough for us to notice.
Regards,
Andris Reinman
Zone Media LLC
https://www.zone.ee/en/

2018-04-09 10:50 GMT+03:00 Dan Malm >:
On 04/09/2018 04:23 AM, John Levine wrote:
> Simple theory: there are similar delays after EHLO and MAIL FROM, so
> they seem to be severly overloaded.  Don't take it personally. That's
> why your mail server can do a zillion connections at once.

As I saw a bunch of joomla sites with unprotected (or poorly protected)
account registration pages being abused to try and bomb 
rambler.ru
addresses this morning this theory sounds valid...

--
BR/Mvh. Dan Malm, Systems Engineer, One.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

Re: [mailop] SNDS returning 503 Service Unavailable

[Benjamin BILLON]

Same.
Maybe they're preparing an update?

(please be just that, please please please!)

--
Benjamin

De : mailop  De la part de Ewald Kessler | webpower
Envoyé : mercredi 25 avril 2018 16:57
À : mailop 
Objet : [mailop] SNDS returning 503 Service Unavailable

Good day,

SNDS seems to be having issues. It's returning a 503 Service Unavailable at 
https://postmaster.live.com/snds

Is it just me or is everybody else experiencing the same? Is Microsoft aware of 
the problem?

Regards,
Ewald
--
Deliverability & Abuse Management, 
www.webpower-group.com
ewald.kess...@webpower.nl
t: +31 342 423 262

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

Re: [mailop] Not receiving Y! local domains complaints

[Benjamin BILLON]

Hi Lindani,

You're not alone on this, although we still get yahoo.com.br and .co.uk at a 
"normal" level but .fr, .de, .it and .es are either very low or just missing.

[cid:image001.png@01D3DB56.B61C3A50]

There's something odd indeed.

Best,

--

Benjamin Billon

From: mailop <mailop-boun...@mailop.org> On Behalf Of Lindani Tshabangu via 
mailop
Sent: Monday, 23 April, 2018 22:20
To: mailop <mailop@mailop.org>
Subject: [mailop] Not receiving Y! local domains complaints

Good day,

We stopped receiving complaints from Yahoo's local domains 
(yahoo.fr<http://yahoo.fr>, Yahoo.es, Yahoo.de) but are receiving them normally 
from yahoo.com<http://yahoo.com>.
These stopped coming through on the 11th April to date.

Has anyone seen this kind of behaviour on their side?





Kind regards



Lindani Tshabangu
Deliverability EMEA | GROUPON

ltshaba...@groupon.com<mailto:ltshaba...@groupon.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Surge in Yahoo bounces

[Benjamin BILLON]

Yeah, two posts on Laura's blog: 
https://wordtothewise.com/2018/03/update-spike-yahoo-unknown-users/

I didn't see a huge surge in the first place, so I'm probably not the best 
witness for this ...

--

Benjamin Billon

From: mailop <mailop-boun...@mailop.org> On Behalf Of David Hofstee
Sent: Monday, 19 March, 2018 20:26
To: mailop <mailop@mailop.org>
Subject: [mailop] Surge in Yahoo bounces

Hi,

As some <https://wordtothewise.com/2018/03/update-spike-yahoo-unknown-users/> 
have seen there is a spike in Yahoo's "554 delivery error: dd This user doesn't 
have a yahoo.com<http://yahoo.com> account ...@<mailto:...@>..." bounces. It 
appears the bounces are incorrect and recipients should not be removed.

I was wondering when the event started. I have also seen a dip at bounces on 
the 17th and 18th but my stats for today do not have enough volume for me to 
conclude it is over yet. If anyone can comment?

Yours,


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

Re: [mailop] Libero.it delivery issues

[Benjamin BILLON]

Hello,

This isn't supposed to be temporary, it's been like this for months (although 
they're enforcing this gradually, I've heard of senders throttled 6 months ago, 
in my case it only started this summer). They're just not in the game anymore, 
they don't have enough resources. Users aren't receiving their emails, their 
market share might decrease in favor of Gmail.

--
Benjamin

From: mailop  On Behalf Of Robert Rubenking
Sent: mercredi 17 octobre 2018 02:49
To: Udeme Ukutt ; ltshaba...@groupon.com
Cc: mailop 
Subject: Re: [mailop] Libero.it delivery issues

Udeme,
I assume you have since received this notice, but for those that may not have a 
relationship with RP;


Libero.it email servers are overloaded and refusing a majority of connection 
attempts with the following error code:

"connect to smtp-in.libero.it[XX.XX.XX.XX]:25586: Connection refused"

We recommend that you temporarily send to Libero.it subscribers at a very slow 
rate to detect when or if connections are accepted. Should connections be 
refused at any send rate, we recommend that you temporarily stop sending to 
Libero.it subscribers for several hours and try again at a later time. Return 
Path is in contact with Libero and will provide updates as soon as they are 
available.



Bob










From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Udeme Ukutt
Sent: Tuesday, October 16, 2018 3:51 PM
To: ltshaba...@groupon.com
Cc: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Libero.it delivery issues

This email has reached Mapp via an external source

Lindani: Looking back the last seven days, I see *very very low* metrics for 
this.

Udeme

On Tue, Oct 16, 2018 at 11:27 AM Lindani Tshabangu via mailop 
mailto:mailop@mailop.org>> wrote:
Good day,

Today we  have  been experiencing delays from Libero & Virgilio.it in Italy,  
with errors ranging from  "No valid hosts" to "Too many connections slow down" 
while we have not changed anything on our side.
Has anyone else experienced this issue today?


Kind regards



Lindani Tshabangu
Deliverability EMEA | GROUPON

ltshaba...@groupon.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

Re: [mailop] Libero.it delivery issues

[Benjamin BILLON]

Update, from Return Path:

" The server performance at Libero has improved, but you still may see some 
reduced throughput or refused connections. Some senders have reported being 
able to send at normal send volumes. We recommend increasing send volume slowly 
until you observe SMTP bounce error codes indicating throttling or refused 
connections. "

I'm happy to read that; even though I don't witness it, I'm glad there's still 
someone in charge, and I'm convinced they're doing their best with the 
available resources.

Good luck!
--
Benjamin
From: mailop  On Behalf Of Benjamin BILLON
Sent: jeudi 18 octobre 2018 13:58
To: Stefano Bagnara ; mailop 
Subject: Re: [mailop] Libero.it delivery issues

[cid:image001.jpg@01D46A74.59E09CB0]

Something probably happened indeed.

By "not in the game anymore" I don't mean they don't have users anymore, I mean 
they don't care enough to maintain the resources they'd need to provide a good 
service to their users.

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Stefano Bagnara
Sent: mercredi 17 octobre 2018 12:13
To: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Libero.it delivery issues

On Wed, 17 Oct 2018 at 06:27, Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:
Hello,

This isn't supposed to be temporary, it's been like this for months (although 
they're enforcing this gradually, I've heard of senders throttled 6 months ago, 
in my case it only started this summer). They're just not in the game anymore, 
they don't have enough resources. Users aren't receiving their emails, their 
market share might decrease in favor of Gmail.

We almost never saw a connection refused by Libero in the past months, but 
yesterday.
Yesterday, instead, we recorded thousands of connection refused between 8AM and 
10AM (GMT+2): rest of the day and today everything is back to normal.

I have to say we only use 1 single connection per IP to Libero servers as we 
found Libero enforcing this limit too often to try to use more connections.

How do you say "they are not in the game"? we target mostly the italian users 
and I don't see this drastic market share issue for Libero. In terms of clicks, 
we saw a 2x increase from Gmail in a 24 month comparison, while other providers 
(everyone else) are almost stable over the same period. Clicks are a good 
"evidence" of the health of the inboxes. Libero+Virgilio (ItaliaOnLine) inboxes 
still counts 18% of clicks for a "mostly italian" user base.

Stefano

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

Re: [mailop] No SNDS confirmations for at least 5 days (was No SNDS data for last 2 days)

[Benjamin BILLON]

+1

I _did_ get a range (that mysteriously disappeared from my account) added last 
week, then 2 days later I requested to add another one (that also mysteriously 
disappeared) but never got the confirmation email.

--
Benjamin

From: mailop  On Behalf Of Annalivia Ford
Sent: mardi 23 octobre 2018 10:33
To: mailop 
Subject: Re: [mailop] No SNDS confirmations for at least 5 days (was No SNDS 
data for last 2 days)

Id like to note that we also are not getting the confirmation emails, and 
discussions on other mailing lists indicate this is not unique to us.

Michael, can you prod someone, please? And, hello back!

Regards,

Annalivia Ford
Email Services Manager, EMEA
[IBM Cognitive Engagement | Watson Marketing | Watson Commerce | Watson 
Marketing]

[IBM Watson]

Phone: +31 (0)6 53 32 34 44
eMail: annalivi...@nl.ibm.com












From:"Stefan Bauer" mailto:s...@plzk.de>>
To:"mailop" mailto:mailop@mailop.org>>
Date:11/10/2018 07:48
Subject:Re: [mailop] No SNDS data for last 2 days
Sent by:"mailop" 
mailto:mailop-boun...@mailop.org>>




Something is still broken here. Requested 2 IPs to be added to SNDS - so far 
did not even get a verification mail.

Stefan
-Ursprüngliche Nachricht-
Von: Michael Wise via mailop mailto:mailop@mailop.org>>
Gesendet: Dienstag 9 Oktober 2018 21:35
An: Laura Atkins mailto:la...@wordtothewise.com>>; 
Stefano Bagnara mailto:mai...@bago.org>>
CC: mailop mailto:mailop@mailop.org>>
Betreff: Re: [mailop] No SNDS data for last 2 days



Hmm.

I have no personal knowledge of this, and the person who I'd hand this off to 
is attending a conference on the East Coast 



Aloha,

Michael.

--

Michael J Wise
Microsoft Corporation| Spam Analysis

"Your Spam Specimen Has Been Processed."

Got the Junk Mail Reporting 
Tool ?



From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Laura Atkins
Sent: Tuesday, October 9, 2018 7:31 AM
To: Stefano Bagnara mailto:mai...@bago.org>>
Cc: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] No SNDS data for last 2 days



On 9 Oct 2018, at 15:00, Stefano Bagnara 
mailto:mai...@bago.org>> wrote:



It didn't work for me too until a couple of hours ago.

Now the web interface works again, but newer data is missing: the last day with 
data is October the 5th.



SNDS is the data collector. If the website isn't up then the data isn't being 
collected. MS has never filled in old data. As I understand it, they don't have 
the data to be able to backfill missing days.



laura






Stefano

On Tue, 9 Oct 2018 at 09:49, Stefan Bauer mailto:s...@plzk.de>> 
wrote:

Furthermore - the admin page is also broken and does infinite redirects:



https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx







-Ursprüngliche Nachricht-
Von: Joel Golliet mailto:j...@2lm.fr>>
Gesendet: Montag 8 Oktober 2018 17:57
An: mailop@mailop.org
Betreff: [mailop] No SNDS data for last 2 days

Hi everyone and outlook/hotmail team especially

we are unable to get data from our IP addresses from SNDS for saturday octobre 
the 6th 2018 and sunday the 7th.

I think we are not the only ones (?).

B.R.

--


* Joël GOLLIET | Ingénieur Infrastructure et Système
* 2L Multimedia - Park Nord, Les Pléiades, 74370 - Epagny-Metz-Tessy - FRANCE




Pensez à l'environnement, n'imprimez cet e-mail qu'en cas de réelle nécessité




___

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



--

Stefano Bagnara
Apache James/jDKIM/jSPF

Re: [mailop] Libero.it delivery issues

[Benjamin BILLON]

[cid:image003.jpg@01D466EA.97365DD0]

Something probably happened indeed.

By "not in the game anymore" I don't mean they don't have users anymore, I mean 
they don't care enough to maintain the resources they'd need to provide a good 
service to their users.

--
Benjamin

From: mailop  On Behalf Of Stefano Bagnara
Sent: mercredi 17 octobre 2018 12:13
To: mailop 
Subject: Re: [mailop] Libero.it delivery issues

On Wed, 17 Oct 2018 at 06:27, Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:
Hello,

This isn't supposed to be temporary, it's been like this for months (although 
they're enforcing this gradually, I've heard of senders throttled 6 months ago, 
in my case it only started this summer). They're just not in the game anymore, 
they don't have enough resources. Users aren't receiving their emails, their 
market share might decrease in favor of Gmail.

We almost never saw a connection refused by Libero in the past months, but 
yesterday.
Yesterday, instead, we recorded thousands of connection refused between 8AM and 
10AM (GMT+2): rest of the day and today everything is back to normal.

I have to say we only use 1 single connection per IP to Libero servers as we 
found Libero enforcing this limit too often to try to use more connections.

How do you say "they are not in the game"? we target mostly the italian users 
and I don't see this drastic market share issue for Libero. In terms of clicks, 
we saw a 2x increase from Gmail in a 24 month comparison, while other providers 
(everyone else) are almost stable over the same period. Clicks are a good 
"evidence" of the health of the inboxes. Libero+Virgilio (ItaliaOnLine) inboxes 
still counts 18% of clicks for a "mostly italian" user base.

Stefano

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

Re: [mailop] What do other ISP / ESP do about the MailChimp spam problem?

[Benjamin BILLON]

Could be discussed on Spam-L rather than here, but I believe you're talking 
about EasEye (no "y" in the middle); it's an ESP from Shanghai, noticeable in 
China.
Do you need to know something about them, or are you just stating they don't 
respect best practices --or laws?

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Michael Peddemors
Sent: mardi 6 novembre 2018 19:15
To: mailop@mailop.org
Subject: Re: [mailop] What do other ISP / ESP do about the MailChimp spam 
problem?

Like any organization, when the volume of unwanted exceeds the volume of 
wanted, you flag them... and let customers 'This is not junk' the ones they 
want.

Only way around this conundrum is to empower your users.

And while we also see they abuse problem, as pointed out they aren't the worst..

Speaking of, has anyone heard of a player using Chinese IP space called 
EasyEye, using 118.192.64.0/21 IP Space?

So far, only seen them in spam reports, but they might be a new player..



On 2018-11-06 3:53 a.m., Benoit Panizzon wrote:
> Hi List
> 
> We again face problems with services by MailChimp.
> 
> Their platform is equally fashioned by serious companies sending 
> permission based newsletters and by very persistent repetitive spamer.
> 
> They repeatedly get blacklisted on our platform, because of recipient 
> complaints.
> 
> Then repeatedly customers having subscribed to newsletters from 
> serious companies complain to us, because mailchimp is blocked by our 
> anti-spam services.
> 
> The customer reporting spam are not those who subscribed to 
> newsletters, forget about it and them report opt-in emails as spam.
> 
> No, the problem is that MailChimp operates under 'US' marketing laws 
> where the sender is only obliged to provide an 'opt-out' link in spam 
> he sends and does not have to require the recipient to have a 
> validated opt-in to get advertisement emails.
> 
> So often, the spamers use harvested email addresses (even spamtraps we 
> have hidden of websites) or lists they bought online.
> 
> The other problem is about GDPR, where laws in most European countries 
> require the sender of advertisement to disclose the source of data of 
> a recipient to this recipient.
> 
> Spamers sending email over mailchimp are clever. The links in the 
> email point to some anonymous redirection services to mailchimp 
> themselves or to domains registered via anonymizing proxies. Payment 
> work over paypal and if you have been trying to get at the identity of 
> a fraudster who took money via paypal, you know this is not possible. 
> So the recipient of spam needs to contact the 'sender' aka MailChimp 
> and requires MailChimp to disclose the identity of the sender, which 
> MailChimp then again rejects pointing to US privacy laws which require 
> them not to disclose the identity of their customers. Safe Heaven for 
> Spamer!
> 
> MailChimp does close accounts for which they get a certain number of 
> complaints, but they fail to recognize and block the same spamer who 
> repeatedly opens news accounts.
> 
> So what do you think should ISP and Email Plattform operators do about 
> MailChimp?
> 
> * Tell the customers complaining about spam they have to live with it?
> * Block MailChimp and tell serious companies who get blocked as
>collateral damage, to look for another, not so spamer firendly ESP?
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
> 



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For 
More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard 
Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended 
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely those 
of the author and are not intended to represent those of the company.

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

Re: [mailop] How to say "bounced" in German

[Benjamin BILLON]

https://certified-senders.org/wp-content/uploads/2017/08/CSA-Aufnahmekriterien.pdf

" wenn drei Hard Bounces erfolgten"
" Insgesamt darf die Hard-Bounce-Rate"

Seems you can say "Bounce"

--
Benjamin

From: mailop  On Behalf Of Alexander Burch
Sent: mardi 6 novembre 2018 17:51
To: mailop 
Subject: [mailop] How to say "bounced" in German

What would be an appropriate translation of "bounced" in German? The current 
options I have heard are:

“Kahm zurück”
“Kam zurück”
“Rückläufer”

Thanks,
Alex

--

[https://d226aj4ao1t61q.cloudfront.net/cy3nisxfd_ac_logo-circle.png]

Alexander Burch
ActiveCampaign / Deliverability Engineer
abu...@activecampaign.com
1 North Dearborn St Suite 500, Chicago IL, 60602
[https://d226aj4ao1t61q.cloudfront.net/ys2h3to2m_email-facebook.png]
 [https://d226aj4ao1t61q.cloudfront.net/tc3x0kcsn_email-twitter.png] 
  
[https://d226aj4ao1t61q.cloudfront.net/y1t0ztxcr_email-linkedin.png] 
  
[https://d226aj4ao1t61q.cloudfront.net/j14l6ck9n_email-google.png] 



[https://www.activecampaign.com/sig/?u=aburch]
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google Postmaster Tools lagging several days behind?

[Benjamin BILLON]

You
are not
alone

--
Benjamin
From: mailop  On Behalf Of Robert Rubenking
Sent: vendredi 9 novembre 2018 20:53
To: mailop 
Subject: [mailop] Google Postmaster Tools lagging several days behind?

Anyone else seeing a longer than typical delay in updates?  Even my most active 
domains have not updated since 11/5.

Mark/Brandon any insights?


Thanks,
Bob

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

Re: [mailop] SNCD.ORG - Signal Spam

[Benjamin BILLON]

Yup!

--
Benjamin

From: mailop  On Behalf Of Emre Üst |euro.message|
Sent: mardi 13 novembre 2018 15:14
To: mailop 
Subject: [mailop] SNCD.ORG - Signal Spam

Hello List ,

We are currently working as a partner with CSA in Germany . And we want to 
become members of SNCD.ORG and Signal -Spam . Is there anybody 
from SNCD  and Signal Spam ?

Thank you .

--
[http://clients.euromsg.com/i/euromsg/2016/06/1/1_01.png]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

EMRE ÜST

Technical Support Team Leader



t.   +902123430739
f.   +902123430742

email: emre@euromsg.com
skype:
web: 
euromsg.com
Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul





[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_02.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_03.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_04.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_05.jpg]

[http://clients.euromsg.com/i/euromsg/2016/06/1/2_06.jpg]


[http://clients.euromsg.com/i/euromsg/2016/06/1/2_01.jpg]

[http://clients.euromsg.com/i/relateddigital/sign/bnr.jpg]


[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_01.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_02.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_03.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_04.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_06.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_06.jpg]

[http://clients.euromsg.com/i/relateddigital/2017/04/17/1/1_07.jpg]









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

Re: [mailop] What do other ISP / ESP do about the MailChimp spam problem?

[Benjamin BILLON]

Hi Michael, 

> how long they have been in business
I've seen emails from them since 2009

> how big the IP space is
I can't say; they used other ranges back in 2009, but that can legitimately 
evolve over the years

> and their relationship to the parent in the SWIP, etc..
You won't get any reliable WHOIS information from China. They have a limited 
number of operators (and ASNs) and a NIR (CNNIC) that doesn't require to 
declare who the IP space is used by.

> And whether the ESP is actually from china, or a North American operator 
> operating off shore..
Chinese from China. They might have a few Chinese clients sending emails in 
other countries, OR could be starting to expand in North America (although I 
didn't witness that), but it's very unlikely they are operating off shore. One 
of the main reason is that they send emails from Chinese IPs, and you just 
can't do that if you're not from there.


Cheers, 
--
Benjamin

-Original Message-
From: Michael Peddemors  
Sent: mardi 6 novembre 2018 20:22
To: Benjamin BILLON ; mailop@mailop.org
Subject: Re: [mailop] What do other ISP / ESP do about the MailChimp spam 
problem?

On 2018-11-06 11:10 a.m., Benjamin BILLON wrote:
> Could be discussed on Spam-L rather than here, but I believe you're talking 
> about EasEye (no "y" in the middle); it's an ESP from Shanghai, noticeable in 
> China.
> Do you need to know something about them, or are you just stating they don't 
> respect best practices --or laws?
> 
> --
> Benjamin

More curiosity, how long they have been in business, how big the IP space is, 
and their relationship to the parent in the SWIP, etc..

Received: from mx216.sx64.email-deliver.com (HELO
mx216.sx64.email-deliver.com) (118.192.64.216)

No URL related to email-deliver.com, (or many of the other domains in use), and 
not much to go by in headers..

X-EASEYEUID: 7889443-272549-542-6580
Precedence: bulk
X-Easeye-ExpirationDate:  2018-11-13 19:24:43
List-Unsubscribe: 
<mailto:unsub-7889443-272549-542-6...@unsub.email-deliver.com?subject=unsubscribe>
X-PRECENDENCE: 0
X-Easeye-MailSeq: 4
X-DELAYHEADER: 0-0-5-0

And whether the ESP is actually from china, or a North American operator 
operating off shore..




> 
> -Original Message-
> From: mailop  On Behalf Of Michael Peddemors
> Sent: mardi 6 novembre 2018 19:15
> To: mailop@mailop.org
> Subject: Re: [mailop] What do other ISP / ESP do about the MailChimp spam 
> problem?
> 
> Like any organization, when the volume of unwanted exceeds the volume of 
> wanted, you flag them... and let customers 'This is not junk' the ones they 
> want.
> 
> Only way around this conundrum is to empower your users.
> 
> And while we also see they abuse problem, as pointed out they aren't the 
> worst..
> 
> Speaking of, has anyone heard of a player using Chinese IP space called 
> EasyEye, using 118.192.64.0/21 IP Space?
> 
> So far, only seen them in spam reports, but they might be a new player..
> 
> 
> 
> On 2018-11-06 3:53 a.m., Benoit Panizzon wrote:
>> Hi List
>>
>> We again face problems with services by MailChimp.
>>
>> Their platform is equally fashioned by serious companies sending
>> permission based newsletters and by very persistent repetitive spamer.
>>
>> They repeatedly get blacklisted on our platform, because of recipient
>> complaints.
>>
>> Then repeatedly customers having subscribed to newsletters from
>> serious companies complain to us, because mailchimp is blocked by our
>> anti-spam services.
>>
>> The customer reporting spam are not those who subscribed to
>> newsletters, forget about it and them report opt-in emails as spam.
>>
>> No, the problem is that MailChimp operates under 'US' marketing laws
>> where the sender is only obliged to provide an 'opt-out' link in spam
>> he sends and does not have to require the recipient to have a
>> validated opt-in to get advertisement emails.
>>
>> So often, the spamers use harvested email addresses (even spamtraps we
>> have hidden of websites) or lists they bought online.
>>
>> The other problem is about GDPR, where laws in most European countries
>> require the sender of advertisement to disclose the source of data of
>> a recipient to this recipient.
>>
>> Spamers sending email over mailchimp are clever. The links in the
>> email point to some anonymous redirection services to mailchimp
>> themselves or to domains registered via anonymizing proxies. Payment
>> work over paypal and if you have been trying to get at the identity of
>> a fraudster who took money via paypal, you know this is not possible.
>> So the recipient of spam needs to contact the 'sender' aka MailChimp
>> and req

Re: [mailop] Is SenderID deprecated? (Udeme Ukutt)

[Benjamin BILLON]

Thanks for the reply!

Although this apparently isn't new, I'll consider this a milestone as we just 
removed spf2.0 records from our settings guidelines.

Smartscreen for email is deprecated on Exchange onPrem ... but isn't it also in 
O365 and Outlook.com, since those rely on EOP? The copy/pasted answers from the 
Outlook.com Support still mentions Smartscreen heavily.
That being said, the said Support is also named " Hotmail Sender Support ", 
maybe they didn't get the memo about Outlook.com =)

Cheers,
--
Benjamin

From: mailop  On Behalf Of Mihai Costea
Sent: jeudi 4 octobre 2018 19:21
To: mailop@mailop.org
Subject: Re: [mailop] Is SenderID deprecated? (Udeme Ukutt)


Hi



There are no reasons to worry about old Exchange onPrem servers spam filters as 
nobody relies on them anymore.

We stopped issuing filter updates two years ago and the filter itself stopped 
receiving new features well before that.

https://blogs.technet.microsoft.com/exchange/2016/09/01/deprecating-support-for-smartscreen-in-outlook-and-exchange/



"no record" never had any impact in the SenderID agent.

"Auth fail -> hard fail" was not wise policy to enable due to complex routing 
false positives.

Auth pass was fed into the smartscreen (content filter) in Exchange as a 
positive email feature, assuming legit senders will auth more than spammers.  
Which was a bad assumptions as spammers were in fact the earliest adopters.

No record never had any impact.



Everything is SPF these days in both O365 and Outlook.com.  Some headers might 
mention PRA/PRD as the entity among all the sender related headers that was 
selected to do the check against, but this selection is done the SPF way.



>From any practical pov SenderID is deprecated.

For the email historians, Terry had at least a hundred blogs on auth over the 
years.

e.g. 
https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/
Sender authentication part 17: Hazards of SenderID and SPF 
...<https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/>
blogs.msdn.microsoft.com
Both SenderID and SPF have their critics. I'd like to touch on two potential 
problems with them: the first is the issue of email forwarding. There's no 
official standard on how email is to be forwarded (in terms of rewriting the 
headers). Suppose that Mail Server A sends the message and everything complies 
with SenderID...







> Message: 3
> Date: Thu, 4 Oct 2018 08:45:58 +
> From: Benjamin BILLON mailto:bbil...@splio.com>>
> To: "mailop@mailop.org <mailto:mailop@mailop.org>"  <mailto:mailop@mailop.org>>
> Subject: [mailop] Is SenderID deprecated?
> Message-ID:
> 
>   
> <mailto:he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com>>
>
> Content-Type: text/plain; charset="utf-8"
>
> The RFC 4406 is not obsolete, only experimental.
>
> In the past, Hotmail/Live heavily relied on it, but it's not even visible in 
> Outlook's headers anymore (advantageously replaced by DKIM, and DMARC). So 
> Hotmail's out.
>
> Microsoft Exchange servers also used it, but it's not clear it's still the 
> case.
> The article 
> https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/sender-id?view=exchserver-2019
>  
> <https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/sender-id?view=exchserver-2019>
>  says "basically unchanged from Exchange Server 2010", which kind of scares 
> me. But the page also says it checked the "RECEIVED SMTP header", so 
> basically the HELO/EHLO; it mentions the PRA, but it's not the definition I 
> knew (nor what's in the RFC): "The IP address of the authorized sending 
> server is referred to as the purported responsible address (PRA).".


> In short, I don't understand this article and I'm glad I'm not administrating 
> an Exchange server right now.
>
> In my _opinion_, only old (non-updated) Exchange servers might reject or 
> consider negatively emails with missing SenderID record in their sending 
> domains, so it _should_ be ok to stop setting up these records.
>
> Dear Microsoft folks around there, what's the status of it from your 
> perspective?
>
> Cheers,
> --
> Benjamin
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to find 'low flying' spamers? (Re: outlook.com blocking reason: S3150 "network is on our block list")

[Benjamin BILLON]

Hi Benoit, 

I assume you already checked M3AAWG's BCPs? 
https://www.m3aawg.org/published-documents
I'm not familiar with _all_ of them, but that's a good source of ideas anyway. 

Cheers, 
--
Benjamin

-Original Message-
From: mailop  On Behalf Of Benoit Panizzon
Sent: Monday, 1 October, 2018 11:23
Cc: mailop@mailop.org
Subject: [mailop] How to find 'low flying' spamers? (Re: outlook.com blocking 
reason: S3150 "network is on our block list")

Hi List

Well thank you for all the hints. I also (thanks to Al) found out, that you 
need to set the browser language to english, to get to the propper help page 
where the delisting request form can be found. With german, you're lost :-)

But I would like to use that topic on a discussion about what to do to mitigate 
abuse of an ISP email platform.

I believe we do much to mitigate abuse from our email platform, but perhaps, 
there is more that can be done. So tell me how you 'do' it and where you see 
potential for improvement.

First let me explain what we do...

We are a classical end user ISP. Our customers are private households with an 
internet connection and some companies. We encourage companies to use an own 
mailserver. We do not offer any 'relay' services to them, so we won't get the 
crap some hacked company servers produce via our mail platform (of course our 
abuse desk also deals with them, to notify those customers in our AS).

So we mainly get the usual problems with customers who hand out their email 
credentials in reply to phishing emails or get trojans who steal them from 
their computers.

To mitigate those problems we have implemented those mechanisms:

* Require minimal password strength.
* Require SMTP Authentication.
* Keep cache history from which IP an SMTP Authentication occurred.
* If count(IP) in delta time > IPlimit block account and require
  password change.
* If count(geoIP) in delta time > Geolimit block account and require
  password change.

Some exception for google services and local mobile networks NAT which use a 
different ip for each SMTP connections.

* If count(recipients) in delta time > RecipientLimit - tempfail and
  notify postmaster to check manually.

We also use account encapsulated SRS for forwarded emails, so we can detect 
bounces from the far side and deactivate bouncing forwards to limit backscatter 
to a minimum.

Of course, this fails if the phished account keeps below our radar by using a 
single ip address and sending emails slowly to keep below the tempfail 
threshold.

In this case we rely on feedback loops to 'react' and also sometimes on 
customers reporting the bounces their phished account produces as spam :-)

What else could we do?

Mit freundlichen Grüssen

-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
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Is SenderID deprecated?

[Benjamin BILLON]

The RFC 4406 is not obsolete, only experimental.

In the past, Hotmail/Live heavily relied on it, but it's not even visible in 
Outlook's headers anymore (advantageously replaced by DKIM, and DMARC). So 
Hotmail's out.

Microsoft Exchange servers also used it, but it's not clear it's still the case.
The article 
https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/sender-id?view=exchserver-2019
 says "basically unchanged from Exchange Server 2010", which kind of scares me. 
But the page also says it checked the "RECEIVED SMTP header", so basically the 
HELO/EHLO; it mentions the PRA, but it's not the definition I knew (nor what's 
in the RFC): "The IP address of the authorized sending server is referred to as 
the purported responsible address (PRA).".
In short, I don't understand this article and I'm glad I'm not administrating 
an Exchange server right now.

In my _opinion_, only old (non-updated) Exchange servers might reject or 
consider negatively emails with missing SenderID record in their sending 
domains, so it _should_ be ok to stop setting up these records.

Dear Microsoft folks around there, what's the status of it from your 
perspective?

Cheers,
--
Benjamin


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

Re: [mailop] Spamcop IP blacklisted

[Benjamin BILLON]

> if the email isn't opened, or there is no show of interest over the course of 
> the past 3 - 6 months ... It's mailing malpractice

Hi Michael, I believe you're working in a different department than the one in 
charge of Outlook.com filtering, so I don't make a direct link between your 
statement and how Outlook.com filters are working.

BUT. I couldn't agree* with a filtering system that assumes that this or that 
email is spam because it's unread, and I would consider that decreasing the 
overall reputation of the sender's domain/IP based on this sole criteria is 
malpractice.
There's definitely that part where ISPs are receiving and hosting a lot of 
emails that are unwanted and unread. That's literally money for nothing, and 
this is a real problem for all receivers.
But there are also those emails that we receive and never read, but that we 
want to keep anyway. Bank statements. Order confirmation. That newsletter about 
woodworking tips. Or that one about dreamy holidays that I'd check for the next 
vacation, or the next one, or the next one ...
Messages delivered (or automatically moved at a later time) in junk folder will 
be automatically deleted after X days, so those would be lost.

I don't think there's today a way to spot the "interest" an user has for an 
email other than by checking if he opened it or not; but not opening an email 
doesn't mean we're not interested in it.
So impacting the reputation solely based on this criteria seems clumsy, unless 
maybe if done really really well (and that unfortunately usually isn't the 
case).

In the meantime, it doesn't mean that bulk marketing senders shouldn't exclude 
inactives. They should, they must do it. Their job is to create and maintain a 
relationship between their brand and their public. If the public isn't reacting 
anymore, then it's time to say goodbye.

* I'm well aware that my opinion doesn't matter much in the end, and yet I'm 
here on Friday evening

~epilogue~
In a much more practical approach, there's also the other way: if people open, 
they probably are interested. Unless they were just browsing through their 
emails and the next one got automatically "opened" before being quickly 
deleted. I guess the TTL after opening is another criteria. Anyway, that would 
mean that if the recipients of a bulk sending open, then it should increase the 
reputation of this IP and/or domain (excuse my innocence in this, I'm genuinely 
asking if there's a reason to think otherwise).
So that's a nice principle, and Gmail actually enforces it pretty well; 
unfortunately not all other receivers do, and that makes things a lot more 
difficult: we (I'm an ESP) spend a considerable amount of time educating our 
clients on best practices and compliance. We tell them what to do, they don't 
believe us, they crash, we tell them how to start to fix it, they try, it 
works, they learned something. But when we tell them to follow the best 
practices (target only the active ones to make it work) and it doesn't work any 
better, they start questioning the whole best practices again.

Cheers to all, and have a nice week-end!

--
Benjamin

From: mailop  On Behalf Of Michael Wise via mailop
Sent: vendredi 16 novembre 2018 20:27
To: Michael Rathbun ; mailop@mailop.org
Subject: Re: [mailop] Spamcop IP blacklisted




And if the email isn't opened, or there is no show of interest over the course 
of the past 3 - 6 months ...

It's mailing malpractice, and will *impact* your IP / domain reputation.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| 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 Michael Rathbun
Sent: Friday, November 16, 2018 6:52 AM
To: mailop@mailop.org
Subject: Re: [mailop] Spamcop IP blacklisted



On Fri, 16 Nov 2018 11:04:03 +, Laura Atkins 
mailto:la...@wordtothewise.com>>

wrote:



>Last time I talked to a SC employee, which admittedly was more than a few 
>years ago, about their trap conditioning they were using a 2+ year cycle of 
>actively rejecting mail to trap domains. If your users can’t figure out how to 
>stop mailing domains that never accept a single email over the course of 2 
>years, I don’t think that’s really a trap maintainer problem.

>

>I’ve taken the position, and tell my clients this, that EVERY SINGLE

>EMAIL that bounces is a potential spamtrap.This has been reinforced by

>the commercial services selling access to spamtrap data - where the

>spamtrap data is simply domains maintained by the commercial service.

>If your customers are bouncing mails then your response should be “they

>hit a spamtrap” not some vague “oh, well.”



In addition to internal spamtraps, they have external ones, like "Nadine"

Re: [mailop] Microsoft Support System Down?

[Benjamin BILLON]

Yup

--
Benjamin

From: Mathieu Bourdin 
Sent: jeudi 17 janvier 2019 10:26
To: Laura Atkins ; Benjamin BILLON 
Cc: mailop 
Subject: RE: [mailop] Microsoft Support System Down?

I think Benjamin was talking about the case (rare, but they do happen) where 
you get no answer at the ticket opening, ie you have nothing to answer to. You 
do get the ticket opening receipt, but no “first level answer” to build a 
conversation from.

Mathieu.

De : mailop mailto:mailop-boun...@mailop.org>> De la 
part de Laura Atkins
Envoyé : jeudi 17 janvier 2019 10:16
À : Benjamin BILLON mailto:bbil...@splio.com>>
Cc : mailop mailto:mailop@mailop.org>>
Objet : Re: [mailop] Microsoft Support System Down?

Why do you open a new ticket and not respond to the old one? When I’ve dealt 
with MS on behalf of clients (which, admittedly, has been a while), I’ve always 
kept everything in the same ticket.

Is there something I’m missing that makes it better to open a new ticket?

laura


On 16 Jan 2019, at 06:13, Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:

Seems really on People reported a few days ago that yay, they finally got 
answers to their requests.
Your message indicates it's not "solved", but it's been like that for months.

I guess the best (and most awful) way would be to open a new ticket if there's 
no feedback after 24 hours (given them some margin out of the 8h SLA)

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Christina Hoheisel via mailop
Sent: mercredi 16 janvier 2019 02:08
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Microsoft Support System Down?

Hello Everyone,

For the past couple weeks we've noticed an issue with Microsoft's support 
system. After submitting a new support request, we receive the auto-response 
message noting that the ticket has been received and we should expect to 
receive a response within 8 hours (like normal), but then we never actually 
receive a response. The first time we noticed this happening was at the end of 
December and the issue still persists. Is anyone else having luck with getting 
through to Microsoft support right now? I appreciate your help with this.

Thanks,

Christina

--
Christina Hoheisel
Technical Account Manager
SparkPost<http://sparkpost.com/>

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

--
Having an Email Crisis?  We can help! 800 823-9674

Laura Atkins
Word to the Wise
la...@wordtothewise.com<mailto:la...@wordtothewise.com>
(650) 437-0741

Email Delivery Blog: https://wordtothewise.com/blog






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

Re: [mailop] Microsoft Support System Down?

[Benjamin BILLON]

Seems really on People reported a few days ago that yay, they finally got 
answers to their requests.
Your message indicates it's not "solved", but it's been like that for months.

I guess the best (and most awful) way would be to open a new ticket if there's 
no feedback after 24 hours (given them some margin out of the 8h SLA)

--
Benjamin

From: mailop  On Behalf Of Christina Hoheisel via 
mailop
Sent: mercredi 16 janvier 2019 02:08
To: mailop@mailop.org
Subject: [mailop] Microsoft Support System Down?

Hello Everyone,

For the past couple weeks we've noticed an issue with Microsoft's support 
system. After submitting a new support request, we receive the auto-response 
message noting that the ticket has been received and we should expect to 
receive a response within 8 hours (like normal), but then we never actually 
receive a response. The first time we noticed this happening was at the end of 
December and the issue still persists. Is anyone else having luck with getting 
through to Microsoft support right now? I appreciate your help with this.

Thanks,

Christina

--
Christina Hoheisel
Technical Account Manager
SparkPost

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

Re: [mailop] TLS Statistics

[Benjamin BILLON]

One of the basic principles of GDPR however is that whatever doable should be 
done to keep personal information safe. So if you have the feature to use 
encryption, you must use it. Nowadays in Europe, opportunistic TLS would be the 
bare minimum.

--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Paul Smith
Sent: mardi 18 décembre 2018 12:33
To: mailop@mailop.org
Subject: Re: [mailop] TLS Statistics

On 18/12/2018 10:52, Sidsel Jensen wrote:
> What Frands is referring to, is the local Danish requirements by our 
> national Danish Data Protection Agency called “Datatilsynet” - their 
> statement by which Danish companies need to comply by January 2019 can 
> be read


Ah, so it's a Danish thing, not actually GDPR.

There's a reason GDPR itself never actually says "use encryption". It just says 
that encryption is something you may decide to use if it's technically possible 
and you feel it's appropriate. For email, it's arguable that it's not 
technically possible to enforce the use of encryption - because even if only 5% 
or so won't be deliverable in that case, that's a LOT of emails.



-- 


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] TLS Statistics

[Benjamin BILLON]

(I mostly agree with Paul, I'm just continuing the discussion for the beauty of 
it)

> You do not have to do what is "doable". You have to do whatever is 
> *practical*. Investing in armoured vehicles to transfer your data is 
> certainly "doable", but not really "practical".
Doable, practical, reasonable. 
I consider "doable" something that makes sense in a given context, but if you 
take it literally, yeah, that wasn't precise enough.

> unless it's sensitive information, it is probably fine to send it unencrypted 
> or using a lesser encryption [...]
> Most emails do NOT contain sensitive information
You probably don't know that, but you actually should know*. So in doubt, use 
encryption. Nobody will blame you for using it, but you could be blamed for not 
doing so. Even if your current system doesn't do encryption, it's the 
opportunity to check if another system could, and maybe upgrade. Not having the 
proper tools isn't an excuse.

> People often think 'Ooh, my emails are sent using TLS1.3 encryption - no one 
> can see them, they're safe'. Nothing could be further from the truth.
Using TLS1.3 for emails is a step towards securing data. Man in the middle is 
not impossible, but harder to do. Not doing TLS because "pff the whole 
transport isn't 100% secure anyway" is, in addition to a bad idea, clearly 
reprehensible.

* I'm using "you" generally, not specifically about Paul. If you are an ESP, 
then you should have a data privacy agreement with your clients to describe 
what content could be there and what is done with it. If you're a sender using 
an ESP, you should have a DPA with your provider, and ask them to enforce TLS 
and other "practical" methods to secure the transportation of information.
--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Paul Smith
Sent: mardi 18 décembre 2018 15:45
To: mailop@mailop.org
Subject: Re: [mailop] TLS Statistics

On 18/12/2018 13:54, Benjamin BILLON wrote:
> One of the basic principles of GDPR however is that whatever doable should be 
> done to keep personal information safe. So if you have the feature to use 
> encryption, you must use it. Nowadays in Europe, opportunistic TLS would be 
> the bare minimum.

You do not have to do what is "doable". You have to do whatever is *practical*. 
Investing in armoured vehicles to transfer your data is certainly "doable", but 
not really "practical".

So, yes, if strong email encryption is available, use it, but if it's not, 
then, unless it's sensitive information, it is probably fine to send it 
unencrypted or using a lesser encryption. Your data risk assessments should let 
you know whether that's OK or not. GDPR is quite pragmatic in that way.

Most emails do NOT contain sensitive information. Email addresses & names are 
not 'sensitive information'. Financial & medical details are 'sensitive 
information'.

If you had to use encryption, then using session encryption will most 
definitely NOT keep sensitive data safe. The mail could be processed by or 
stored by multiple servers, including those which may not be subject to GDPR 
and those will have access to the message data if you are only using session 
encryption. The details & locations of the servers which can access the mail 
data will not be known to most email users (in fact, unless both sender and 
recipient mail admins get together to discuss it, NO ONE will know which 
servers have access to a particular message)

People often think 'Ooh, my emails are sent using TLS1.3 encryption - no one 
can see them, they're safe'. Nothing could be further from the truth.


-- 


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Decode MS SPAM Headers

[Benjamin BILLON]

Besides https://testconnectivity.microsoft.com/?tabid=mha you mean?

--
Benjamin

From: mailop  On Behalf Of Mike Hammett
Sent: jeudi 20 décembre 2018 14:38
To: Mailop 
Subject: [mailop] Decode MS SPAM Headers

Microsoft inserts a lot of headers into a message regarding their SPAM 
filtering and so on. I assume somewhere in there is why it failed the checks. I 
realize that 
https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spam-message-headers
 explains a lot (if not everything), but that's far too "in the weeds" for me. 
Is there a place I can paste the headers and have it list out for me the 
important stuff regarding why it failed?


https://mxtoolbox.com/EmailHeaders.aspx does a decent job of breaking things 
up, but it isn't throwing out front and center why MS thinks it's SPAM.



-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Decode MS SPAM Headers

[Benjamin BILLON]

Yeah, and you won't have more explanation. I mean, you can contact Microsoft's 
support, but you will probably learn that this is due to smartscreen's 
decision. A fat lot of good that does you!

But it's on purpose. If it was possible to get too much details, be sure that 
spammers would find a workaround.

What we're all wishing for now is that Microsoft would have a way to identify 
the good senders from the bad, and provide a bit more details to the good ones. 
Easy principle, hard implementation.

Cheers,

--
Benjamin

From: Mike Hammett 
Sent: jeudi 20 décembre 2018 16:31
To: Benjamin BILLON 
Cc: Mailop 
Subject: Re: Decode MS SPAM Headers

Spam Confidence Level 5
Spam Filtering Verdict  SPM


I see they determined it to be SPAM, but not why.



-
Mike Hammett
Intelligent Computing Solutions<http://www.ics-il.com/>
[Image removed by sender.]<https://www.facebook.com/ICSIL>[Image removed by 
sender.]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[Image 
removed by 
sender.]<https://www.linkedin.com/company/intelligent-computing-solutions>[Image
 removed by sender.]<https://twitter.com/ICSIL>
Midwest Internet Exchange<http://www.midwest-ix.com/>
[Image removed by sender.]<https://www.facebook.com/mdwestix>[Image removed by 
sender.]<https://www.linkedin.com/company/midwest-internet-exchange>[Image 
removed by sender.]<https://twitter.com/mdwestix>
The Brothers WISP<http://www.thebrotherswisp.com/>
[Image removed by sender.]<https://www.facebook.com/thebrotherswisp>[Image 
removed by sender.]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

From: "Benjamin BILLON" 
To: "Mike Hammett" , "Mailop" 
Sent: Thursday, December 20, 2018 9:21:46 AM
Subject: RE: Decode MS SPAM Headers
Besides https://testconnectivity.microsoft.com/?tabid=mha you mean?

--
Benjamin

From: mailop  On Behalf Of Mike Hammett
Sent: jeudi 20 décembre 2018 14:38
To: Mailop 
Subject: [mailop] Decode MS SPAM Headers

Microsoft inserts a lot of headers into a message regarding their SPAM 
filtering and so on. I assume somewhere in there is why it failed the checks. I 
realize that 
https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spam-message-headers
 explains a lot (if not everything), but that's far too "in the weeds" for me. 
Is there a place I can paste the headers and have it list out for me the 
important stuff regarding why it failed?


https://mxtoolbox.com/EmailHeaders.aspx does a decent job of breaking things 
up, but it isn't throwing out front and center why MS thinks it's SPAM.



-
Mike Hammett
Intelligent Computing Solutions<http://www.ics-il.com/>
[Image removed by sender.]<https://www.facebook.com/ICSIL>[Image removed by 
sender.]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[Image 
removed by 
sender.]<https://www.linkedin.com/company/intelligent-computing-solutions>[Image
 removed by sender.]<https://twitter.com/ICSIL>
Midwest Internet Exchange<http://www.midwest-ix.com/>
[Image removed by sender.]<https://www.facebook.com/mdwestix>[Image removed by 
sender.]<https://www.linkedin.com/company/midwest-internet-exchange>[Image 
removed by sender.]<https://twitter.com/mdwestix>
The Brothers WISP<http://www.thebrotherswisp.com/>
[Image removed by sender.]<https://www.facebook.com/thebrotherswisp>[Image 
removed by sender.]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

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

Re: [mailop] Outlook/Hotmail/etc rejecting email (but not Office 365)

[Benjamin BILLON]

Hi Chris, 

Although rare, this isn't unusual. For some reason Microsoft considered there's 
an issue. In a similar case I had recently, I couldn't say that " part of their 
network is on our block list "* is untrue. We have some IPs blocked, as seen on 
SNDS, and some on the same range as the IPs that generated these replies. 
However, those specific IPs had a pretty fine traffic.
So these IPs were getting rejection because other IPs in the network (range?) 
are also blocked, but despite being rejected, those weren't blocked.
These 2 IPs (with the same fine traffic) generated rejections (not the plenty 
of other neighbor IPs in the same situation of "part of network is on block 
list"), they were submitted together to the Support, first answer was "we see 
no problem on one and the other has been mitigated". The next day, the "no 
problem" one was still rejecting, so I pushed back to the Support, and they 
mitigated as well. Case closed!

There's mystery (or dark magic) going on in Outlook.com. But after a few back 
and forth with the Support, they've been mitigated, and back to normal. So 
honestly at this point, I let the "but why" go!

* I believe that being on Microsoft's "block list" isn't necessarily about the 
blocked IPs we can see on SNDS 
--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Chris Malton (Delta V)
Sent: mardi 11 décembre 2018 08:42
To: Michael Wise ; mailop@mailop.org
Subject: Re: [mailop] Outlook/Hotmail/etc rejecting email (but not Office 365)

On 11/12/2018 00:11, Michael Wise via mailop wrote:
> Looks like Mitigation was applied, but it's possible that the /24 had some 
> bad tenants previously?
I have a hunch it was allocated before, I'm just curious why it's been working 
for 2-3 months, and then suddenly stopped between Saturday night and this 
morning.
> We don't provide support thru MailOp, only via the Support webform, which it 
> seems you have already discovered.

Understandable Michael - was just curious if anyone else could see anything I'd 
obviously missed.

Your Deliverability Support Team have been in touch off the back of that form 
and things now seem to be working again.

Many thanks for any work you did behind the scenes to get this in front of the 
right people.

Regards,

Chris Malton

--
Delta V Technologies Limited
0 402 406www.deltav-tech.co.uk
Office: 17 Elm Close, Southampton, SO16 7DT Company No. 11006104 Registered in 
England and Wales


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

Re: [mailop] Contact at Orange.fr

[Benjamin BILLON]

ab...@orange.fr is the way to go, however it could take 
a few days to get a reply, if they consider there should be one.

Otherwise if you can share some details, I'll meet these folks tomorrow night.

--
Benjamin

From: mailop  On Behalf Of Dragutin Cvetkovic
Sent: mardi 4 décembre 2018 10:48
To: mailop@mailop.org
Subject: [mailop] Contact at Orange.fr

Hi all,

I am hoping to get in touch with someone offlist from Orange.fr PostMaster team.

Please contact me directly.


Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead




Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com 

[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4


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

Re: [mailop] Contact at Orange.fr

[Benjamin BILLON]

For IPs with ReturnPath Certification, you can increase the number of 
concurrent connection by IP.

--
Benjamin

From: mailop  On Behalf Of Mathieu Bourdin
Sent: mercredi 5 décembre 2018 10:53
To: Dragutin Cvetkovic ; mailop@mailop.org
Subject: Re: [mailop] Contact at Orange.fr

Hi Dragutin,

Limit rates for Orange/wanadoo is 3 connection per IP. Often issues are caused 
by not taking into account wanadoo.fr domain addresses as this is the same 
operator (meaning you have to manage this on a mx basis, not just domain). If 
you use PMTA for sending wrap both domains in the same queue.

Mathieu.

De : mailop mailto:mailop-boun...@mailop.org>> De la 
part de Dragutin Cvetkovic
Envoyé : mercredi 5 décembre 2018 10:30
À : mailop@mailop.org<mailto:mailop@mailop.org>
Objet : Re: [mailop] Contact at Orange.fr

Hi Benjamin, et. al,

Thank you for the feedback.

Essentially, I am trying to find out what are the optimal/recommended MTA/SMTP 
connection settings for orange.fr.

I ran into several online articles on the topic, but they are somewhat 
contradicting.
Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead




Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>

[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4






From:    Benjamin BILLON mailto:bbil...@splio.com>>
To:Dragutin Cvetkovic 
mailto:dcvetko...@ie.ibm.com>>, 
"mailop@mailop.org<mailto:mailop@mailop.org>" 
mailto:mailop@mailop.org>>
Date:04/12/2018 10:35
Subject:Re: [mailop] Contact at Orange.fr
Sent by:"mailop" 
mailto:mailop-boun...@mailop.org>>




ab...@orange.fr<mailto:ab...@orange.fr>is the way to go, however it could take 
a few days to get a reply, if they consider there should be one.

Otherwise if you can share some details, I'll meet these folks tomorrow night.

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Dragutin Cvetkovic
Sent: mardi 4 décembre 2018 10:48
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Contact at Orange.fr

Hi all,

I am hoping to get in touch with someone offlist from Orange.fr PostMaster team.

Please contact me directly.


Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead






Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>

[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4


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

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

Re: [mailop] Contact at Orange.fr

[Benjamin BILLON]

mx-connection-limit does the trick

Pmta forums probably have detailed examples too

--
Benjamin

From: mailop  On Behalf Of Dragutin Cvetkovic
Sent: mercredi 5 décembre 2018 13:32
To: mbour...@np6.com
Cc: mailop@mailop.org
Subject: Re: [mailop] Contact at Orange.fr

Hello Mathieu,

Thanks for the tip.

My issue with using PMTA queues is that I only know of the 'route' directive to 
pass the mailings to the specific MX server: this can be a problem if the ISP 
changes their MX server's addresses, and the change could go unnoticed.

Is there a way to queue up two domains and have the queue deliver to the DNS 
provided MX record of a specific domain?

Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead




Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com <mailto:dcvetko...@ie.ibm.com>

[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4



- Original message -
From: Mathieu Bourdin mailto:mbour...@np6.com>>
Sent by: "mailop" mailto:mailop-boun...@mailop.org>>
To: Dragutin Cvetkovic mailto:dcvetko...@ie.ibm.com>>, 
"mailop@mailop.org<mailto:mailop@mailop.org>" 
mailto:mailop@mailop.org>>
Cc:
Subject: Re: [mailop] Contact at Orange.fr
Date: Wed, Dec 5, 2018 9:58 AM


Hi Dragutin,



Limit rates for Orange/wanadoo is 3 connection per IP. Often issues are caused 
by not taking into account wanadoo.fr domain addresses as this is the same 
operator (meaning you have to manage this on a mx basis, not just domain). If 
you use PMTA for sending wrap both domains in the same queue.



Mathieu.



De : mailop mailto:mailop-boun...@mailop.org>> De la 
part de Dragutin Cvetkovic
Envoyé : mercredi 5 décembre 2018 10:30
À : mailop@mailop.org<mailto:mailop@mailop.org>
Objet : Re: [mailop] Contact at Orange.fr



Hi Benjamin, et. al,

Thank you for the feedback.

Essentially, I am trying to find out what are the optimal/recommended MTA/SMTP 
connection settings for orange.fr.

I ran into several online articles on the topic, but they are somewhat 
contradicting.

Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead







Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>


[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland




IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4






From:Benjamin BILLON mailto:bbil...@splio.com>>
To:Dragutin Cvetkovic 
mailto:dcvetko...@ie.ibm.com>>, 
"mailop@mailop.org<mailto:mailop@mailop.org>" 
mailto:mailop@mailop.org>>
Date:04/12/2018 10:35
Subject:Re: [mailop] Contact at Orange.fr
Sent by:"mailop" 
mailto:mailop-boun...@mailop.org>>





ab...@orange.fr<mailto:ab...@orange.fr>is the way to go, however it could take 
a few days to get a reply, if they consider there should be one.

Otherwise if you can share some details, I'll meet these folks tomorrow night.

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Dragutin Cvetkovic
Sent: mardi 4 décembre 2018 10:48
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Contact at Orange.fr

Hi all,

I am hoping to get in touch with someone offlist from Orange.fr PostMaster team.

Please contact me directly.



Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead







Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>


[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland




IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4


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

___
mailop mailing list
mailop@mailop.org<mailto: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] Outlook.com Support (whining time)

[Benjamin BILLON]

Hi there,

It's understood and proven, Outlook.com can accept emails, deliver them to 
inbox, then move them to Junk folder a few seconds later.
This a posteriori moving makes sense to clean users' inboxes from scams, 
phishing or spams that have been spotted a little too late.

My case (SRX1448704980ID) of course is far from these contexts, and yet I 
couldn't get any sensible answer. The keyword "escalation" seems broken ...
I had other, unrelated cases fixed in a breeze (or two).

So, I'm keeping the ticket open by asking for news every few days, but I just 
can't stop thinking there's something abnormal here, and I apparently can't 
wave enough for this to be noticed.
I (non-secretly) hope the Microsoft folks in the list would be able to poke 
around internally, but I'm still convinced this is not how this should be 
handled.

Side notes:

  *   I _did_ see changes in the Support process recently. Now there's a 
templated confirmation email sent, subject lines and some URLs have been 
updated (copy/pasted part are still pointing to 
https://postmaster.live.com/snds/FAQ.aspx and http://postmaster.msn.com/snds/ 
though), so I _know_ there are people working there, and this is greatly 
appreciated.
  *   Do not put List-unsubscribe URLs in your emails with the Support (when 
providing samples of headers, for instance), as something, somewhere, 
apparently checks what's behind the link. By "clicking" on it.

Cheers,
--
Benjamin

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

Re: [mailop] Contact at Orange.fr

[Benjamin BILLON]

For PowerMTA specific questions, I strongly advise to ask on 
https://forum.port25.com rather than here.

That being said: why using "route"? Why the queue? Maybe it's related to your 
specific settings, but it might not be useful.
Hint: limit your max-msg-per-connection to less. Start with 50 then try to 
increase, if necessary.

Try this:

domain-macro orange-domains wanadoo.fr, orange.fr
mx-connection-limit smtp-in.orange.fr 3

   max-smtp-out 1
   max-msg-per-connection 50


Note that using a domain-macro won't aggregate the setting the the macro. It 
just makes your conf shorter.
So the above is exactly the same as

mx-connection-limit smtp-in.orange.fr 3

   max-smtp-out 1
   max-msg-per-connection 50


   max-smtp-out 1
   max-msg-per-connection 50





--
Benjamin

From: mailop  On Behalf Of Dragutin Cvetkovic
Sent: jeudi 6 décembre 2018 11:15
To: mailop 
Subject: Re: [mailop] Contact at Orange.fr

LOL!

Oh well...

defined a macro...

domain-macro orange-domains wanadoo.fr, orange.fr


defined a queue...



   route smtp-in.orange.fr
   max-smtp-out 1
   max-msg-per-connection 500


and then told it to redirect stuff...

# Domain Settings

   queue-to smtp-in.orange.fr.queue


and still getting

SMTP service unavailable: "421 mwinf5c53 ME Trop de connexions, veuillez 
verifier votre configuration. Too many connections, slow down. OFR004_104 [104]"

The trick is I have three PMTAs here harnessed together, so max-smtp-out 1 
translates to 3 connections, 1 per PMTA.

So, I think I will have to get in touch with the folks at Orange to clarify 
this.

One thing I did, which is a bit naughty, is pushed the max-msg-per-connection 
to 500 from 100... Doesn't seem to affect anything negatively.
Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead




Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>

[IBM]

IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4






From:Mathieu Bourdin mailto:mbour...@np6.com>>
To:Al Iverson 
mailto:aliver...@aliverson.com>>, Benjamin BILLON 
mailto:bbil...@splio.com>>
Cc:mailop mailto:mailop@mailop.org>>, 
"dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>" 
mailto:dcvetko...@ie.ibm.com>>
Date:05/12/2018 15:24
Subject:Re: [mailop] Contact at Orange.fr
Sent by:"mailop" 
mailto:mailop-boun...@mailop.org>>




But… where’s the fun  in that ?

(mentally insert image of a slightly confused and a bit sad kitty)

Mathieu.

De : Al Iverson mailto:aliver...@aliverson.com>>
Envoyé : mercredi 5 décembre 2018 15:58
À : Benjamin BILLON mailto:bbil...@splio.com>>
Cc : dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>; Mathieu Bourdin 
mailto:mbour...@np6.com>>; mailop 
mailto:mailop@mailop.org>>
Objet : Re: [mailop] Contact at Orange.fr

Or just set it to one connection max for each domain and you'll stay below 3 
because there are only two domains. :)

Cheers,
Al Iverson

On Wed, Dec 5, 2018 at 8:28 AM Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:
mx-connection-limit does the trick

Pmta forums probably have detailed examples too

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Dragutin Cvetkovic
Sent: mercredi 5 décembre 2018 13:32
To: mbour...@np6.com<mailto:mbour...@np6.com>
Cc: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: Re: [mailop] Contact at Orange.fr

Hello Mathieu,

Thanks for the tip.

My issue with using PMTA queues is that I only know of the 'route' directive to 
pass the mailings to the specific MX server: this can be a problem if the ISP 
changes their MX server's addresses, and the change could go unnoticed.

Is there a way to queue up two domains and have the queue deliver to the DNS 
provided MX record of a specific domain?

Best regards,

Dragutin Cvetković
IBM WCA Deliverabilty Tech Lead






Phone: +353 1 815 2564
Mobile: +353 87 118 3960
E-mail: dcvetko...@ie.ibm.com<mailto:dcvetko...@ie.ibm.com>



IBM Technology Campus
Damastown Industrial Estate, Mulhuddart, Dublin 15
Ireland


IBM Ireland Product Distribution Limited Registered in Ireland with number 
92815.
Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4




- Original message -
From: Mathieu Bourdin mailto:mbour...@np6.com>>
Sent by: "mailop" mailto:mailop-boun...@mailop.org>>
To: Dragutin Cvetkovic mailto:dcvetko...@ie.ibm.com>>, 
"mailop@mailop.org<mailto:mailop@mailop.org>" 
mailto:m

Re: [mailop] SPF soft fail vs. hard fail

[Benjamin BILLON]

This behavior of respecting the published policy is the way to go, until it's 
not anymore. You have to be a big enough receiver for having enough complaints 
about unreceived legit emails without taking the time to educate/explain that 
an admin didn't do his job properly. And also to afford not filtering out 
emails at the early stage of the SMTP transaction.
Small receivers aren't checking DKIM or DMARC most probably because they're 
rejecting right after the MAIL FROM (I doubt there's a lot rejecting at HELO 
for SPF reasons, but I guess there still are), sparing resources.

> Given this situation, the customer is now considering whether they want to 
> move every domain they own to SPF soft fail instead, so I wanted to ask 
> around and get a feel for how common this is before they change all of their 
> many domains.
Is it easier to do that, than adding the proper record (and maybe a central 
SMTP relay for their own needs)?
Switching to softfail also means removing some security, allowing more 
non-legit emails to be sent MAIL FROM: their domain, relying solely on the 
antispam system of small receivers (and I wouldn't rely on that).
Maybe it should only be a temporary workaround?

--
Benjamin

From: mailop  On Behalf Of Mark Foster
Sent: vendredi 7 décembre 2018 03:48
To: Brandon Long ; Brandon Long via mailop 
; Autumn Tyr-Salvia 
Cc: mailop 
Subject: Re: [mailop] SPF soft fail vs. hard fail

I know SPF generates some polarizing views, but my view is this:

- if you can trust that legit mail will have a 100% pass rate for legit email, 
use a hardfail and those operators who evaluate it and use it will see benefit. 
Win.
- if you can't trust that pass rate, publish a soft fail and let other measures 
come into play.

It's hard to penalise people for correctly using the standard. So in the OP 
scenario the move to soft fail was the right call IMO.

Mark.
On 7 December 2018 3:15:40 PM NZDT, Brandon Long via mailop 
mailto:mailop@mailop.org>> wrote:
I'd say you're likely to get two types of receivers: those that know that spf 
policies are useless so they'll ignore -all, and those who think that they 
should do what the policy says.

I'd say that most people who believe the latter are smaller operators.

I don't see any reason to publish -all if you are planning to send any messages 
in that domain, it doesn't gain you anything.

Brandon

On Thu, Dec 6, 2018 at 6:00 PM Autumn Tyr-Salvia 
mailto:tyrsal...@gmail.com>> wrote:
Hello Mail Operators,

My job is to help large organizations figure out their email infrastructure and 
authenticate everything legitimate with the goal of going to DMARC p=reject. A 
customer recently reported an issue to me about receiver behavior that I hadn't 
heard before, so I wanted to reach out to get a feel for whether this is more 
widespread than I realized or if this particular receiver is behaving strangely.

It's a bit of a long story why things are set up in the way they are for this 
particular situation, and in the interests of not writing a novel here, I'm 
going to cut to the chase:

Customer is sending messages that pass DKIM with first party signing, so they 
pass DMARC. Unfortunately, SPF fails, and the SPF record uses a -all, so it's a 
hard fail. There is an SPF entry at the sending subdomain, and the SMTP MAIL 
FROM domain is aligned, but the SPF record does not include the sending IPs. 
There are complicated reasons why they can't just do that easily.

DMARC requires only one aligned method of authentication to pass, either SPF or 
DKIM. Since these messages pass with aligned DKIM, they pass DMARC. In theory, 
all should be good, right?

We have received reports that a particular organization they are sending to is 
seeing the SPF hard fail and choosing not to further evaluate DKIM, and is 
rejecting these messages on SPF hard fail alone. I don't have the bounce 
message handy, but it said something like "SPF hard fail: your organization's 
security policy does not permit this message." The organization they're sending 
to is a small nonprofit, but the MX record shows that they are using GoDaddy's 
hosted email.

When one of the email admins involved had the recipient ask their email vendor 
about it, they were explicitly told that if senders use an SPF -all, if 
messages fail SPF, they will not accept them even if they pass DKIM and DMARC. 
As a consequence, I had them try setting the domain to use a soft fail ~all and 
test, and initial reports say that delivery was successful.

I have a lot of experience with SPF, though admittedly, I don't have as much 
experience with SPF failures (I see a lot of cases of no SPF, or passing but 
not aligned SPF, but comparatively few actual failures), but I haven't heard 
this distinction between hard and soft fail modes before.

How common is it to have receiver systems set so that SPF hard fail will reject 
messages even if they otherwise pass DKIM and DMARC, but to accept them on the 
DKIM pass if the domain uses 

Re: [mailop] mailchannels.ch / mailchannels.net ESP contact?

[Benjamin BILLON]

I do know the dot com, with Ken Simpson, from Canada.

@Ken, FYI

Cheers, 
--
Benjamin Billon

-Original Message-
From: mailop  On Behalf Of Benoit Panizzon
Sent: vendredi 30 novembre 2018 08:46
To: mailop@mailop.org
Subject: [mailop] mailchannels.ch / mailchannels.net ESP contact?

Hi List

Does anyone know about mailchannels.ch? Looks a bit like an ESP but they send 
out emails with a sender domain hosted on our email plattform and protected by 
SPF. Unfortunately this makes us receive all the bounces.

https://www.mailchannels.ch/ leads to a site with many certificates, none 
fitting and when adding an exception to a 404 error.
Same with: https://www.mailchannels.net/

Domain name:
mailchannels.ch

Holder of domain name:
Ken Simpson
#142 - 757 Hastings St. W, Suite 612
CA-V6C 1A1 Vancouver
Canada

inetnum:46.232.183.0 - 46.232.183.255
netname:MAILCHANNNELS-NET
descr:  MAILCHANNNELS CORPORATION
country:CA

% Abuse contact for '46.232.183.0 - 46.232.183.255' is 'ab...@mailchannels.ch'

So trying to contact them on their RIPE abuse contact:

<<< 421 4.7.0 IP not in whitelist for RCPT domain, closing connection. 
f28si2936218pff.131 - gsmtp ... Deferred: 421 4.7.0 IP 
not in whitelist for RCPT domain, closing connection. f28si2936218pff.131 - 
gsmtp ... while talking to alt1.aspmx.l.google.com.:

ehm... what is THAT feature?

How many times do I need to tell google, that abuse contact email addresses 
from RIPE etc. should not get filtered in any way?

Mit freundlichen Grüssen

-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
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outlook.com Support (whining time)

[Benjamin BILLON]

Hi Michael,

When you say the wording is very important, do you mean that "please escalate" 
isn't correct? I just tried the word "escalation" (I checked, I didn't use this 
one exactly yet), we'll see. If there's another wording to use ... I'd love to 
know it =)

The "proof" I have that emails are reaching inbox is that I can reproduce and 
see it happening right in front of me. It's in inbox, then disappears after a 
few seconds, popping in junk. Headers show dest:I, and not dest:J like other 
messages I could find in Junk folder.

Cheers,
--
Benjamin

From: Michael Wise 
Sent: mardi 4 décembre 2018 21:52
To: Al Iverson ; Benjamin BILLON 
Cc: mailop 
Subject: RE: [mailop] Outlook.com Support (whining time)




Oops.

Please understand that the wording is VERY important.

The email may in fact be getting to the mailbox SERVER, but there is no 
guarantee that it is not in fact being delivered to junk.



And if that was me, sorry, been crazy busy recovering from Thanksgiving Madness.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?



-Original Message-
From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Al Iverson
Sent: Tuesday, December 4, 2018 10:27 AM
To: Benjamin BILLON mailto:bbil...@splio.com>>
Cc: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Outlook.com Support (whining time)



Hey Benjamin, I am having similar (I think) problems over here where I request 
mitigation or feedback regarding junk folder delivery and no matter what I say, 
MS sender support says everything is fine, even though the mail is clearly not 
going to the inbox.



I would even be happy to get a response that says "this mail is going to the 
junk folder appropriately based on sending reputation" but nothing like that 
comes. It is always, "we see no issue and don't understand what you're asking." 
I keep asking to escalate as well, to no avail.



I am wondering if perhaps some filtering at Microsoft could be broken.

I reached out to one Microsoft contact last week, and have gotten no response. 
I emailed them again, and a second contact, today but have yet to hear back.



Cheers,

Al Iverson

On Tue, Dec 4, 2018 at 1:04 PM Benjamin BILLON 
mailto:bbil...@splio.com>> wrote:

>

> Hi there,

>

>

>

> It's understood and proven, Outlook.com can accept emails, deliver them to 
> inbox, then move them to Junk folder a few seconds later.

>

> This a posteriori moving makes sense to clean users' inboxes from scams, 
> phishing or spams that have been spotted a little too late.

>

>

>

> My case (SRX1448704980ID) of course is far from these contexts, and yet I 
> couldn't get any sensible answer. The keyword "escalation" seems broken ...

>

> I had other, unrelated cases fixed in a breeze (or two).

>

>

>

> So, I'm keeping the ticket open by asking for news every few days, but I just 
> can't stop thinking there's something abnormal here, and I apparently can't 
> wave enough for this to be noticed.

>

> I (non-secretly) hope the Microsoft folks in the list would be able to poke 
> around internally, but I'm still convinced this is not how this should be 
> handled.

>

>

>

> Side notes:

>

> I _did_ see changes in the Support process recently. Now there's a templated 
> confirmation email sent, subject lines and some URLs have been updated 
> (copy/pasted part are still pointing to 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpostmaster.live.com%2Fsnds%2FFAQ.aspxdata=02%7C01%7Cmichael.wise%40microsoft.com%7C239bf53035354a07d1bf08d65a1722f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795452753962179sdata=GFLyEbpnrZRlEWQLw7a7MHALa2PJ7%2BxHX8QRECkl2yo%3Dreserved=0
>  and 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpostmaster.msn.com%2Fsnds%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C239bf53035354a07d1bf08d65a1722f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795452753962179sdata=dQHkuD1d7XcG5CChto%2F20Jaiy%2BH27VWfoxSGtY7AF%2FU%3Dreserved=0
>  though), so I _know_ there are people working there, and this is greatly 
> appreciated.

> Do not put List-unsubscribe URLs in your emails with the Support (when 
> providing samples of headers, for instance), as something, somewhere, 
> apparently checks what's behind the link. By "clicking" on it.

>

>

>

> Cheers,

>

> --

> Benjamin

>

>

>

> ___

> mailop mailing list

> mailop@mailop.org<mailto:mailop@mailop.org>

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchill

> i.

Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques

[Benjamin BILLON]

Hi Todd,

Thanks for the notice. That's definitely not Signal Spam, although it doesn't 
look totally malicious.

Signal Spam works with law enforcement authorities and security companies and 
initiative (among others) to help punishing ... bad people.

I'll notify the Signal Spam folks.

Thanks again!

--
Benjamin

From: mailop  On Behalf Of Todd Herr via mailop
Sent: mardi 27 novembre 2018 03:31
To: mailop@mailop.org
Subject: [mailop] Sanity Check - Signal Spam and Signal Arnaques

Hi.

I believe from past posts that there are Signal Spam reps on this list, and I 
just want to sanity check something with them.

We have a customer seeing their good name sullied on the website 
signal-arnaques.com, where they're being implicated 
as sending fraudulent messages. They're not actually sending fraudulent 
messages, and they have a DMARC p=reject policy in place that should cause 
these messages to never see a mailbox, but there's at least one ISP out there 
that doesn't honor DMARC, and so mailbox holders at that ISP are getting 
messages "From" my customer and posting them to 
signal-arnaques.com as "Scam Website Announcement".

My customer is frantic, and keeps referring to 
signal-arnaques.com as "Signal Spam", but I don't 
get the sense that the two are related in any sense of the word; different 
domains, different physical addresses, different operating models, it appears. 
However, I would like to get an official pronouncement from someone more 
knowledgeable than I that the two organizations are completely unrelated.

Thanks in advance.

--

todd herr
postmaster
www.sparkpost.com
twitter @toddherr @sparkpost

tel 415-578-5222 x477
mobile 703-220-4153
email todd.h...@sparkpost.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques

[Benjamin BILLON]

Hi again,

So they're definitely unrelated, but Signal Arnarques appears to have a 
community of people behind it. They do name, notify hosting providers, 
etc.

Unfortunately sounds-alike, but not purposely malicious.

Thomas Fontvielle, from Signal Spam, could contact your client to clarify this 
if you think it's relevant.

Cheers,
--
Benjamin

From: mailop  On Behalf Of Mathieu Bourdin
Sent: mardi 27 novembre 2018 09:47
To: mailop 
Subject: Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques

Hi Todd,

Benjamin beat me to it (must still be on a different timezone) but I can also 
confirm that the two organization have no relation, I’ve been on the signal 
spam board for some time now and that’s actually the first time I’ve heard 
about this signal-arnaque thing. The issue you describe is unfortunately one we 
sometime get with other similar websites like WoT who do not actually check for 
the real source in case of spoofing or, in case of legitimate complaints, let 
people categorize bad behavior in their own biased way.

Mathieu Bourdin.
NP6.


De : mailop mailto:mailop-boun...@mailop.org>> De la 
part de Benjamin BILLON
Envoyé : mardi 27 novembre 2018 07:32
À : mailop mailto:mailop@mailop.org>>
Objet : Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques

Hi Todd,

Thanks for the notice. That's definitely not Signal Spam, although it doesn't 
look totally malicious.

Signal Spam works with law enforcement authorities and security companies and 
initiative (among others) to help punishing ... bad people.

I'll notify the Signal Spam folks.

Thanks again!

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Todd Herr via mailop
Sent: mardi 27 novembre 2018 03:31
To: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: [mailop] Sanity Check - Signal Spam and Signal Arnaques

Hi.

I believe from past posts that there are Signal Spam reps on this list, and I 
just want to sanity check something with them.

We have a customer seeing their good name sullied on the website 
signal-arnaques.com<http://signal-arnaques.com>, where they're being implicated 
as sending fraudulent messages. They're not actually sending fraudulent 
messages, and they have a DMARC p=reject policy in place that should cause 
these messages to never see a mailbox, but there's at least one ISP out there 
that doesn't honor DMARC, and so mailbox holders at that ISP are getting 
messages "From" my customer and posting them to 
signal-arnaques.com<http://signal-arnaques.com> as "Scam Website Announcement".

My customer is frantic, and keeps referring to 
signal-arnaques.com<http://signal-arnaques.com> as "Signal Spam", but I don't 
get the sense that the two are related in any sense of the word; different 
domains, different physical addresses, different operating models, it appears. 
However, I would like to get an official pronouncement from someone more 
knowledgeable than I that the two organizations are completely unrelated.

Thanks in advance.

--

todd herr
postmaster
www.sparkpost.com<http://www.sparkpost.com>
twitter @toddherr @sparkpost

tel 415-578-5222 x477
mobile 703-220-4153
email todd.h...@sparkpost.com<mailto:firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcop IP blacklisted

[Benjamin BILLON]

> Does this mean I can’t declare the Era of IP Reputation is over?
No you can't, it has been explicitly said it's not over last month, in some 
meeting, by some major consumer provider.

This isn't a problem from my point of view, IPs or domains, the idea is to have 
an overall good reputation. Behave, and it'll work.

My problem is more when it doesn't work, while it should.

--
Benjamin

From: mailop  On Behalf Of Laura Atkins
Sent: lundi 19 novembre 2018 11:25
To: Michael Wise 
Cc: mailop 
Subject: Re: [mailop] Spamcop IP blacklisted


On 16 Nov 2018, at 22:23, Michael Wise via mailop 
mailto:mailop@mailop.org>> wrote:

Per email, no, bad test.
But if they keep not opening it, and others are reporting it as spam (or other 
things), and especially if there’s no clear unsubscribe link …
Bad Things will happen to the reputation.
Automatically in some places.

Yup. That’s one of those things I find hard to explain conceptually. Signals 
can modify each other. Signal A is neutral to slightly negative, Signal B is 
slightly negative, Signal C is neutral. But Signal A + Signal B is A*B not A+B. 
In the presence of Signal A then Signal C because extremely negative. Signal A, 
B and C all being present is an immediate block.


 And I agree, the machine should notice things like, this sender has been 
sending traffic to this recipient, and occasionally they open it, and 
occasionally they click a link, and they don’t report it as spam… that should 
build the reputation for that sender/recipient.

It works at some places. At other places their engine needs a bit of a tweak.


And hopefully, if wouldn’t matter which IP they were sending from, as long as 
the domain validated.

There are at least two major consumer providers where this is the case. There’s 
a third that puts more emphasis on IP reputation than the others.


(Some bits of this email contain forward-dreaming statements and wishes…)

Does this mean I can’t declare the Era of IP Reputation is over? There has been 
a pretty significant divergence in filters over the last few years and it’s 
making it challenging for folks to have one deliverability strategy that works 
for all ISPs.

(It’s just gone10am here and I already have 3 different “thought piece” blog 
posts working)

laura

--
Having an Email Crisis?  We can help! 800 823-9674

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741

Email Delivery Blog: https://wordtothewise.com/blog






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

Re: [mailop] List of unused, big email-domains?

[Benjamin BILLON]

It's just another tool in our toolbox. 

--
Benjamin

-Original Message-
From: mailop  On Behalf Of John R Levine
Sent: mardi 8 janvier 2019 21:49
To: Brandon Long 
Cc: mailop ; Grant Taylor 
Subject: Re: [mailop] List of unused, big email-domains?

> Tools can be used for good and bad purposes.  At some level, an ESP is 
> trusting mailing lists from their customers, and knows that some of 
> those lists are bad, even if the customer claims the lists are on the 
> up and up.  Any "white hat" ESP is going to have various systems in 
> place to try and catch these bad lists and bad customers before they 
> send mail.  A grey or black hat ESP could use that to just remove the 
> known bad entries.

Every legit ESP that I know already has a big list of poison addresses. 
People can try and do it if they want, but don't see it as very useful.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please 
consider the environment before reading this e-mail. https://jl.ly

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

Re: [mailop] List of unused, big email-domains?

[Benjamin BILLON]

RBL would be useful but I can start a list of defunct domains based on my 
experience, my email history and a few logs. I can't publish a RBL in a blink.
Also in my case, I wouldn't need a MTA to consume the list, I just want to have 
a list, with a date (or a year) of when the domain stopped asking to receive 
emails, so when I spot those domains I would have an indication of the age of 
the database, and do something with that.
It would also show an interesting history of the merges and deaths of emailing 
ecosystems on the Internet.
I'm not convinced about the need to highly document that, and official shutdown 
pages have high chances of being shut as well not long after the domain. But 
there's no problem to describing too much either.
We could also ask Al, or Laura, to maintain this list, but I believe they 
wouldn't mind a little community effort instead. 

I'll create the page on Wikipedia tomorrow, if nobody does it first =)

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Grant Taylor via mailop
Sent: mardi 8 janvier 2019 19:58
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

On 01/08/2019 10:32 AM, John Levine wrote:
> A lot of them have been turned into spamtraps after rejecting mail for 
> a year or so.  For obvious reasons, the people using them will not 
> tell you what they are.

I think there is a significant difference in a list of defunct sending domains 
and a list of spam traps.

I can see how there is some overlap.  But I don't think that concern of the 
latter precludes the former.

Also, it would be trivial for spam trap operators to disqualify their domains 
by stating that they do send email from said domains.



-- 
Grant. . . .
unix || die

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

Re: [mailop] List of unused, big email-domains?

[Benjamin BILLON]

https://en.wikipedia.org/wiki/Draft:List_of_major_email_domains_no_longer_in_service


--
Benjamin

-Original Message-
From: mailop  On Behalf Of Benjamin BILLON
Sent: mercredi 9 janvier 2019 18:15
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

I didn't find shorter than "List of domain names formerly used to receive 
massive amounts of emails" for the title of the page, if someone has a better 
idea, please sho[o|u]t ...

--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Benjamin BILLON
Sent: mardi 8 janvier 2019 20:19
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

RBL would be useful but I can start a list of defunct domains based on my 
experience, my email history and a few logs. I can't publish a RBL in a blink.
Also in my case, I wouldn't need a MTA to consume the list, I just want to have 
a list, with a date (or a year) of when the domain stopped asking to receive 
emails, so when I spot those domains I would have an indication of the age of 
the database, and do something with that.
It would also show an interesting history of the merges and deaths of emailing 
ecosystems on the Internet.
I'm not convinced about the need to highly document that, and official shutdown 
pages have high chances of being shut as well not long after the domain. But 
there's no problem to describing too much either.
We could also ask Al, or Laura, to maintain this list, but I believe they 
wouldn't mind a little community effort instead. 

I'll create the page on Wikipedia tomorrow, if nobody does it first =)

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Grant Taylor via mailop
Sent: mardi 8 janvier 2019 19:58
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

On 01/08/2019 10:32 AM, John Levine wrote:
> A lot of them have been turned into spamtraps after rejecting mail for 
> a year or so.  For obvious reasons, the people using them will not 
> tell you what they are.

I think there is a significant difference in a list of defunct sending domains 
and a list of spam traps.

I can see how there is some overlap.  But I don't think that concern of the 
latter precludes the former.

Also, it would be trivial for spam trap operators to disqualify their domains 
by stating that they do send email from said domains.



--
Grant. . . .
unix || die

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

Re: [mailop] List of unused, big email-domains?

[Benjamin BILLON]

I'd be interested in that too. 
As I'm not aware of such list, what about just starting it from scratch? We 
could put it on Wikipedia or anywhere else where it makes sense, and where we 
would have history and versioning.

I recently saw a few domains decommissioned for years, and they still have a MX 
record as of today.

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Stefan Neufeind
Sent: mardi 8 janvier 2019 17:44
To: mailop@mailop.org
Subject: [mailop] List of unused, big email-domains?

Hi,

from time to time I stumble across (former?) large mail-domains, including for 
example vr-web.de, eunet.at und some others. Those domains also include some 
freemails of "former days". of which quite a number don't run email-services 
anymore.

Does somebody know of a list of domains that are known to not run 
email-services anymore these days? Such domains usually don't have an MX-entry, 
but most still have an A-record since they want to redirect to some website. 
Technically having an A-record is sufficient to be able to receive emails 
though I expect most people "seriously" running email-services will then also 
provide MX-records "just to be sure".


Kind regards,
 Stefan

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

Re: [mailop] Outlook.com Support (whining time)

[Benjamin BILLON]

Hi Michael and others,

So I did something I usually don't do: I switched to other IPs (the client has 
dedicated IPs, we switched to shared ones to send to Outlook.com), and while a 
previous test wasn't conclusive a few weeks before, this time it worked: 
messages were delivered in inbox and stayed there.
That lasted for two weeks, now we're getting the same issue of dest:I, then 
moved to Junk after a few seconds. The Support still doesn't answer to this, 
but I didn't receive a "ticket is closed thxbye" notification for 
SRX1448704980ID so far.
I don't plan to play switching to other IPs again, that's not how we roll and 
the fact that a big receiver would "force" a good sender to do so leaves me 
speechless. I know it's (probably) not on purpose, but there's apparently a 
flaw in the bug reporting process.

ANYWAY, I didn't came back _solely_ to complain, I also have a new element to 
add: I added the sending domain in whitelist of my @outlook.com personal 
account. I sent myself a test. Result: dest:I, then moved to junk.

Apparently I'm not the only one: 
https://outlook.uservoice.com/forums/601444/suggestions/34103461

Michael, if you have colleagues to poke, I'm of course at your disposal to 
provide any relevant data or feedback they'd need.

Cheers, and happy few last days of 2018!

--
Benjamin

From: Michael Wise 
Sent: jeudi 6 décembre 2018 20:17
To: Benjamin BILLON ; Al Iverson ; 
mailop 
Subject: RE: [mailop] Outlook.com Support (whining time)


That sounds like, “TimeTravel”. Hmm.
That’s what we call retroactively moving things to Junk if it looks too much 
like a spam campaign in the eyes of the machine.

I’ll forward this to others who are in a better position to investigate it.
All I can go on, usually, is the Dest:I or J.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?

From: Benjamin BILLON mailto:bbil...@splio.com>>
Sent: Thursday, December 6, 2018 9:15 AM
To: Michael Wise 
mailto:michael.w...@microsoft.com>>; Al Iverson 
mailto:aliver...@aliverson.com>>; mailop 
mailto:mailop@mailop.org>>
Subject: RE: [mailop] Outlook.com Support (whining time)

Hi Michael,

When you say the wording is very important, do you mean that "please escalate" 
isn't correct? I just tried the word "escalation" (I checked, I didn't use this 
one exactly yet), we'll see. If there's another wording to use ... I'd love to 
know it =)

The "proof" I have that emails are reaching inbox is that I can reproduce and 
see it happening right in front of me. It's in inbox, then disappears after a 
few seconds, popping in junk. Headers show dest:I, and not dest:J like other 
messages I could find in Junk folder.

Cheers,
--
Benjamin

From: Michael Wise 
mailto:michael.w...@microsoft.com>>
Sent: mardi 4 décembre 2018 21:52
To: Al Iverson mailto:aliver...@aliverson.com>>; 
Benjamin BILLON mailto:bbil...@splio.com>>
Cc: mailop mailto:mailop@mailop.org>>
Subject: RE: [mailop] Outlook.com Support (whining time)




Oops.

Please understand that the wording is VERY important.

The email may in fact be getting to the mailbox SERVER, but there is no 
guarantee that it is not in fact being delivered to junk.



And if that was me, sorry, been crazy busy recovering from Thanksgiving Madness.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fdownload%2Fdetails.aspx%3Fid%3D18275=02%7C01%7CMichael.Wise%40microsoft.com%7Cc7bcd1fc959549f8cb0708d65b9e4b63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636797132832134756=zNfzyPQ4G49%2FNVVvqTHABlTSf%2Ft30LBHaRPT%2Fht4W%2FQ%3D=0>
 ?



-Original Message-----
From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Al Iverson
Sent: Tuesday, December 4, 2018 10:27 AM
To: Benjamin BILLON mailto:bbil...@splio.com>>
Cc: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Outlook.com Support (whining time)



Hey Benjamin, I am having similar (I think) problems over here where I request 
mitigation or feedback regarding junk folder delivery and no matter what I say, 
MS sender support says everything is fine, even though the mail is clearly not 
going to the inbox.



I would even be happy to get a response that says "this mail is going to the 
junk folder appropriately based on sending reputation" but nothing like that 
comes. It is always, "we see no issue and don't understand what you're asking." 
I keep asking to escalate as well, to no avail.



I am wondering if perhaps some filtering at Microsoft could be broken.

I reached out to one Microsoft contact last

Re: [mailop] Mailing List Address Formats..

[Benjamin BILLON]

https://www.jochentopf.com/email/chars.html

--
Benjamin

From: mailop  On Behalf Of David Carriger
Sent: vendredi 11 janvier 2019 18:49
To: Al Iverson ; Michael Peddemors 

Cc: mailop 
Subject: Re: [mailop] Mailing List Address Formats..


I'm afraid you're going to be disappointed.



https://en.wikipedia.org/wiki/Email_address#Local-part
Email address
en.wikipedia.org
An email address identifies an email box to which email messages are delivered. 
A wide variety of formats were used in early email systems, but only a...

The RFC allows you to put a LOT in the localpart without any sort of fanfare, 
and you can do almost any stupid thing you want as long as you quote it.


From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Al Iverson mailto:aiver...@wombatmail.com>>
Sent: Friday, January 11, 2019 10:45 AM
To: Michael Peddemors
Cc: mailop
Subject: Re: [mailop] Mailing List Address Formats..

Return-path headers using VERP in this way, with asterisks in the
username part like this, can be traced all the way back to LISTSERV in
the 1990s.  It's a long standing practice. If you block based on this,
you'll block a few spammers or commercial mailers who used or use
LISTSERV, or who rolled their own mailing list software in a way where
they copied the VERP styling exactly, but you'll also probably block
lots of academia and random non-spammy discussion lists.

When I worked for Digital River approximately 150 years ago, we had an
internal platform that had its own databases and UI for list
management and campaign configuration, and then when you hit "send" an
email template was built that was then handed off to the LISTSERV
server which then did all the building of the messages. The
Return-Path header for these messages was always of the format
owner-nolist-x-y*username**domain*-suffix@sender.

Regards,
Al Iverson


On Fri, Jan 11, 2019 at 12:36 PM Michael Peddemors
mailto:mich...@linuxmagic.com>> wrote:
>
> owner-nolist-cp_enews-190110p-gqfjbpue*username**domain*-suf...@digital.annexbusinessmedia.com
>
> (Where 'username', 'domain','suffix' are placeholders)
>
> I don't know of this particular mailer, but can I get some feedback to
> confirm that the '*' character is not a permitted character in an email
> address? (user name portion)
>
> Or has there been a change to RFC's that I am not aware of?
>
> Grepping of logs, only shows a couple cases of it.. but wanted feedback
> on this, as some as you can see are important legitimate senders..
>
> owner-at-l*username**domain*-suf...@listserv.sde.ok.gov
> owner-nolist-190110n-f3yuf778*username**domain*-suf...@prdlsv1nu.shaw.ca
> owner-abajournal_weekly_allnon*username**domain*-n...@mail.americanbar.org]
> owner-news_release_e*username**domain*-c...@lserv.pmo-cpm.gc.ca
> owner-nolist-tdw-20190110-cet*username**domain*-c...@listserv.td.com
>
>
>
>
>
> --
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
Wizard IT Services - Web Hosting, Network Solutions, Internet 
Services
www.wizard.ca
Wizard IT provides support and services for the ISP, Telco and Enterprise 
markets. Specializing in Linux Development, Linux Solutions, and ISP 
Infrastructure, Wizard Tower TechnoServices is also the parent company for 
LinuxMagic and City Email, and provides mail server and anti-spam products, as 
well as hosted and outsourced solutions and custom development.



> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



--
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
Al Iverson's Spam 

Re: [mailop] Outlook.com Support (whining time)

[Benjamin BILLON]

Ah, I would have answered off-list, but since it's here, I can certainly reply 
here.

Preamble: if there's a better channel than Mailop to give Microsoft an educated 
feedback about an apparent disfunction of their service, please let me know. I 
already tried quite a few "official" others with no result. Also, we've been 
patient and polite, maybe too much. You don't take care of patient people's 
problems, you prioritize those of the loud ones (yellow jacket, anyone?). It's 
all human. As for Gmail Postmaster Tools APIs, if the email community doesn't 
make noise enough to be heard by Google that we want those and why, chances are 
we'll never get them (and I said I would work on making some noise, and still 
didn't yet, I'm also only human, apparently).
A _lot_ of senders are hitting issues with Outlook.com. A lot of them 
understands that it's not an easy issue to fix, and that it's less a priority 
than catching phishing, pedophilia contents or other things that make Outlook's 
people sweat, but it doesn't mean that it's not a real problem that shouldn't 
be fixed at some point. A lot of senders are also staying quiet, for various 
reasons, but are still sharing the same legitimate frustration.

So, dear readers, there's a new piece of information since earlier today: I 
found out that the "weird behavior" came back, but not on the shared IPs I said 
I switched that client into. Indeed, for an unknown reason that my team is 
trying to figure out, the client's last few sendings (those with the issue) 
were sent from their dedicated IPs. So with the same issue as before the switch 
of IPs.
That means there's no new signal that Outlook.com or its users are _still_ 
considering the emails are unwanted with the new IPs.
Although I understand that having the same issues after switching IPs could 
mean that there was a problem of traffic quality with previous IPs, and it's 
still there with the new ones, that would be ignoring the impact a domain name, 
a sender's email address, or other elements of an email can have. We know 
Microsoft relies a lot on IPs, but we also saw it stumbles quite often (some 
IPs with no traffic change, or no traffic at all, are getting blocked out of 
nowhere).

Turns out that the only piece of news in my previous message was that despite 
whitelisting the sender's domain name, the "TimeTravel" behavior still occurs, 
which straightens me in the idea that there's a bug on Outlook.com's side.

Now to reply Laura's points (there's nothing confidential here, I have not much 
to hide, and it could benefit to others in various ways):

> 1) Mail going to the bulk folder? That sign says: Your mail is bad, our users 
> don’t want it and we’re going to protect them from it.
This is the common understanding of it, yes. Minus false positives.
Just in case I didn't say it already, this traffic is very legitimate opt-ins, 
messages are nice, inactives are excluded, 40% open rates on average, etc. : 
the perfect client an ESP can dream of.

> 2)  Mail going to the bulk folder after reaching the inbox because you 
> changed IPs? Our users are telling us that when we put your mail in the inbox 
> they don’t want it there.
That would be a big hint indeed; but as explained, my case is in fact not in 
this scenario.

> 3) The closing of tickets without any response?  We’ve told you repeatedly 
> what you need to do to fix things and you aren’t paying any attention. We’re 
> tired of sending you the same information, and there’s nothing more we’re 
> able to tell you.
That could work for several Support teams I know of, but copy/pasting 
irrelevant texts (because that's all the support agents are legally allowed to 
do) isn't what you're depicting. In the context of Outlook.com's support for 
instance, it doesn't work that way.
Maybe it's "we are not allowed to answer anything else than the copy/pasted 
stuff so we just won't reply at all", hence my initial and unanswered request 
for escalation.
If I continue to push for this ticket, it's in the hope that someone will be 
looking at SLA and other statistics like Support team managers do: time of 
response, number of tickets per agent, number of replies, etc. and that maybe 
some light will be shed on the case. Yet another channel where I try to be 
heard.

> 4) The overruling of address book whitelisting? This mail is so bad and the 
> sender has such a poor reputation, we’re not going to let it go to the inbox 
> even when the user adds the sender to their inbox.
Ow come on. Seriously? I prefer to consider you're trolling here.
This would be a very bad way to deal with users' preferences, but after all, if 
a system thinks he knows better than its users, why not? (Yes I'm the one 
trolling now)


Cheers,
--
Benjamin

From: Laura Atkins 
Sent: vendredi 28 décembre 2018 14:00
To: Stefano Bagnara 
Cc: mailop ; Benjamin BILLON ; Michael 
Wise 
Subject: Re: [mailop] Ou

Re: [mailop] List of unused, big email-domains?

[Benjamin BILLON]

I didn't find shorter than "List of domain names formerly used to receive 
massive amounts of emails" for the title of the page, if someone has a better 
idea, please sho[o|u]t ...

--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Benjamin BILLON
Sent: mardi 8 janvier 2019 20:19
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

RBL would be useful but I can start a list of defunct domains based on my 
experience, my email history and a few logs. I can't publish a RBL in a blink.
Also in my case, I wouldn't need a MTA to consume the list, I just want to have 
a list, with a date (or a year) of when the domain stopped asking to receive 
emails, so when I spot those domains I would have an indication of the age of 
the database, and do something with that.
It would also show an interesting history of the merges and deaths of emailing 
ecosystems on the Internet.
I'm not convinced about the need to highly document that, and official shutdown 
pages have high chances of being shut as well not long after the domain. But 
there's no problem to describing too much either.
We could also ask Al, or Laura, to maintain this list, but I believe they 
wouldn't mind a little community effort instead. 

I'll create the page on Wikipedia tomorrow, if nobody does it first =)

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Grant Taylor via mailop
Sent: mardi 8 janvier 2019 19:58
To: mailop@mailop.org
Subject: Re: [mailop] List of unused, big email-domains?

On 01/08/2019 10:32 AM, John Levine wrote:
> A lot of them have been turned into spamtraps after rejecting mail for 
> a year or so.  For obvious reasons, the people using them will not 
> tell you what they are.

I think there is a significant difference in a list of defunct sending domains 
and a list of spam traps.

I can see how there is some overlap.  But I don't think that concern of the 
latter precludes the former.

Also, it would be trivial for spam trap operators to disqualify their domains 
by stating that they do send email from said domains.



--
Grant. . . .
unix || die

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

Re: [mailop] Questions about Interia.pl deferrals

[Benjamin BILLON]

Hi Matt,

I'm afraid this isn't a good news.
This and other Polish ISPs are deferring emails on purpose, to encourage 
senders to pay for delivery.

--
Benjamin

From: mailop  On Behalf Of Matt Gilbert via mailop
Sent: lundi 7 janvier 2019 18:14
To: mailop@mailop.org
Subject: [mailop] Questions about Interia.pl deferrals

Hi Mailop!

I was hoping there was someone from Interia.pl here that could reach out to me 
off list about an elevated deferral rate we’ve been seeing for a couple of 
weeks.


Thanks,
Matt Gilbert
--
Deliverability Engineer | Mailchimp
delivery.mailchimp.com

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

Re: [mailop] mail to Outlook accepted, then vanishing

[Benjamin BILLON]

Yeah, an extremely bad reputation can do that at Outlook.com.

Are the open rates really low for emails sent from this or those IPs?

--
Benjamin

From: mailop  On Behalf Of Ricardo Signes
Sent: vendredi 29 mars 2019 15:02
To: mailop@mailop.org
Subject: [mailop] mail to Outlook accepted, then vanishing

Hiya,

Lately, we're seeing a lot of mail from us (FastMail) being accepted by 
Outlook[.com], but then never reaching its destination inbox.  It's not in a 
junk folder or somewhere else.  It seems like Outlook is accepting the mail and 
then dropping it on the floor somewhere.  Obviously, this isn't great for out 
users.

Here's an example SMTP interaction between us and Outlook:

2019-03-29T09:44:11-04:00 gateway2 postfix-out/smtp[3294666]: A421222096: 
to=mailto:operatester...@outlook.com>>, 
relay=outlook-com.olc.protection.outlook.com[104.47.1.33]:25, delay=2.3, 
delays=0.05/0/0.69/1.5, dsn=2.6.0, status=sent (250 2.6.0 
mailto:c6883afe-2d47-40b2-be0d-73b897c7f...@beta.fastmail.com>>
 [InternalId=18708877624108, 
Hostname=VE1EUR01HT199.eop-EUR01.prod.protection.outlook.com] 10961 bytes in 
0.465, 23.013 KB/sec Queued mail for delivery -> 250 2.1.5)

We've filed a ticket, but I don't think we've had any response, and it's a 
scary problem, since we can't detect anything to tell users.  Anybody know what 
can cause this behavior?

--
Ricardo Signes (rjbs)
Postmaster, FastMail

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

Re: [mailop] mail to Outlook accepted, then vanishing

[Benjamin BILLON]

Hi Rob,

You appear to be extrapolating; the only case I know of blackholed emails are 
by Outlook.com, when the sending reputation is really bad. Other ISPs usually 
reject the message explicitely. Hence my question about the open rate: maybe 
it's not globally low on Outlook.com, meaning this issue doesn't happen for all 
or many recipients, but only on this testing account where the user can't find 
the email despite the 250 reply. It's very basic support procedure, when 
someone is asking for help, to make sure we all have the same level of 
information.

What might be happening is that Microsoft considers this IP address has a very 
bad reputation, resulting in blackholed emails, even if there's no visible data 
(or at all) to back that up. We had IPs flagged as "blocked" despite not 
sending any traffic, so the behavior sounds similar.

--
Benjamin

From: Rob McEwen 
Sent: vendredi 29 mars 2019 17:02
To: Benjamin BILLON ; Ricardo Signes 
; mailop@mailop.org
Subject: Re: [mailop] mail to Outlook accepted, then vanishing

On 3/29/2019 11:42 AM, Benjamin BILLON wrote:
Yeah, an extremely bad reputation can do that at Outlook.com. Are the open 
rates really low for emails sent from this or those IPs?

Benjamin,

the outlook/hotmail side of Microsoft has been out-of-control this past year, 
and if everyone else applied to them the same draconian standards that they 
sometimes apply to so many others - ALL of outlook/hotmail's sending-IPs  would 
start getting blocked EVERYWHERE! The truth is - everyone leaks a little spam 
on occasions due to things like compromised accounts. But the problem here is 
that outlook/hotmail's responses to things like that have been very 
bizarre/draconian, where they have little consideration for collateral damage, 
and where they sometimes apply permanent blocks to short-term security issues 
that were ALREADY fixed. Again, imagine if the SAME standards were applied to 
outlook/hotmail's outbound email? Over the years, they have sent a MASSIVE 
amount of spam from their outbound IPs.

So please don't assume that this is FastMail's issue!

--

Rob McEwen, invaluement




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

Re: [mailop] deactivation of hard bounces

[Benjamin BILLON]

Tricky; we have a similar case, but not specifically B2B.
The sender is complaining that a bunch of addresses flagged as hard are in fact 
not bouncing when they test them.
The samples they provided is mostly Outlook.com, and a bit of Gmail. So they're 
most probably complaining that what we flagged hard bounces are now 
Outlook.com's spamtraps.
(I can't really tell about Gmail though).
We could tell more by a) checking the spamtrap count on SNDS (but do we really 
want to?) and b) checking if there's any reaction from these addresses (but 
spamtraps can also "react" if they want to).

Sure, mistakes happen, both on the receiver's and on the sender's side. But for 
us the balance benefit/risk isn't worth it. Senders complaining about a few 
false-positive hard bounces probably should be spending their time and energy 
on data collection and practices instead.

So we have to de-hard a few addresses every few years, when one ISP messes up. 
We can live with that.

--
Benjamin

From: mailop  On Behalf Of Marco Franceschetti via 
mailop
Sent: lundi 4 mars 2019 10:16
To: Maarten Oelering 
Cc: mailop@mailop.org
Subject: Re: [mailop] deactivation of hard bounces

Hi Maarten

By one specific customer, whose lists are more b2b oriented to be honest, we 
enountered a false positive rate of abount 7%.
This customer regularly sends to us small lists of addresses to be reactivated 
– and I must say, these do not bounce.
So, I think a further investigation on this matter is worth.

Sure, we use text, enhanced status code and status code to classify the bounces 
in our bounce rule management process.
It the rules don’t match, we classify the bounce as “unknown” and we examinate 
the unknown bounce regularly to do some fine tuning.

Kind regards
Marco


From: Maarten Oelering mailto:maar...@postmastery.com>>
Sent: mercoledì 27 febbraio 2019 22:02
To: Marco Franceschetti 
mailto:marco.francesche...@contactlab.com>>
Cc: mailop@mailop.org
Subject: Re: [mailop] deactivation of hard bounces

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the enhanced 
status code, and the status code. If the bounce is clearly an invalid address, 
then remove it after the first bounce. For example when the text contains 
“mailbox” or a synonym, and “unknown” or a synonym. Bounces which are 
ambiguous, or with inconsistent features should be treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | 
Milano
contactlab.com/it

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

Re: [mailop] Anyone from GitHub here?

[Benjamin BILLON]

Hi Philip, they absolutely do, let me forward your email to them.

Cheers, 
--
Benjamin

-Original Message-
From: mailop  On Behalf Of Philip Paeps
Sent: mercredi 6 mars 2019 08:54
To: mailop 
Subject: [mailop] Anyone from GitHub here?

I share my mailserver with several GitHub users.  Recently, we've all been 
getting recruitment spam to addresses mined from GitHub.

I wonder if GitHub cares about their platform being used for harvesting.

Email to ab...@github.com appears to be ignored.

Anyone from GitHub on this list?

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

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

Re: [mailop] Issue receiving fbl reports from laposte.net

[Benjamin BILLON]

After thourough checking, we still received a (very) few complaints on March 
12th to 14th (so non-null), and it's increasing since 15th. It might be back to 
the usual count today.

--
Benjamin

From: Benjamin BILLON
Sent: vendredi 15 mars 2019 11:08
To: 'mailop' 
Subject: RE: [mailop] Issue receiving fbl reports from laposte.net

They're checking with ReturnPath.

--
Benjamin

From: Benjamin BILLON
Sent: vendredi 15 mars 2019 09:02
To: 'Al Iverson' mailto:aiver...@wombatmail.com>>; 
mailop mailto:mailop@mailop.org>>
Subject: RE: [mailop] Issue receiving fbl reports from laposte.net

Same here for the FBL, although the Signal-Spam counters still indicates 
non-null values.

I'll ask them

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Al Iverson
Sent: jeudi 14 mars 2019 20:18
To: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Issue receiving fbl reports from laposte.net

Yep, we're seeing that here as well. Both for LaPoste and for OpenSRS/Tucows.

Cheers,
Al Iverson
Salesforce Marketing Cloud


On Thu, Mar 14, 2019 at 2:56 PM Mathew Hodges via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

I'm a deliverability engineer with Mailchimp. We noticed that on March 11 we 
stopped receiving fbl reports from laposte.net<http://laposte.net>. Our last 
message came in at Mon, 11 Mar 2019 13:04:20 +. We aren't noticing any lack 
of data from other domains, including those serviced by Return Path.
I reached out to Return Path customer service and they mentioned everything was 
enabled and active on their end to send fbl reports. I have also been able to 
confirm that our inbox that receives these fbl reports isn't full and is 
receiving messages successfully. Our fbl is still registered and active for our 
full IP range.
For reference, our sending IP ranges are as follows:
205.201.128.0/20<http://205.201.128.0/20>
198.2.128.0/18<http://198.2.128.0/18>
148.105.0.0/16<http://148.105.0.0/16>
Our sending domains are:
mandrillapp.com<http://mandrillapp.com>
rsgsv.net<http://rsgsv.net>
mcsv.net<http://mcsv.net>
mcdlv.net<http://mcdlv.net>
mctxapp.net<http://mctxapp.net>
mailchimpapp.net<http://mailchimpapp.net>
I wanted to check if anyone else was seeing the same issue? If so, was anyone 
able to find a resolution?

--
Mathew Hodges
Deliverability Engineer
mathew.hod...@mailchimp.com<mailto:mathew.hod...@mailchimp.com>

[https://docs.google.com/uc?export=download=1xsT1_GR77qM_27jexp4KnTa2W3piQCff=0Bz7a5qlFmAsOdHYzdVJKODVxeFV4MldZUHBOcXN0aVVMOThnPQ]
___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


--
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mailing list with From header munging... and Outlook

[Benjamin BILLON]

So, the question is rather why Jesse and Michael's messages contain a Reply-To: 
header, and not yours.
(What will my contain? Surprise surprise! Using Outlook)

While we're here blaming Outlook for things it might or might not do properly, 
it's simply insane that it let senders be impersonated in such an easy way:

[cid:image001.png@01D4D8A8.4D8A1F70]
(Subject's prefix and body's banner are due to a custom Exchange Transfer Rules 
in 0365, without it the message would have gone straight to inbox)

The headers are:

From: "no-re...@sharepointonline.com" 
To: 

There's no option in Outlook to display the sender's address along with (or 
instead of) the sender's name.

--
Benjamin

From: mailop  On Behalf Of Neil Jenkins
Sent: mardi 12 mars 2019 02:44
To: Mailop 
Subject: Re: [mailop] Mailing list with From header munging... and Outlook

On Tue, 12 Mar 2019, at 09:26, Jesse Thompson via mailop wrote:
When someone reply-alls to a munged message it only composes a message to the 
Reply-to and the Cc, but ignores the From (the list address is munged into the 
From header).

That sounds exactly what I would expect for "Reply All"; it's certainly what's 
implemented at FastMail.

  *   Reply => message is "to" either the Reply-To address if specified, 
otherwise the From address.
  *   Reply All => Contents of To/Cc of message being replied to are also added 
to the new email (except for your address).

I would be very surprised to see a client add both the From and Reply-To 
address as recipients on reply-all. Let's see what RFC5322 
says:


   When a message is a reply to another message, the mailboxes of the

   authors of the original message (the mailboxes in the "From:" field)

   or mailboxes specified in the "Reply-To:" field (if it exists) MAY

   appear in the "To:" field of the reply since these would normally be

   the primary recipients of the reply.  If a reply is sent to a message

   that has destination fields, it is often desirable to send a copy of

   the reply to all of the recipients of the message, in addition to the

   author.  When such a reply is formed, addresses in the "To:" and

   "Cc:" fields of the original message MAY appear in the "Cc:" field of

   the reply, since these are normally secondary recipients of the

   reply.

Yes, that sounds about right.

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

Re: [mailop] Issue receiving fbl reports from laposte.net

[Benjamin BILLON]

Same here for the FBL, although the Signal-Spam counters still indicates 
non-null values.

I'll ask them

--
Benjamin

From: mailop  On Behalf Of Al Iverson
Sent: jeudi 14 mars 2019 20:18
To: mailop 
Subject: Re: [mailop] Issue receiving fbl reports from laposte.net

Yep, we're seeing that here as well. Both for LaPoste and for OpenSRS/Tucows.

Cheers,
Al Iverson
Salesforce Marketing Cloud


On Thu, Mar 14, 2019 at 2:56 PM Mathew Hodges via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

I'm a deliverability engineer with Mailchimp. We noticed that on March 11 we 
stopped receiving fbl reports from laposte.net. Our last 
message came in at Mon, 11 Mar 2019 13:04:20 +. We aren't noticing any lack 
of data from other domains, including those serviced by Return Path.
I reached out to Return Path customer service and they mentioned everything was 
enabled and active on their end to send fbl reports. I have also been able to 
confirm that our inbox that receives these fbl reports isn't full and is 
receiving messages successfully. Our fbl is still registered and active for our 
full IP range.
For reference, our sending IP ranges are as follows:
205.201.128.0/20
198.2.128.0/18
148.105.0.0/16
Our sending domains are:
mandrillapp.com
rsgsv.net
mcsv.net
mcdlv.net
mctxapp.net
mailchimpapp.net
I wanted to check if anyone else was seeing the same issue? If so, was anyone 
able to find a resolution?

--
Mathew Hodges
Deliverability Engineer
mathew.hod...@mailchimp.com

[https://docs.google.com/uc?export=download=1xsT1_GR77qM_27jexp4KnTa2W3piQCff=0Bz7a5qlFmAsOdHYzdVJKODVxeFV4MldZUHBOcXN0aVVMOThnPQ]
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


--
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Free.fr contact

[Benjamin BILLON]

As mentioned in http://postmaster.free.fr/, 
postmas...@proxad.net is the way to go.

--
Benjamin

From: mailop  On Behalf Of Andrew Gosney
Sent: mardi 19 février 2019 00:54
To: J Orlando Letra via mailop 
Subject: [mailop] Free.fr contact


Hi mailop community,

Are there any contacts at free.fr that would be able to reach out to me?

Cheers,
Andrew

Andrew Gosney

supp...@mimecast.com

www.mimecast.com

MSOC Regional Manager

p: +61 3 9017 5101

Address click here


[http://www.mimecast.com/]




[LinkedIn]


[YouTube]


[Facebook]


[Blog]


[Twitter]






[EIA MQ 
Leader]



Disclaimer
The information contained in this communication from 
agos...@mimecast.com sent at 2019-02-19 08:53:39 
is confidential and may be legally privileged. It is intended solely for use by 
mailop@mailop.org and others authorized to receive 
it. If you are not mailop@mailop.org you are hereby 
notified that any disclosure, copying, distribution or taking action in 
reliance of the contents of this information is strictly prohibited and may be 
unlawful.

This email message has been scanned for viruses by Mimecast. Mimecast delivers 
a complete managed email solution from a single web based platform. For more 
information please visit http://www.mimecast.com

Visit our preference center to change how often you hear from us: Preference 
Center.






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

Re: [mailop] testing with gmail

[Benjamin BILLON]

What does Google Postmaster Tools say?


--
Benjamin

From: mailop  On Behalf Of Randall Diffenderfer via 
mailop
Sent: lundi 4 février 2019 18:07
To: mailop@mailop.org
Subject: [mailop] testing with gmail

i have a need to be able to send some messages to my gmail address.  the source 
that i control has a non-existent rep, so that isn't happening.

can anybody assist someone "in the biz" please?


<** 421-4.7.0 [63.237.219.41  15] Our system has detected that this message 
is

<** 421-4.7.0 suspicious due to the very low reputation of the sending IP 
address.

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

Re: [mailop] Are there any de facto standards around no-reply@ addresses?

[Benjamin BILLON]

The answer to your question is "no there is not".

I can see disadvantages of having one.

I guess you have to decide whether or not you want to auto-reply to no-reply@ 
addresses!

--
Benjamin

-Original Message-
From: mailop  On Behalf Of Grant Taylor via mailop
Sent: jeudi 11 avril 2019 04:33
To: mailop@mailop.org
Subject: Re: [mailop] Are there any de facto standards around no-reply@ 
addresses?

On 4/10/19 8:11 PM, Jay Hennigan wrote:
> I hold a very low opinion of any business entity that sends me 
> automated email and either deliberately chooses to ignore my reply or 
> forces me to jump through hoops in order to reply via a web form or such.

The use case that has me asking is in some ways more dastardly than that.

Think $BigCompany1 having a home grown ticketing system that uses email talking 
to $BigCompany2 that also has a home grown ticketing system using email and the 
complications that can ensue when one and / or the other don't implement sanity 
checks like those outlined in RFC 3834.

Hence the question ~> discussion about one of the big companies ""enhancing 
their home grown ticketing system to not send messages to noreply@ email 
addresses, even if the notification that prompted something did come from 
there.  (Assume that there are anywhere between
3 and 30 other email addresses on a ticket.)

I don't know the exact criteria that precipitated the loop (there's a chance 
that someone on one end or the other added their own system as a CC to receive 
copies).

> If it's important enough for them to trouble a customer or potential 
> customer, it should be important enough for them to listen to what 
> that customer or potential customer has to say about it.

Agreed.

> Even if it's a notification I've requested, the concept of write-only 
> email smacks of poor customer service IMHO.




--
Grant. . . .
unix || die

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

Re: [mailop] Anyone from free.fr on the list?

[Benjamin BILLON]

And make sure to have your homework done, be clear, concise and provide details 
of how you fixed the issue.
If it's not totally fixed and you get blocked again, he'll have other things to 
do than reply to you.

--
Benjamin

From: mailop  On Behalf Of Mathieu Bourdin
Sent: vendredi 12 avril 2019 13:54
To: Sidsel Jensen ; mailop 
Subject: Re: [mailop] Anyone from free.fr on the list?

Hi,

You can reach out to postmas...@proxad.net (home 
company for free.fr). The guy in charge is usually quite reactive but, as he is 
alone, it might depend of his schedule.

Mathieu B.


De : mailop mailto:mailop-boun...@mailop.org>> De la 
part de Sidsel Jensen
Envoyé : vendredi 12 avril 2019 13:39
À : mailop mailto:mailop@mailop.org>>
Objet : [mailop] Anyone from free.fr on the list?

Hi

We had a spam outbreak (mainly Paypal stuff) targetted towards accounts on 
free.fr and I’ve been struggling to get it cleaned up.
Some of our sending IPs are still blacklisted though..

If there is someone from free.fr on the list - please reach out 
to me off the list
- Thanks :-)

Kind Regards,
Sidsel Jensen
Systems Engineer @ One.com
s...@one.com





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

Re: [mailop] 2 Return-Path headers?

[Benjamin BILLON]

Hey Autumn,

My guess: more than one Return-Path: header isn't "illegal" (as "SMTP servers 
making final delivery MAY remove Return-path headers before adding their own.", 
from 2821), but in the meantime, SPF should be checked on the unique MAIL FROM: 
command value, not on the value of the header.
I'm not clear if additional Return-Path headers are prepended (like Received: 
ones) or appended.

You could tell with the Received: headers, but maybe the sender sends the email 
to the ESPs' MTA, which adds the first Return-Path:, then submits the email to 
the final recipients, which for some reasons doesn't delete the existing 
Return-Path:, and just adds another one. The one related to the ESP.
So it would kind of make sense, even though it's not what's initially expected?

(I don't recall I already saw something like that)

Cheers,

--
Benjamin
From: mailop  On Behalf Of Autumn Tyr-Salvia
Sent: jeudi 11 avril 2019 21:01
To: Mailop 
Subject: [mailop] 2 Return-Path headers?

Hello,

I'm looking at headers for a particular message, and noticed two different 
Return-Path headers. The message is being sent by an ESP. One Return-Path uses 
a VERP address with the ESP's domain, and the other uses the same address as 
the friendly From:.

I haven't seen this in other headers before - is this common? Why would there 
be 2? I spent some quality time with RFC 2822 and couldn't determine if it's 
spec-legal to have two Return-Path headers or not. More to the point, it's 
using the one with the ESP domain for checking SPF, which is not what the 
desired behavior.

I can reach out directly to the ESP in question to get more info, but wanted to 
ask this group first if there's some other resource I should consult for a firm 
understanding of using multiple Return-Path headers before I have that 
conversation.


Thanks,

Autumn Tyr-Salvia
tyrsalvia@gmail
atyrsalvia@agari
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Issue receiving fbl reports from laposte.net

[Benjamin BILLON]

They're checking with ReturnPath.

--
Benjamin

From: Benjamin BILLON
Sent: vendredi 15 mars 2019 09:02
To: 'Al Iverson' ; mailop 
Subject: RE: [mailop] Issue receiving fbl reports from laposte.net

Same here for the FBL, although the Signal-Spam counters still indicates 
non-null values.

I'll ask them

--
Benjamin

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Al Iverson
Sent: jeudi 14 mars 2019 20:18
To: mailop mailto:mailop@mailop.org>>
Subject: Re: [mailop] Issue receiving fbl reports from laposte.net

Yep, we're seeing that here as well. Both for LaPoste and for OpenSRS/Tucows.

Cheers,
Al Iverson
Salesforce Marketing Cloud


On Thu, Mar 14, 2019 at 2:56 PM Mathew Hodges via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

I'm a deliverability engineer with Mailchimp. We noticed that on March 11 we 
stopped receiving fbl reports from laposte.net<http://laposte.net>. Our last 
message came in at Mon, 11 Mar 2019 13:04:20 +. We aren't noticing any lack 
of data from other domains, including those serviced by Return Path.
I reached out to Return Path customer service and they mentioned everything was 
enabled and active on their end to send fbl reports. I have also been able to 
confirm that our inbox that receives these fbl reports isn't full and is 
receiving messages successfully. Our fbl is still registered and active for our 
full IP range.
For reference, our sending IP ranges are as follows:
205.201.128.0/20<http://205.201.128.0/20>
198.2.128.0/18<http://198.2.128.0/18>
148.105.0.0/16<http://148.105.0.0/16>
Our sending domains are:
mandrillapp.com<http://mandrillapp.com>
rsgsv.net<http://rsgsv.net>
mcsv.net<http://mcsv.net>
mcdlv.net<http://mcdlv.net>
mctxapp.net<http://mctxapp.net>
mailchimpapp.net<http://mailchimpapp.net>
I wanted to check if anyone else was seeing the same issue? If so, was anyone 
able to find a resolution?

--
Mathew Hodges
Deliverability Engineer
mathew.hod...@mailchimp.com<mailto:mathew.hod...@mailchimp.com>

[https://docs.google.com/uc?export=download=1xsT1_GR77qM_27jexp4KnTa2W3piQCff=0Bz7a5qlFmAsOdHYzdVJKODVxeFV4MldZUHBOcXN0aVVMOThnPQ]
___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


--
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outage at Orange

[Benjamin BILLON]

Problem has been solved, we're asked to resume (gradually if possible) the 
sending!

--
Benjamin

From: mailop  On Behalf Of Benjamin BILLON
Sent: jeudi 25 avril 2019 10:30
To: mailop 
Subject: [mailop] Outage at Orange

Hi there, for those awake, Orange (France) is facing an outage so not much 
traffic is going through. If you can pause your sending to their domains, that 
could help!

--
Benjamin

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

[mailop] Outage at Orange

[Benjamin BILLON]

Hi there, for those awake, Orange (France) is facing an outage so not much 
traffic is going through. If you can pause your sending to their domains, that 
could help!

--
Benjamin

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

Re: [mailop] Google Postmaster Tools: spam rates

[Benjamin BILLON via mailop]

Digging up this topic,

@Anna> you might have had some feedback from Google about that since your
message?

I can still sleep at night, but I'm curious about the outcome!
-- 

Benjamin

2017-05-31 18:23 GMT+02:00 Nick Schafer :

> The feedback loop shouldn't include messages caught by their spam filter
> as users aren't able to complain against a message already in the spam
> folder. The feedback loop is used to identify campaigns in a sender's
> traffic that are getting a high volume of complaints from Gmail users. From
> my understanding the user reported spam number would be the overall rate
> that day for that DKIM domain while the feedback loop would be for the
> identifier specified. But if the only messages they sent that day had the
> broadcast identifier, i would expect the rates to be much closer. Maybe an
> error or someone complaining then marking not spam, and then doing the same
> thing over and over?
>
> Nick Schafer
> Technical Account Manager, Mailgun 
> m:(210) 833-3933
>
> On Wed, May 31, 2017 at 5:53 AM, Paul Smith  wrote:
>
>> On 31/05/2017 10:29, Anna Ward wrote:
>>
>> I've talked to a bunch of different industry folks at this point, and no
>> one seems to understand the difference between "user reported spam" and
>> "feedback loop spam" in Google Postmaster Tools
>> .
>>
>> A notable example for me was May 8th when a client's DKIM domain showed a
>> 100% "feedback loop spam rate" but only a 0.1% "user reported spam rate" (
>> screenshots ).
>> They sent to about 4000 Gmail addresses that day, and the one identifier
>> in the Feedback Loop graph was "broadcast" (represents the message type, a
>> bulk-send newsletter). All of their outgoing mail used the "broadcast"
>> identifier like this: Feedback-Id: ::broadcast:getresponse
>>
>> I just can't think of a scenario where the Feedback Loop could be at 100%
>> but the Spam Rate ("user reported") would be at only 0.1%. How are such
>> drastic differences possible?
>>
>>
>> If the feedback loop includes messages caught by their spam filter, then
>> if their spam blocked everything, that would show 100% as spam, but most
>> users wouldn't see the spam or bother reporting it as spam (because it's
>> already been caught) so the user reported spam rate would be approaching
>> zero.
>>
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail labeled as Spam based on content

[Benjamin BILLON via mailop]

In the case of Gmail, you can have _some_ hint about your domain's
reputation with the Gmail Postmaster Tools https://gmail.com/postmaster/

@Laura> nice article, would it also apply to Hotmail, from your opinion?

Cheers,


-- 

Benjamin

2017-08-01 23:36 GMT+02:00 Laura Atkins :

>
>
> On Aug 1, 2017, at 2:26 PM, Brett Schenker  wrote:
>
> Anyone have a good suggestion to research domain reputation? IP ratings
> are easy, but domain seems to be much more difficult (there's one or two go
> tos for me).
>
>
> When I’m looking into domain reputation I look for answers to the
> following questions:
>
> * Where is this domain used?
> * What types of mail does it show up in?
> * What does the website look like if I go to the bare URL?
> * What does the whois record look like?
> * What does the SPF record look like?
> * Does this company have an affiliate program?
> * Does this company have an easy to find signup link on their website?
> * Is this domain listed on any of the domain based blocklists?
>
> There are some other questions I ask and specifics that I look at, but I
> can’t share all my secrets publicly.
>
> laura
>
>
>
> On Tue, Aug 1, 2017 at 5:09 PM, Laura Atkins 
> wrote:
>
>>
>> On Aug 1, 2017, at 1:48 PM, Paul Witting 
>> wrote:
>>
>> Anyone from Gmail here? Hopefully I’m not off topic.
>>
>> CEO was complaining about mail not getting to clients (not mail
>> campaigns, just day to day business). He sent a simple Subject: Test w/
>> Body Test (+ signature) to his personal Gmail account and Gmail flagged it
>> as spam based on “content”. I duplicated it sending from my own account to
>> my own account (even included his signature) and it came through to my
>> inbox, no issues. . SPF and DMARC both passed on the original message. How
>> is the message he sends getting flagged as spam while the identical message
>> I send gets right through.
>>
>>
>> Gestalt filtering. https://wordtothewise.com/2017/06/filtering-by-
>> gestalt/
>>
>> In more modern filtering, particularly at Gmail, scoring is dynamic.
>> There are still rules and they still assign scores. But the
>> scores themselves can be modified by other scores in the process. It’s not
>> a simple sum of scores so changing anything can change the overall status
>> of a message.
>>
>> Take two identical messages and two IP addresses one with an arbitrary
>> reputation of 5 and another with an arbitrary reputation of 10. By the
>> score and sum method, the final email reputation scores would be message+5
>> and message+10. With relative scoring, though, the IP reputations might
>> turn out to be 2 and 13.
>>
>> There’s also a big piece of individual filtering there - if you send from
>> your account to your account with any sort of regularity, then that pattern
>> will affect how mail from you, to you is delivered outside of whatever
>> filtering there is. I’ve had to stop using my “main” gmail account for
>> tests and go to a new one because Gmail figured out I regularly send from
>> @wttw to @gmail and has prioritized that mail into the inbox. If I send to
>> a different @gmail account, it goes to bulk.
>>
>> With the symptoms you describe, however, I’d look hard at the domain
>> reputation.
>>
>> 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
>>
>>
>
>
> --
> Brett Schenker
> Man of Many Things, Including
> 5B Consulting - http://www.5bconsulting.com
> Graphic Policy - http://www.graphicpolicy.com
>
> Twitter - http://twitter.com/bhschenker
> LinkedIn - http://www.linkedin.com/in/brettschenker
>
>
> --
> 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
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google Postmaster Tools: spam rates

[Benjamin BILLON via mailop]

Anna's case is still uncanny, I trust her organization respects Gmail's
requirements to use identifiers for campaigns, and not being almost unique
per message sent. If it was the case anyway, she wouldn't get enough volume
per identifier to trigger any feedback.

I found a case in my data:
- number of markers in the FBL (in "feedback loop spam"): 1 (the identifier
of one given campaign)
- spam rate for this campaign (in "feedback loop spam"): 0.3%
- spam rate for that given day (in "user reported spam"): 0.1%

Here it makes sense. The domain was used for other campaigns, but only this
one generated enough complaints to notice me.

Indeed we don't have access to enough info from Anna, but I guess she does,
so let's see if there's an happy ending =)
-- 

Benjamin

2017-07-31 21:16 GMT+02:00 Bressier simon <bressie...@gmail.com>:

> Well, actually it depends on how the identifiers are defined, if they are
> almost unique per messages sent, that's normal, but we don't have enough
> infos here on how the identifiers are assigned/defined.
>
> users spam rate is the spam rate for your whole domain, not depending if
> it reach any max spam rate on Gmail, so you can have a 0.1% rate for example
>
> On feedbackloop page, you have the spam rate per identifier, an identifier
> has to identify a specific customer, a campaign, a mail flow, so you can
> have rates per identifiers, which works fine on our side actually. You can
> have datas for an identifier only if it reach a non negligeable rate,
> basically, if you have datas for an identifier, it means there is an issue
> with the flow identified.
>
>
>
> 2017-07-31 15:50 GMT+02:00 Benjamin BILLON via mailop <mailop@mailop.org>:
>
>> Digging up this topic,
>>
>> @Anna> you might have had some feedback from Google about that since your
>> message?
>>
>> I can still sleep at night, but I'm curious about the outcome!
>> --
>>
>> Benjamin
>>
>> 2017-05-31 18:23 GMT+02:00 Nick Schafer <n...@mailgun.com>:
>>
>>> The feedback loop shouldn't include messages caught by their spam filter
>>> as users aren't able to complain against a message already in the spam
>>> folder. The feedback loop is used to identify campaigns in a sender's
>>> traffic that are getting a high volume of complaints from Gmail users. From
>>> my understanding the user reported spam number would be the overall rate
>>> that day for that DKIM domain while the feedback loop would be for the
>>> identifier specified. But if the only messages they sent that day had the
>>> broadcast identifier, i would expect the rates to be much closer. Maybe an
>>> error or someone complaining then marking not spam, and then doing the same
>>> thing over and over?
>>>
>>> Nick Schafer
>>> Technical Account Manager, Mailgun <http://www.mailgun.com/>
>>> m:(210) 833-3933
>>>
>>> On Wed, May 31, 2017 at 5:53 AM, Paul Smith <p...@pscs.co.uk> wrote:
>>>
>>>> On 31/05/2017 10:29, Anna Ward wrote:
>>>>
>>>> I've talked to a bunch of different industry folks at this point, and
>>>> no one seems to understand the difference between "user reported spam" and
>>>> "feedback loop spam" in Google Postmaster Tools
>>>> <https://support.google.com/mail/answer/6227174?hl=en>.
>>>>
>>>> A notable example for me was May 8th when a client's DKIM domain showed
>>>> a 100% "feedback loop spam rate" but only a 0.1% "user reported spam rate" 
>>>> (
>>>> screenshots <http://howdyanna.com/xnnd/>).
>>>> They sent to about 4000 Gmail addresses that day, and the one
>>>> identifier in the Feedback Loop graph was "broadcast" (represents the
>>>> message type, a bulk-send newsletter). All of their outgoing mail used the
>>>> "broadcast" identifier like this: Feedback-Id:
>>>> ::broadcast:getresponse
>>>>
>>>> I just can't think of a scenario where the Feedback Loop could be at
>>>> 100% but the Spam Rate ("user reported") would be at only 0.1%. How are
>>>> such drastic differences possible?
>>>>
>>>>
>>>> If the feedback loop includes messages caught by their spam filter,
>>>> then if their spam blocked everything, that would show 100% as spam, but
>>>> most users wouldn't see the spam or bother reporting it as spam (because
>>>> it's already been caught) so the user reported spam rate would be
>>>> approaching zero.
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> mailop mailing list
>>>> mailop@mailop.org
>>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>>
>>>>
>>>
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google Postmaster Tools - Authentification accuracy or issue on my side ?

[Benjamin BILLON via mailop]

I see these disparities for domains that are used in MAIL FROM / envelope
header / return-path (for SPF), and that sometimes are used for DKIM
signing (so it's not 0%), but not always (so it's not 100%).

With no more detail about your settings, content and traffic it would be
hard to help, but adding an ruf= in your DMARC record will most probably
give you more insight.

Cheers,
-- 
Benjamin

2017-08-01 13:41 GMT+02:00 Ken O'Driscoll :

> Hi Yves-Marie,
>
> My guess, and it's just a guess, is that the discrepancy might be down to
> the "alignment" of the SPF and DKIM records.
>
> DMARC requires that the domain of the SPF approved email source in the
> envelope header (return-path) matches the domain in the From address. It
> also requires that DKIM selector domain matches that of the From address
> domain.
>
> However, in the absence of DMARC, SPF and DKIM are not bound to the From
> address domain in any way. You can protect an email with SPF and DKIM using
> any domain name(s) and it will still validate.
>
> So, I suspect that Google Postmaster may be reporting correctly validating
> SPF and DKIM authentication but also indicating that not all of that is
> aligned, i.e. not compliant with your DMARC policy.
>
> The easiest thing to do is look at the DMARC failure email reports and see
> what they are saying.
>
> Ken.
>
> --
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 | w: www.wemonitoremail.com
>
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book
>
>
> On Tue, 2017-08-01 at 09:54 +0200, Yves-Marie Le Pors Chauvel wrote:
> > Hi there,
> >
> > Since a few weeks from now, I'm having some results I don't really
> > understand with Google Postmaster Tools.
> >
> > When I take a look at the Authentification page, my SPF and DKIM
> > compliancy are always 100% but my DMARC compliancy is variation from day
> > to day (from 5.9% to 77.3%) without changing anything on my side.
> >
> > If I check on Dmarcian, for Google reports, I have a compliance level of
> > 100%...
> >
> > Does any one have any idea where it should come from ?
> >
> > Regads,
> >
> > --
> > Yves-Marie LE PORS-CHAUVELEmail Product Manager
> > T: +33 2 23 45 57 99 (3043)   3 rue de Paris - Atalis 2 / Batiment D
> > - 35 510 Cesson Sévigné
> > www.ccmbenchmark.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
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sharing Google Postmaster Tools

[Benjamin BILLON via mailop]

Hi Luis,

I guess you did it already, but just in case, after sharing a domain to
another user, this user needs to go through the process of adding the
domain, like for any new domain (like Anthony said, by clicking the ( + )
button). But here it won't ask to add the TXT record!


-- 

Benjamin

2017-08-16 16:31 GMT+02:00 Anthony Chiulli :

> Luis - I'm not from Google by my thoughts below.
>
> 1.) Google Suite and @Gmail addresses are the only allowed email addresses
> to register for GPT and share GPT data. Unsure why Google is rejecting an
> address if it valid that fits this criteria
> 2.) Is GPT data showing up when sharing out after 24/48 hours at all? Is
> it simply the delay in question? I personally have had shared GPT domain
> data appear after a few minutes of requesting to be shared. Make sure you
> or your customer are clicking the (+) icon in the UI and adding in the
> exact domain that is requesting to be shared.
>
>
>
> *ANTHONY CHIULLI*
>
> Marketing Practice, Deliverability Services
>
> Salesforce
>
> Mobile: 303.817.6506 <(303)%20817-6506>
>
>
>
> On Tue, Aug 15, 2017 at 9:47 PM, Luis E. Muñoz 
> wrote:
>
>>
>> Hi there,
>>
>> I hope someone from Google can give me a hand.
>>
>> I've been trying to share a few domains in the Google Postmaster Tools
>> console. These are the issues I've experienced:
>>
>> * Authenticated domains that I've shared with my personal Gmail account
>> don't show up in my own console after ~48 hours
>> * Users with which I've provided access to authenticated domains with and
>> without data, do not show up in their consoles after ~24 hours
>> * Gmail addresses that are known to be correct are not allowed for
>> sharing. Sometimes the UI rejects them as invalid right away, sometimes the
>> rejection happens in the last step
>>
>> Are there any ongoing issues with this service? So far I've been unable
>> to discern any usable pattern. The documentation makes this seem incredibly
>> easy, but it's not working for me.
>>
>> Thanks in advance.
>>
>> -lem
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Alice.it contact

[Benjamin BILLON via mailop]

For abuse handling, the M3AAWG published at least these two guidelines:
-
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Hosting_Abuse_BCPs-2015-03.pdf
-
https://www.m3aawg.org/sites/default/files/document/MAAWG_Abuse_Desk_Common_Practices.pdf

(and potentially this one
https://www.m3aawg.org/sites/default/files/document/MAAWG_Anti-Abuse_Product_Evaluation_BCP.pdf
)

However, postmaster@ is not about abuse. It has to exist, but if nothing
else is done then it's missing the point. While abuse _must_ be handled,
taking time and resources to handle the problems of senders who don't
manage to deliver emails is a far lower priority.

To stick back to the initial topic, we can expect ab...@alice.it to process
any abuse matter (spam, botnets, etc.), but not to take care of
deliverability issues.
We can then only hope that there's someone reading postmas...@alice.it.


-- 

Benjamin

2017-08-18 20:46 GMT+02:00 Aaron C. de Bruyn via mailop :

> > Are you serious? or simply joking?
>
> Serious.  No one is beholden to RFCs.  They are guidelines for
> interoperability.  I don't care if one postmaster@ address is staffed
> by a human response 24/7, or if another is staffed 8x5 and at other
> times auto-responds with "we'll investigate and get back to you during
> business hours".
>
> It's annoying if abuse@ goes to /dev/null, but no one controls my mail
> servers except me.  You control yours.  You can absolutely decide to
> reject my mail if I /dev/null abuse.  I've blacklisted a few domains
> due to lack of abuse and postmaster addresses--but usually they have a
> lot more problems than just failing to accept abuse mail.
>
> I use rfc-clueless to help score inbound messages on a few of my mail
> servers.
>
> > I keep repeating facts:
>
> Ok--so e-mail the rfc-clueless people and explain your point and how
> you think their listing service is behaving badly.  See what they say.
> It certainly sounds like an unintended block.
>
> > I didn't ask your permission to start my own list ;-) I simply stated
> > that I hope someone will start a dnsbl for people dev/nulling
> > postmaster and YOU said that rfc-clueless is a solution while it is
> > NOT an asnwer to my dream.
>
> I get that.  I'm not trying to pick a fight or anything, just
> suggesting that if you have a better way of doing it, do it.
> Hell--you might end up with a bunch of mail admins who feel the same
> way and start using your service.
>
> I'm in the path of the eclipse, so I'm going to retreat to my
> underground bunker now as everyone's starting to go crazy around here.
> ;)
>
> -A
>
>
>
>
> On Fri, Aug 18, 2017 at 10:56 AM, Stefano Bagnara  wrote:
> > On 18 August 2017 at 19:25, Aaron C. de Bruyn 
> wrote:
> >> As a postmaster or abuse contact, I'm not clicking on random links
> >> sent to me by robots to verify anything. ;)
> >>
> >> There's a difference between *rejecting* mail sent to an address and
> >> *accepting* it and routing it to /dev/null.
> >>
> >>> "Pretending that this is for the "RFC" good sounds like a joke"
> >>
> >> If I recall correctly, the RFC says you have to *accept* mail for
> >> those addresses--it doesn't specify what you are required to do with
> >> them, or how long it should take.
> >
> > Are you serious? or simply joking?
> >
> >> Should they block any address that doesn't respond in 15 minutes?
> >> Maybe an hour?  How about a week?  How often to you re-verify?  Is it
> >> a big company like Microsoft that might staff their abuse team 24/7,
> >> or is it a small outfit where they have an abuse contact but maybe you
> >> caught him or her during their week or two of vacation every year?
> >
> > They already have timings for most of they checks.
> > IMO they could even wait 1 month and then list you. If you succesfully
> > unlist then you get some more time the next time (like any blacklist
> > deal with removal).
> >
> > I keep repeating facts:
> > - postmaster@app.mydomain works and have a human dealing with it but
> > rfc-clueless list it because "mydomain" (not app.mydomain) have MX
> > records on google and those MX does not accept "postmaster" email
> > (with no domain specification). But my email is
> > postmaster@app.mydomain not postmaster@mydomain and the RFC clearly
> > doesn't mix MX for an host with MX for the domain of that host (and
> > BTW postmaster@mydomain works too).
> > - postmas...@alice.it instead is not listead while it /dev/null any
> email.
> >
> > This means that rfc-clueless does not answer to my "wish" unlike you
> > replied. I don't care to define if rfc-clueless is right or not doing
> > that, it simply doesn't do what I wished. I didn't mention
> > rfc-clueless until you said it was the answer to my wish.
> >
> > While I explained WHY it didn't answer to my wish I also explained WHY
> > I think it is not even giving "useful" informations (are you really
> > more happy when a domain HAVE postmaster@