[mailop] Google feedbackloop

[David Hofstee]

Hi (Brandon),

We've setup the Google Feedback-ID header in our mails for quite a while
now, we double DKIM-sign with our domain and we review the postmaster
pages. However, when I look at the feedbackloop page, it never reports
anything.

Now I don't expect there something everyday. It always was pretty quiet at
my previous ESP. But it seems too quiet in that area. Normally our
"user-reported spam" rate is about 0.0% or 0.1%. However, even on days that
we saw a "user-reported spam" rate of 0.7%, we still did not see anything
on the feedback loop identifier count.

Earlier, you had to register the SenderId in the Feedback-ID header with
Google. These days this is no longer necessary, or so it seems:
https://support.google.com/mail/answer/6254652?hl=en_topic=7279058 . It
is at least not mentioned there.

I've asked for help via the "send feedback" functionality. As I think it
would be good to have an idea if the Sender-ID identifier is seen at all.
But I have not heard back.

So I have two questions:
- Do you still need to register the SenderId (and if so, where)? Have
people seen it work without such a registration?
- Are there reasons that the feedbackloop does not work/provide
information (even if you follow the pointers on the pages from Google so
that only aggregate/anonymous info is provided back)?

Now this functionality is not essential for me finding problems, but I need
all the information that I can get (and Google usually has solid
information). Any pointers are appreciated.

Yours,


David

P.S. the Sender-Id = othve
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SmartScreen weirdness

[David Hofstee]

I've seen this with Yahoo btw... One of the 15 shared pool IPs was just
permanently blacklisted / not accepting mail.

Yours,


David

On Fri, 31 Aug 2018 at 00:23, Michael Wise via mailop 
wrote:

>
> /me coughs discretely ...
>
> As I don't have the right crescent wrench to what this issue, I have
> forwarded your concerns to the people who ARE in a position to get a better
> understanding of these issues.
> There's a lot of conflicting signals that SmartScreen takes into
> consideration, and a lot of ... obscure-on-purpose policies that affect how
> the folks who are typically the ones to mitigate these issues are allowed
> to do ... and yes, a lot of boilerplate, sometimes that doesn't seem ... on
> point.
>
> /sigh
>
> I will do what I can.
>
> 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 John Stephenson
> Sent: Thursday, August 30, 2018 10:57 AM
> To: bbil...@splio.com
> Cc: mailop ; Stefano Bagnara 
> Subject: Re: [mailop] SmartScreen weirdness
>
> >For my part, rather than complaining, I'd like to know what we could do
> to help Microsoft, in case this is considered not to be normal.
>   I should have included that and emphasized the fact that individuals at
> Microsoft have been very helpful to respond and pass things along, but I
> feel strongly that some major, network level changes have taken place which
> are having unintended consequences and which aren't readily apparent or
> fixable by abuse/product folks.  I have heard this sentiment from other ESP
> pros who definitely know the difference between a good client and a bad one.
> On Thu, Aug 30, 2018 at 9:34 AM Benjamin BILLON  wrote:
> >
> > WELL.
> > *streches his fingers*
> >
> > We have one IP, 91.190.168.55, red in SNDS for YEARS.
> > I have record of traffic (mostly green, with some yellow) back to Nov.
> 2009.
> > Then some time with no traffic, then red, then green, the IP lived.
> > In 2014, it became ReturnPath certified. All green. Then in 2016, the
> certification was canceled by the sender. Since then, only red, with
> obvious junk folder placement (4% open rate for Microsoft vs. 20% for other
> ISPs).
> > I spotted one day of yellow in 2017, probably a glitch =) It was still
> > dedicated to the same client (who previously had the Certification)
> until March 2018, where it started to send a low volume of shared traffic,
> with the incredulous hope of changing the color. No luck.
> >
> > Of course there were tickets about that, with no result.
> >
> > I know that during certification Microsoft doesn't maintain the
> reputation of the IP, so it is considered cold again after it's over. But
> it should regain some reputation at some point, that happens regularly.
> Just not this IP. I still sacrifice some traffic every day to monitor this.
> My life is amazing.
> >
> > We also have the case of IPs showed as green by SNDS, but with obvious
> junk folder placement (and that since the migration to the Outlook
> Protection platform, I have a very nice theory to discuss around frosty
> beverages).
> > And tickets aren't helping much.
> > We also have cases of clients with Microsoft recipients opening at
> roughly 1/3rd compared to other ISPs. SNDS color may vary, but MS Support
> finds nothing to do (or doesn't reply, then when we push back the ticket
> has been closed).
> >
> > Anyway you're not alone in this.
> > From the various groups of ESPs I'm in, the recurring nightmare of all
> is Microsoft.
> >
> > For my part, rather than complaining, I'd like to know what we could do
> to help Microsoft, in case this is considered not to be normal.
> >
> > Cheers!
> > --
> >
> > Benjamin
> >
> > -Original Message-
> > From: mailop  On Behalf Of Stefano Bagnara
> > Sent: Thursday, 30 August, 2018 17:40
> > To: mailop 
> > Subject: [mailop] SmartScreen weirdness
> >
> > Hi all, or I should probably say Hi Michael, :-)
> >
> > I manage a pool of 5 IPs shared by the same group of senders (>100 small
> senders).
> > IPs are 188.165.188.85..188.165.188.89. (please no OVH-flames)
> >
> > They are low volume and they sends the same things (emails are
> roundrobin-ed between the IPs). They share the same reputation of public
> reputation providers (99 on senderscore, good on Talos). They haven't been
> blacklisted recently (AFAIK).
> >
> > One of those IPs is RED on SNDS (188.165.188.85) and in fact, emails
> sent by that IP to new email addresses ends up in the Junk folder. The
> other 4 IPs are GREEN and have always been GREEN and an email sent to a new
> recipient is sent to inbox. I say "new recipients" because if I send an
> email to an "old recipient" that is already reading that email flow the
> email is inboxed by both. It's hard to "debug" this from the outside
> because I need reports from "new users" or I'd have to create new hotmail
> accounts.
> >
> > In 

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

[David Hofstee]

Hi Anne:
>> Companies should not ask for an email address unless they take good care
of it and convince the recipient of that. That is how they should protect
themselves.
>(cough)GDPR(cough)
Yes... It would be nice if everyone sticks to the law.

Hi Laura:
> There is an entire segment of the legitimate email industry that provides
list cleaning services for a fee to anyone with cash
I know. They make my work more difficult.

> A naive scanning like you suggest wasn’t sufficient for the spammers of
16 years ago. It’s certainly not going to catch anything actual spammer
today
I'm just giving a simple example, obviously. Complex examples are harder to
explain. But I still have customers with such addresses. Most of my
customers that misbehave in some way are not actively seeking to break the
law. They are just very unknowledgeable. Very.

> You use the data you’ve got to try and find bad behavior. Bounces are a
data point and *sometimes* can lead you down the path of a problem sender
Well, similar conclusions can be made by open, click and unsubscribe
analysis.


Hi Michael:
>
https://www.spamhaus.org/news/article/734/subscription-bombing-coi-captcha-and-the-next-generation-of-mail-bombs
Yes. We've had some discussions in this group, behind the scene, to provide
pointers on how to detect/mitigate that. I would call that "form spam". One
of the problems with that specific type of abuse is that doube opt-in would
not have solved the issue (as the inbox would have still been flooded with
opt-in messages). Which basically proves my point that double opt-in is not
the tool to fix that issue.

The nadine story is interesting.

>> … for signs of lack of opt-in …
> IMHO, you have that the wrong way around.
You are right there. My data setup has not yet allowed me to work it like
that.

> But many of the most promising ways to my mind are actively frowned upon.
> Like noticing bounces from OTHER lists are in the new set.
I would call that "address intelligence" which combined with "domain
intelligence" gets you pretty far. As long as I just use it to vet my
customer list, it should be ok. It is one thing that list cleaning services
cannot fix.

Yours,


David

On Thu, 30 Aug 2018 at 01:55, Michael Wise 
wrote:

>
>
> Sounds like the beginning of ePending.
>
> And I have a crawly feeling about this, because it reminds me of an
> experience we had with someone who wanted a dedicated /24 for their own
> use, but all the rDNS was in like groups of 12 domains at a time, but all
> sending the same traffic.
>
> AOL sent us LOTS of complaints, but finally we had a SpamCop complaint
> that we could start a conversation with, and …
>
>
>
> “ I need to know the history of this email address, how did it sign up…
>
>- I asked my boss and he said yup, that street address in Las Vegas
>exists …
>
> “ But it doesn’t belong to the owner of this email address, who says that
> they have never lived in Las Vegas. Ever.
>
>- …
>
>
>
> /me calls the NOC, “Brad, pull the ethernet for X.
>
>- Done.
>
>
>
> 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  *On Behalf Of *Laura Atkins
> *Sent:* Wednesday, August 29, 2018 10:00 AM
> *To:* David Hofstee 
> *Cc:* mailop 
> *Subject:* Re: [mailop] Gmail - Anybody out there from Gmail, willing to
> assist with strange reputation issue
>
>
>
>
>
> On Aug 29, 2018, at 2:35 AM, David Hofstee 
> wrote:
>
>
>
> > Without confirmed opt-in, you're at the mercy of what random junk people
> happen to stick in there
>
> True, but then the real problem is that the opt-in is invalid. As an ESP
> you should evaluate these lists beforehand *and* monitor for signs of a
> lack of opt-in (e.g. high complaint rates by FBL or unsubscribes). Having
> these typo's are often good indicators for me to start looking further
> beforehand. E.g. a...@hotmail.com is the perfect example of people not
> wanting to provide their real email address.
>
>
>
> There is an entire segment of the legitimate email industry that provides
> list cleaning services for a fee to anyone with cash. A significant portion
> of the time a non-opt-in list will pass all of the tests (and dozens more)
> that you mention above.There’s also vast amounts of work and products in
> the spammer end of the email industry that folks like me never see, but are
> also designed to prevent ESPs from identifying spammers.
>
>
>
> Back in 2002, I was investigating a list of addresses. The questi

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

[David Hofstee]

> For companies that have a high risk of folks giving a fake address, like
quote sites or download sites or even whitepaper sites, the site owners
need to take steps to protect themselves.
No. Recipients are not stupid. They only give fake addresses if they see
that the company is asking their email address for the wrong reasons.
Unless that is fixed, you will keep trouble.

Companies should not ask for an email address unless they take good care of
it and convince the recipient of that. That is how they should protect
themselves.

Yours,


David

On Tue, 28 Aug 2018 at 23:14, Laura Atkins  wrote:

> The difference here is that people may want the quote but not want the
> associated email that comes from the company. So they will fill in a “fake”
> email address, and one that happens to deliver to some random person.
>
> Not all subscription forms are alike, and not all subscription forms have
> the same risk of wrong addresses. For companies that have a high risk of
> folks giving a fake address, like quote sites or download sites or even
> whitepaper sites, the site owners need to take steps to protect themselves.
>
> laura
>
>
> On Aug 28, 2018, at 6:27 AM, David Hofstee 
> wrote:
>
> Hi Otto,
>
> It is not my experience that many people will fill in other people's email
> address. I've seen 100's of millions of subscribers. Most did not have
> double opt-in. It mostly went very well. There are cases of form-spam (see
> e.g. Spamhaus a few years ago) and double opt-in prevents typo's. But there
> are other methods to deal with abuse (in all of its appearances).
>
> So I'm not sure that your opinion towards double opt-in (where customers
> not using it should be seen as spamming) is in line with the numbers I saw.
> I understand the push from the anti-spam community (who have issues in
> discriminating criminals and commercial senders having equally bad/good
> data quality). But this technical solution is, imho, the wrong tool for
> that. As Microsoft, Yahoo and Google have found out, feedback from users
> via alternate systems is much better. But that is not yet integrated into
> RFCs for the rest of us to use.
>
> I'll leave the "confirmed opt-in" vs "double opt-in" discussion as it is.
>
> Yours,
>
>
> David
>
>
> On Tue, 28 Aug 2018 at 09:02, Otto J. Makela  wrote:
>
>> On 2018-08-23 22:10, Jan Schapmans wrote:
>>
>> >   * customer doesn’t want to do double optin, we are pushing to only
>> implement
>> > it for gmail & googlemail addresses.
>>
>> This should definitely raise red flags at your end: customer doesn't
>> care about how good the "leads" are, as long as there are many.
>> This is "Millions CD" level thinking.
>>
>> BTW, a much better term is "confirmed opt-in", because that's what it is.
>> Most companies that want to contact you by email can get it right (send
>> single
>> email with confirmation link as part of registration etc.), why should
>> your
>> customer get a special pass not to do it?
>>
>> --
>>/* * * Otto J. Makela  * * * * * * * * * */
>>   /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>>  /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
>> /* * * Computers Rule 0100 01001011 * * * * * * */
>>
>> ___
>> mailop mailing list
>> 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
>
>
> --
> 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
>
>
>
>
>
>
>
>

-- 
--
My opinion is mine.
___
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

[David Hofstee]

> Without confirmed opt-in, you're at the mercy of what random junk people
happen to stick in there
True, but then the real problem is that the opt-in is invalid. As an ESP
you should evaluate these lists beforehand *and* monitor for signs of a
lack of opt-in (e.g. high complaint rates by FBL or unsubscribes). Having
these typo's are often good indicators for me to start looking further
beforehand. E.g. a...@hotmail.com is the perfect example of people not
wanting to provide their real email address.

A double-optin only confirms there was a relationship with some sender at
some point in time. It avoids typo's. However, it does not state with who
the opt-in was, when it was provided, for what content, for what frequency,
under what circumstances and for how long that is valid. It is not
watertight at all.

Yours,


David

On Wed, 29 Aug 2018 at 00:24, Brandon Long  wrote:

> I would also point out that seeing differences between mailbox providers
> in this instance is not really a surprise.  It may have more to do with
> which random address people use in these situations.  They may be choosing
> Gmail more than Yahoo for whatever reason, or the address they're choosing
> at Gmail may exist and be used, and hence getting spam markings.
>
> Without confirmed opt-in, you're at the mercy of what random junk people
> happen to stick in there, and there's no guarantee that that junk is
> equally distributed.
>
> And as Laura points out, it also depends on what they are getting from the
> form.  Some forms may get low to zero junk, others are probably mostly
> untrusted.
>
> Brandon
>
> On Tue, Aug 28, 2018 at 2:28 PM Laura Atkins 
> wrote:
>
>> The difference here is that people may want the quote but not want the
>> associated email that comes from the company. So they will fill in a “fake”
>> email address, and one that happens to deliver to some random person.
>>
>> Not all subscription forms are alike, and not all subscription forms have
>> the same risk of wrong addresses. For companies that have a high risk of
>> folks giving a fake address, like quote sites or download sites or even
>> whitepaper sites, the site owners need to take steps to protect themselves.
>>
>> laura
>>
>>
>> On Aug 28, 2018, at 6:27 AM, David Hofstee 
>> wrote:
>>
>> Hi Otto,
>>
>> It is not my experience that many people will fill in other people's
>> email address. I've seen 100's of millions of subscribers. Most did not
>> have double opt-in. It mostly went very well. There are cases of form-spam
>> (see e.g. Spamhaus a few years ago) and double opt-in prevents typo's. But
>> there are other methods to deal with abuse (in all of its appearances).
>>
>> So I'm not sure that your opinion towards double opt-in (where customers
>> not using it should be seen as spamming) is in line with the numbers I saw.
>> I understand the push from the anti-spam community (who have issues in
>> discriminating criminals and commercial senders having equally bad/good
>> data quality). But this technical solution is, imho, the wrong tool for
>> that. As Microsoft, Yahoo and Google have found out, feedback from users
>> via alternate systems is much better. But that is not yet integrated into
>> RFCs for the rest of us to use.
>>
>> I'll leave the "confirmed opt-in" vs "double opt-in" discussion as it is.
>>
>> Yours,
>>
>>
>> David
>>
>>
>> On Tue, 28 Aug 2018 at 09:02, Otto J. Makela  wrote:
>>
>>> On 2018-08-23 22:10, Jan Schapmans wrote:
>>>
>>> >   * customer doesn’t want to do double optin, we are pushing to only
>>> implement
>>> > it for gmail & googlemail addresses.
>>>
>>> This should definitely raise red flags at your end: customer doesn't
>>> care about how good the "leads" are, as long as there are many.
>>> This is "Millions CD" level thinking.
>>>
>>> BTW, a much better term is "confirmed opt-in", because that's what it is.
>>> Most companies that want to contact you by email can get it right (send
>>> single
>>> email with confirmation link as part of registration etc.), why should
>>> your
>>> customer get a special pass not to do it?
>>>
>>> --
>>>/* * * Otto J. Makela  * * * * * * * * * */
>>>   /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>>>  /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
>>> /* * * Computers Rule 0100 01001011 * * * * * * */
>>>
>>> ___
>>> mailop ma

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

[David Hofstee]

Hi Otto,

It is not my experience that many people will fill in other people's email
address. I've seen 100's of millions of subscribers. Most did not have
double opt-in. It mostly went very well. There are cases of form-spam (see
e.g. Spamhaus a few years ago) and double opt-in prevents typo's. But there
are other methods to deal with abuse (in all of its appearances).

So I'm not sure that your opinion towards double opt-in (where customers
not using it should be seen as spamming) is in line with the numbers I saw.
I understand the push from the anti-spam community (who have issues in
discriminating criminals and commercial senders having equally bad/good
data quality). But this technical solution is, imho, the wrong tool for
that. As Microsoft, Yahoo and Google have found out, feedback from users
via alternate systems is much better. But that is not yet integrated into
RFCs for the rest of us to use.

I'll leave the "confirmed opt-in" vs "double opt-in" discussion as it is.

Yours,


David


On Tue, 28 Aug 2018 at 09:02, Otto J. Makela  wrote:

> On 2018-08-23 22:10, Jan Schapmans wrote:
>
> >   * customer doesn’t want to do double optin, we are pushing to only
> implement
> > it for gmail & googlemail addresses.
>
> This should definitely raise red flags at your end: customer doesn't
> care about how good the "leads" are, as long as there are many.
> This is "Millions CD" level thinking.
>
> BTW, a much better term is "confirmed opt-in", because that's what it is.
> Most companies that want to contact you by email can get it right (send
> single
> email with confirmation link as part of registration etc.), why should your
> customer get a special pass not to do it?
>
> --
>/* * * Otto J. Makela  * * * * * * * * * */
>   /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>  /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
> /* * * Computers Rule 0100 01001011 * * * * * * */
>
> ___
> mailop mailing list
> 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] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

[David Hofstee]

should have addressed it to Jan...

David H

On Fri, 24 Aug 2018 at 10:07, David Hofstee 
wrote:

> Hi David C,
>
> I've had my dealings with these quote sites... It may apply to you. The
> actions you take seem to target email address validity, but Google cites
> complaints as the issue. None of your answers seem to target the problem of
> "do recipients want the email" effectively imho.
>
> My question would be: Why would the customer ask for an email address if
> the recipient only wants the quote?
> Answer: Because the customer doesn't want to "lose" the recipient.
>
> Question: Does the recipient want anything more than the quote?
> Answer: Likely (s)he does not.
>
> You can:
> - Test this by measuring how many temporary email addresses are in the
> list (e.g. @mailinator.com). If that percentage is relatively high,
> recipients do not trust and/or want to have a relationship with the sender.
> Otherwise they would provide their real email address.
> - Measure this by adding a "complaint" option in the unsubscribe form (so
> you can measure how many recipients didn't want the mails). Be sure to add
> a "free field" so people can explain why. Getting complaints and "the
> story" behind such issues is what deliverability is about... The
> unsubscribe form is by far the most useful tool to understand what
> recipients are thinking.
>
> Bottom line is that unless the recipient wants and expects every email,
> providing him/her with real value, the spam button will be hit... In this
> business case, getting data from the recipient to entice him/her into
> further contact is maybe seen as "aggressive" and people get to vote with
> the spam button.
>
> Yours,
>
>
> David H.
>
> On Thu, 23 Aug 2018 at 21:26, Jan Schapmans 
> wrote:
>
>> Hi David,
>>
>>
>>
>> thank  you very much for your answer.
>>
>>
>>
>> I think you are fully right stating that only changing the sending domain
>> and/or IP addresses won’t help.
>>
>> That’s just why we continue trying other things at the same time
>>
>>- only targeting recent engaged (open/click) users from the last 10
>>days
>>- making sure all clicks on unsubscribe link are processed as an
>>unsubscribe (without the users completely processing the unsubscribe flow)
>>- deduplicate all send outs (we’ve noticed some users are more than
>>once in the system because they’ve filed multiple requests)
>>
>>
>>
>> Only thing missing in their best practices, if we are not missing
>> anything, is that they don’t do double optin. To get them to implement
>> double optin, we are pushing to do this only for Gmail.
>>
>>
>>
>> We are:
>>
>>- using DMARC with reject policy
>>- all emails singed with DKIM
>>- Google postmaster ip reputation BAD, domain reputation BAD &
>>complaint rate ok and of course very low at the end because of no inbox
>>placement.  In the feedback loop there is no mentioning of any identifier
>>you can see below we were in a happy place first, and slowly it got
>>worse & worse
>>- list is acquired by a webform where users request a valuation of
>>their car
>>- customer doesn’t want to do double optin, we are pushing to only
>>implement it for gmail & googlemail addresses.
>>(do you think gmail is also monitoring other domains? google apps?)
>>- spam message says (sorry for the Dutch)
>>
>>
>>
>>
>>
>> kr,
>>
>>
>>
>> Jan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* David Carriger 
>> *Sent:* 22 August 2018 22:13
>> *To:* Jan Schapmans ; mailop@mailop.org
>> *Subject:* Re: Gmail - Anybody out there from Gmail, willing to assist
>> with strange reputation issue
>>
>>
>>
>> Changing the sending domain and the IP addresses won't help at all if you
>> haven't solved the underlying issue, you're just kicking the deliverability
>> can down the road. Is the domain using DMARC to prevent spoofing, and
>> what's the policy? Are all emails signed with DKIM? What does Google
>> Postmaster Tools show for IP reputation, domain reputation, and complaint
>> rates? How is the customer acquiring their list? Are they using double
>> opt-in? When an email goes to the spam folder, does Gmail show a banner
>> saying why it was sent to spam? If so, what's the banner say?
>>
>> Gmail is very good at spam filtering, so your best bet is 

Re: [mailop] Google is sending notifications with big local-parts

[David Hofstee]

Hi José,

More do it, but not that many. Some will just clip the local part.


David

On 10 July 2018 at 14:16, Jose Borges Ferreira  wrote:

> I'm getting some notifications from @docos.bounces.google.com that have a
> local-part with the following pattern 1234567890123+
> 1234567890123456789012345678-012345678901234567890123456789
> 01.123456@docos.bounces.google.com.
>
> The 86 octets length is causing a rejection on my part because it breaks
> the RFC limit**.
>
> I'm I being too picky by enforcing the 64 octets limit or someone else is
> also rejecting messages like this?
>
> José Borges Ferreira
>
>
> ** This limit is referenced since rfc821
> https://tools.ietf.org/html/rfc5321#section-4.5.3.1.1
> https://tools.ietf.org/html/rfc2821#section-4.5.3.1
> https://tools.ietf.org/html/rfc821#section-4.5.3
>
> ___
> mailop mailing list
> 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] Orange.fr and Wanadoo.fr Hardbounces

[David Hofstee]

Hi Emre,

My 5xx bounce rate is around 0.2% for these domains. The domains have not
gone inactive. Some spam filters reply with such 5xx errors to fend off
spam. I haven't seen that @orange yet (but a large Belgium provider does it
infrequently).

@Philip (and Mathieu): The point that Emre is making is:
- You send to e.g. a 1000 recipients one week. These recipients download
images and click on links (e.g. 40% open rate and 5% click rate).
Conclusion: Recipients are real and active.
- The next week *all* these recipients suddenly bounce and are deactivated
on his lists due to a "550 5.1.1 Adresse d au moins un destinataire
invalide. Invalid recipient. OFR_416 [416]"... Across all customers.

That is not how normal recipients, people, stop using their email accounts.
Not at such rates. Some other process is going on. One would like to find
out what happened. He is asking himself if the domain has gone out of
business (which is not the case).

Yours,


David

On 5 July 2018 at 13:51, Suresh Ramasubramanian  wrote:

> For a 1990s throwback, here is the website for xmailserver
>
> http://www.xmailserver.org/
>
> On 05/07/18, 4:56 PM, "mailop on behalf of Benoit Panizzon" <
> mailop-boun...@mailop.org on behalf of benoit.paniz...@imp.ch> wrote:
>
> Hi Erme
>
> I've seen similar problems with ISP using, as I recall, something
> sounding like 'xmailserver' as SMTP Server.
>
> That Server has a very serious bug, instead of rejecting invalid
> recipients during the 'rcpt to' handshake, it does this after 'data'
> has been initiated by issuing a human readable message telling what
> recipient was invalid.
>
> This of course breaks all mailing lists or newsletter tools which send
> emails to as many recipients as possible to lower resource consumption.
>
> If one destination address becomes invalid, this leads to mass
> unsubscription of valid email addresses on tools like mailman.
>
> So Maybe France Telecom switched to such a mailserver?
>
> 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
>



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

Re: [mailop] Senderscore.org / ReturnPath decline of reported volume

[David Hofstee]

Maybe Telstra is changing infrastructure and data streams were not
adjusted... https://senderscore.org/lookup.php?lookup=203.38.21.
21=true

Yours,


David

On 29 June 2018 at 12:20, Nick Stallman  wrote:

> Hi
>
> Actually yeah I can confirm that, also Australian focussed (Australian
> server, to mostly Australians) but we aren't a customer of theirs.
>
> Certainly no change in volume from the relevant server. Using their free
> tool we were a Very High Volume Sender but now it's only saying High Volume
> Sender.
>
> Maybe they were getting data from a large Australian ISP and they are no
> longer getting that data source?
>
>
>
> On 29/06/18 19:27, David Hofstee wrote:
>
> Hi,
>
> We've been seeing an extreme decline in volume reported by
> Senderscore.org/ReturnPath. From e.g. 700k/day to 5k/day on several
> dedicated IPs. The actual volume of the customer on those IPs is still the
> same. This started about 15 days ago. Example IP = 149.235.15.116.
>
> This is to traffic in the Australia area. I have not been able to see the
> same on other IPs. My shared pool (which sends mostly to Europe/USA) is not
> affected. I checked a few IPs from competitors and they were not affected
> either.
>
> I wonder what other see (on their own IPs) and conclude.
>
> Yours,
>
>
> David
>
> P.S. Yes, I know this is from a commercial vendor, we have a contract with
> them and yes I have created a ticket there.
>
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Nick Stallman
> Technical Director
> [image: Email] n...@agentpoint.com
> [image: Phone] 02 8039 6820 <0280396820>
> [image: Website] www.agentpoint.com.au
> [image: Agentpoint] <https://www.agentpoint.com.au/>
> [image: Netpoint] <https://netpoint.group/>
> Level 3, 100 Harris Street, Pyrmont NSW 2009 [image: Facebook]
> <https://www.facebook.com/agentpoint/> [image: Twitter]
> <https://twitter.com/agentpoint> [image: Instagram]
> <https://www.instagram.com/Agentpoint/> [image: Linkedin]
> <https://www.linkedin.com/company/agentpoint-pty-ltd>
>



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

[mailop] Senderscore.org / ReturnPath decline of reported volume

[David Hofstee]

Hi,

We've been seeing an extreme decline in volume reported by
Senderscore.org/ReturnPath. From e.g. 700k/day to 5k/day on several
dedicated IPs. The actual volume of the customer on those IPs is still the
same. This started about 15 days ago. Example IP = 149.235.15.116.

This is to traffic in the Australia area. I have not been able to see the
same on other IPs. My shared pool (which sends mostly to Europe/USA) is not
affected. I checked a few IPs from competitors and they were not affected
either.

I wonder what other see (on their own IPs) and conclude.

Yours,


David

P.S. Yes, I know this is from a commercial vendor, we have a contract with
them and yes I have created a ticket there.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Arbor DNSSEC firewall issues

[David Hofstee]

An interesting read:
https://twitter.com/VDukhovni/status/1008951903147917313

I can't validate, but I would be interested to hear if/how this impacted
delivery of emails.

Yours,


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

Re: [mailop] SNDS Volume Issue

[David Hofstee]

Yes, we see it too. I only see 2/3 or 1/2 of volume reported. Since the
6th. It seems to be restored today. I don't see higher complaint rates (yay)

Yours,


David

On 14 June 2018 at 03:17, Benjamin BILLON  wrote:

> 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
>
>


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

Re: [mailop] Misleading clicks - thoughts

[David Hofstee]

Hi Andrei,

I don't have that data set any more, but I previously looked at domains
with near 0% open and click rates. They exist. E.g. a domain that was
emailed for 15 years, dozens of individual recipients, different customers,
... It went "dead" 10 years ago: Emails were delivered but no one clicked
for years. Then one click. One. Seemed like a manual review of an email
collection setup. But those are the one-offs.

There are (domains which use) spamfilters which open and/or click for
verification. They would be easy to find since opens/clicks are not done
by humans. I've thought about filtering out such opens/clicks but I never
saw the business case for it (since it is not very common).

Yours,


David

On 12 June 2018 at 10:21, Andy Onofrei via mailop  wrote:

> Hi guys,
>
>
>
> I wanted your input .. some while ago I have seen  some issues with clicks
> coming from spam filters like barracuda. I spoke with Barracuda and they
> confirmed that this is not happening at this moment.
>
>
>
> I wanted to ask you if someone is experiencing misleading clicks ( caused
> by spam filters or something similar and not by bot farms ).
>
>
>
> *Andrei Onofrei*
>
> Dynamics 365 Email Deliverability Engineer
>
>
>
> ___
> mailop mailing list
> 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] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[David Hofstee]

> (1) First, I "eat my own dogfood",  ...
Yes, that was clear.

> (2) A large percentage of invaluement subscribers use SpamAssassin
So this should work somewhat. If you have the capacity to let everything be
processed by the SA content filter. Earlier you stated that larger setups
depended on having blacklists at the gate to keep processing manageable but
which results in less weighed filtering. [see #5]

But these setups (often) still lack feedback mechanisms that the Yahoo's,
Hotmail's and Gmail's of this world have... Feedback from users. It also
lacks methods that need large quantities of "historical data". Both
add information back into the content filter to improve it.

> (3) I'm certain that some portion of invaluement subscribers have BETTER
filtering ...- they all have excellent filtering in the areas of their spam
filtering that invaluement attempts to improve! :)
Hey Rob, I think that you have a very good blacklist. My point is that I
think "an excellent blacklist is not good enough". Because you need a
better (and faster) integration between the content filter (using e.g.
reputation data from you), the traffic limiting mechanisms, the feedback
mechanisms (e.g. users marking as spam, or the other way around) and "email
history of your domain".

> (4) You seem to be very confused about what I mean when I talk about how
there has to be some justified level of "collateral damage" these days, due
to the very high frequency of hijacked accounts
I have seen it all... Up to the level of terrorism. I agree with you on
that.

> (5) Also, a large percentage of Invaluement subscribers choose to block
at the perimeter
See #2.

> (6) nobody in this thread ever claimed that blacklists-alone are
sufficient for having good spam filtering
Rob, you as a small set of people, are capable to and have enough access to
improve on the current situation. I also think that the Google's,
Microsofts and Yahoo's are a systemic issue in the email world. This would
include Proofpoint and SpamExperts as well. It is becoming harder and
harder to have your own server and not be troubled by spam unless you use
this small set of services. "They" are unwilling to share their
methods with the rest of us (which I can understand but which results into
"the rest" not having that knowledge).

I think that we, "the rest", should develop better ways to filter spam.
That was my goal of this discussion. To make you conscious of the fact that
we need more than IP/domain blacklists. To be able to level up with the
proprietary solutions. Instead of being stuck with the idea that we should
stick to what we have (because we have it).

Anyway, take it as it is. I hope you have a great weekend.

Yours,


David




On 8 June 2018 at 16:27, Rob McEwen  wrote:

> On 6/8/2018 5:49 AM, David Hofstee wrote:
>
>> > ... score of the sending-IP, which is similar to what you've described,
>> correct?
>> Correct.
>>
>> So you have these mechanisms in place. But your customers, who get access
>> to the invaluement RBL, do not.  Am I correct? If I am, it still results in
>> the conclusion that blacklists are not sufficient to have a resulting good
>> spam filter. You would be ok, the list would not have false positives,
>> but your customers would not be sufficiently covered once bad guys get
>> smarter.
>>
>
>
> David,
>
> You've made so many false assumptions to come to these conclusions... and
> taken things I've said out of context to get there... I had a hard time
> knowing where to begin!
>
> (1) First, I "eat my own dogfood", even for my own mailbox! In our own
> spam filtering system, we score ALL invaluement blacklists "above
> threshold". However, in VERY RARE situations, a message will get delivered
> in our mail system where (a) it had one hit on one invaluement list, (b)
> NOTHING else spammy triggered, (c) and some rules kicked in that lowered
> the spam score just barely below threshold -BUT GUESS WHAT?- the vast
> majority of the time that happens, it ends up being a FALSE NEGATIVE - then
> I'm jealous of my own customers whose systems didn't deliver those spams to
> their users' inboxes!
>
> (2) A large percentage of invaluement subscribers use SpamAssassin, and
> likewise use a multi-tiered scoring system where they score blacklists
> higher if that blacklist (a) had fewer FPs, -AND- (b) the FPs it generates
> are more likely to result in extremely rare and/or extremely justified FPs.
> And they score OTHER DNSBLs lower for those which have a higher frequency
> of hits on desired mail. And some have similar scoring options with other
> spam filtering systems in addition to SpamAssassin.
>
> (3) I'm certain that some portion of invaluement subscribers have BETTER
&g

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[David Hofstee]

Hi Stefano,

The only problem I see with Cloudmark is that they are not just a
reputation provider, but a spamfilter provider with access to all the data.
Which has been acquired by Proofpoint.

I'm asking myself the question if the fingerprints they collect are GDPR
proof (although Jaren may comment on that).

Yours,


David

On 8 June 2018 at 12:35, Stefano Bagnara  wrote:

> On Fri, 8 Jun 2018 at 11:53, David Hofstee 
> wrote:
> > [...]
> > I also think that there is space for a reputation provider which can:
> > - Identify more than just IP addresses and domains from an email.
>
> This is what CloudMark Authority does about this, but you enable a new
> set of issues that have been just fixed in the IP/domain world thanks
> to DMARC (I wrote an answer to the SDLU sister-thread).
> IIRC Vipul's Razor used the same fingerprinting concepts and ended up
> using a DNSBL of "fingerprints". Vipul founded Cloudmark and I don't
> know what is the current status of the Razor project.
>
> > - Is able to process feedback from domain owners and recipients in an
> automated, quick, effective and anonymous enough way (with the GDPR et al).
> Feedback is key.
>
> I strongly agree with "Feedback is key" both for "spam reports" and
> "non-spam reports" (and considering that "non-spam" only flows if you
> didn't block at the SMTP level).
> Unfortunately once you adopt SMTP reject based on a blacklist then you
> accept to stop getting false positives about that traffic, so you
> really stop monitoring the effectiveness of that block.
>
> The issue with this is that you have to start building a reputation
> not only for IP/domains/other email content fingerprints (sender
> stuff), but also need to build a reputation for feedback providers
> (recipient stuff) and maybe you also need a reputation management for
> people asking delisting (consultant, ESP...)
>
> A lot of data to mix.. so you start building some machine learning to
> deal with that automatically and then you end up with SmartScreen and
> no one, included your creator, will know why some message have been
> blocked or not ;-)   (no offense to SmartScreen, I know how hard is to
> deal with this stuff, but I receive Office365 invoices in spam, in my
> Office365 inbox.).
>
> An FBL system "ala Google PT" (so only aggregated data not enabling
> list washing) but open to multiple receivers could help adding more
> accountability to ESP to do their own filtering part (mainly with B2B
> emails, as with B2C they already have microsoft/yahoo/google data).
>
> Stefano
>
> ___
> mailop mailing list
> 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] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[David Hofstee]

Hi Rob,

> ... score of the sending-IP, which is similar to what you've described,
correct?
Correct.

So you have these mechanisms in place. But your customers, who get access
to the invaluement RBL, do not.  Am I correct? If I am, it still results in
the conclusion that blacklists are not sufficient to have a resulting good
spam filter. You would be ok, the list would not have false positives,
but your customers would not be sufficiently covered once bad guys get
smarter.

I also think that there is space for a reputation provider which can:
- Identify more than just IP addresses and domains from an email.
- Is able to process feedback from domain owners and recipients in an
automated, quick, effective and anonymous enough way (with the GDPR et al).
Feedback is key.

Yours,


David


On 7 June 2018 at 17:29, Rob McEwen  wrote:

> On 6/7/2018 9:45 AM, David Hofstee wrote:
>
>> Isn't it time conclude that "separate IP blacklists" combined with
>> "separate content filters" are not sufficient any more? Because you need
>> one to interact with the other? You need the content filter to steer the IP
>> blacklist (and other traffic limiting methods like throttling and
>> greylisting).
>>
>> In this sense, many IP blacklists have always been indicators of
>> reputation instead of being used to block traffic "without questions".
>> Adding to a spam score.
>>
>> I think that these more complicated spam filters need a lot of data to
>> work (both the email and how people react to it). That is not easy to
>> obtain for smaller domains. I guess there is a technical challenge in
>> that...
>>
>
>
> David,
>
> If I had tried to cover all such details in that article (and other
> similar things that you could also have mentioned, too) I would have had to
> write a book, not an article. In fact, my own filtering does such things -
> but I can afford the extra processing, where I accept every entire spam
> message and then combine all such processing as you described - and even
> having them dynamically interact in the ways you've described, and in other
> ways, too.
>
> For example, one of the 3rd party command-line anti-spam content filters
> that I use in my spam filtering is good at blocking elusive spams, but has
> just a few too many false positives. Therefore, I dynamically alter its
> spam scoring in my system based on the sending IP's reputation, increasing
> that score if the IP isn't in my whitelist, and then further altering its
> score based on my systems' overall reputation score of the sending-IP,
> which is similar to what you've described, correct?
>
> But I can afford to put much time and money into my filter per user - even
> if that time and cost isn't justified by the overall spam filtering
> revenue. I can afford this precicely because my anti-spam business
> essentially subsidizes my small mail hosting and spam filtering business,
> which mostly exists as a way to keep my finger on the pulse of what my
> typical DNSBL subscriber experiences. HOWEVER - many businesses don't have
> this flexibility and/or they are stuck with a "canned" anti-spam solution
> from a software or hardware vendor that doesn't provide such flexibility.
> (and not all email admins are coders/programmers! nor should they have to
> be!) And, as I mentioned, others have such massively high volumes of
> inbound mail that they DEPEND on significantly reducing the volume of spam
> (with IPv4 blacklists) before it hits any kind of content filtering.
>
> And these are the more common situations - those with situations like your
> situation or mine (for example, most of my spam filter is self-programmed!)
> ...are more rare.
>
> BTW - for anyone just joining this thread, here is the article being
> discussed:
> https://www.linkedin.com/pulse/should-mail-servers-publish-
> ipv6-mx-records-rob-mcewen/
>
>
> --
> Rob McEwen
> https://www.invaluement.com
>
>
> ___
> mailop mailing list
> 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] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[David Hofstee]

Hi Rob,

Isn't it time conclude that "separate IP blacklists" combined with
"separate content filters" are not sufficient any more? Because you need
one to interact with the other? You need the content filter to steer the IP
blacklist (and other traffic limiting methods like throttling and
greylisting).

In this sense, many IP blacklists have always been indicators of reputation
instead of being used to block traffic "without questions". Adding to a
spam score.

I think that these more complicated spam filters need a lot of data to work
(both the email and how people react to it). That is not easy to obtain for
smaller domains. I guess there is a technical challenge in that...

Yours,


David


On 7 June 2018 at 04:10, Rob McEwen  wrote:

> On 6/6/2018 8:11 PM, Brandon Long wrote:
>
>> Isn't the simplest way to handle this is to treat IPv6 at the /64 or
>> smaller level?
>>
>
> Brandon,
>
> Everything I've stated in that article, and in my comments on this thread
> - came with the foreknowledge that many of those who have discussed
> implementing IPv6 DNSBLs - have concluded that it would be wise to make the
> smallest block at the /64 level. I've already considered this. Your
> suggestion doesn't change a thing I've stated. And it doesn't change the
> "lack of scarcity" issues that will help IPv6 senders easily acquire new
> IPv6 space, where their paid hosters are not as concerned as much about
> soiled IP space, and start falling in love with spammers' money all over
> again. It also doesn't change the magical listwashing opportunities for
> sending spams on a one-IP (or /64) per recipient - then listwashing the
> recipients when that sending IPv6 (or IPv6 /64) gets listed. It doesn't
> change opportunities for them to do one-off sending where the resulting
> DNSBL entries greatly bloat the size of the DNSBL with entries that are
> absolutely worthless. There is just so much you glossed over or
> overlooked...
>
> I'm also not clear that content level scanning is really so much more
>> expensive that it can't be invested in.  "Here's a nickel kid, buy yourself
>> another VM" or something.
>>
>
> I've seen spam filters which were serving several thousand mailboxes and
> running on abundantly fast hardware - brought to their knees due to
> sending-IP filtering temporarily breaking due to a glitch, where everything
> then had to be fully content filtered. The problem here is that you're
> greatly underestimating the VAST difference in resources used when a
> majority of the spam is blocked by IPv4 RBLs at connection - vs - the
> resources needed to accept the entire message and then doing content
> filtering. This can really add up - to a point where it isn't "buying
> another cheap VM"... instead... that becomes... "quadruple your hosting
> budget", or worse. And this can also apply to large ISPs, too. I recall
> chatting with an admin from a really large ISP (~30M mailboxes) some years
> ago - and he told me - "we get 10s of thousand of messages per second, and
> we couldn't even begin to handle that volume without rejecting a large
> percentage of those at the connection based on the sending IP" - their
> expenses would instantly grow by many millions of dollars if they suddenly
> had to depend on much more content filtering.
>
> Also - large e-mail hosters who have teams of in-house software engineers
> (such as Microsoft, Google, Proofpoint, etc) are at a distinct advantage
> here because they have more options to do customized programming that
> enables them to implement strategies that will work better for IPv6 (such
> as filtering based on the DKIM domain, etc). In contrast, many smaller and
> medium sized businesses that used "canned" software or hardware-appliance
> solutions - are limited by the options presented in their software or
> hardware. And, unlike Google and Microsoft, they don't have the option to
> procure more hosting at essentially wholesale prices! So just because these
> issues are no big deal to YOU (Google) - doesn't mean that they don't
> present hardships to these other senders who might not have the flexibility
> and options you handle (potentially) too-fast paradigm shifts like this.
>
> So I'm just trying to help these other types to have the information they
> need to make "informed decisions" - which can be factored into their
> particular situation. Certainly, they shouldn't be pressured into
> publishing IPv6 records (and such pressure is already happening!),
> especially without knowing the rest of these facts - and especially not by
> others who have institutional advantages for handling IPv6 - who then might
> not empathize with their situation.
>
> Ironically, (and sadly) we ALREADY have had a situation for many years
> where the increasing complexity of managing a mail server had motivated
> many to abandon it and move their email to the cloud. This is not all bad -
> but I think the very large amount of that which occurred - was bad for the
> industry. We're now 

Re: [mailop] SNDS report issues?

[David Hofstee]

It does...

Yours,


David

On 31 May 2018 at 21:30, Michael Wise via mailop  wrote:

>
>
> Please … try this, replacing [MyKey] with … your key:
>
>
>
> https://sendersupport.olc.protection.outlook.com/SNDS/
> data.aspx?key=[MyKey]=052818
> 
>
>
>
> Apparently it does work.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* mailop  *On Behalf Of *Michael Wise
> via mailop
> *Sent:* Wednesday, May 30, 2018 3:58 PM
> *To:* Joel Golliet ; mailop@mailop.org
>
> *Subject:* Re: [mailop] SNDS report issues?
>
>
>
>
>
> Forwarding on your request …
>
> I gather that the data is flowing again, but not sure if we can back-fill.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
> 
> ?
>
>
>
> *From:* mailop  *On Behalf Of *Joel Golliet
> *Sent:* Wednesday, May 30, 2018 4:34 AM
> *To:* mailop@mailop.org
> *Subject:* Re: [mailop] SNDS report issues?
>
>
>
> I saw that we are now redirected from https://postmaster.live.com/
> 
> to https://sendersupport.olc.protection.outlook.com/
> 
> and we find SNDS data through a web browser (except for May the 26th).
>
> But we were used to get these data through CSV file with URL like
> https://postmaster.live.com/SNDS/data.aspx?key=xxx=052818
> 
> (for May the 28th of 2018) for example with a perl HTTP::Request script and
> we always get 500 error code.
> We changed it with a simple "curl" get on the new URL (
> https://sendersupport.olc.protection.outlook.com/SNDS/
> data.aspx?key=xx=052818
> 
> ) and the data are retrieved now but the "=" doesn't seem to be
> usable anymore. Even if we give an old date, we always get the last data
> available => from 5/29/2018 2:00 AM to 5/30/2018 2:00 AM.
>
> Does anybody have information on how to get the SNDS CSV data for a
> specific date now with curl request ?
>
> B.R.
>
> Le 29/05/2018 à 18:22, Annalivia Ford a écrit :
>
> And here :(
>
> Regards,
>
> Annalivia Ford
> Email Services Manager, EMEA
> [image: IBM Cognitive Engagement | Watson Marketing | Watson Commerce |
> Watson Marketing]
>
> [image: IBM Watson]
>
> Phone: +31 (0)6 53 32 34 44
> eMail: *annalivi...@nl.ibm.com *
>
>
>
>
>
>
>
>
>
>
>
> From:Marc Bradshaw via mailop 
> 
> To:mailop@mailop.org
> Date:29/05/2018 02:24
> Subject:Re: [mailop] SNDS report issues?
> Sent by:"mailop" 
> 
> --
>
>
>
>
> Yes, same here.
>
>
> - Original message -
> From: Joel Golliet 
> To: mailop@mailop.org
> Subject: Re: [mailop] SNDS report issues?
> Date: Mon, 28 May 2018 17:46:29 +0200
>
> Hi,
>
> it seems the problem is back. We don't have any SNDS data for 26-27th.
>
> B.R.
>
>
>
> --
>
>
>
> • * Joël GOLLIET |* * Ingénieur Infrastructure et Système*
> • 2L Multimedia - Park Nord, Les Pléiades, 74370 - 

Re: [mailop] GDPR and SMTP in general

[David Hofstee]

Hi,

There is a difference between being a "processor" and "telecommunications".
The telecommunications laws are different, more strict sometimes. I know
what the difference was in Dutch law, not sure in the EU area.

Yours,


David

On 25 May 2018 at 15:51, Renaud Allard via mailop  wrote:

>
>
> On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote:
>
>>
>> Yes, dealing with exactly the same kind of problem(s). One of my
>> customers asks me to sign for the fact that mail is encrypted when handling
>> it. However, using standard MTA software, messages that are in the queue
>> waiting to get delivered, are unencrypted. Am I forced to use disk
>> encryption?
>>
>>
> In the same vein, isn't encryption also required on the transmission
> channel? Should we now require for every mail TLS SMTP?
>
>
> ___
> mailop mailing list
> 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] Not receiving Y! local domains complaints

[David Hofstee]

Please note there is a difference in Yahoo European and other operations...
It can be seen in the MX records. Probably GDPR related. That may explain
it.

Yours,


David

On 23 April 2018 at 16:59, Benjamin BILLON  wrote:

> 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.
>
>
>
>
>
> There's something odd indeed.
>
>
>
> Best,
>
>
>
> --
>
> *Benjamin Billon*
>
>
>
> *From:* mailop  *On Behalf Of *Lindani
> Tshabangu via mailop
> *Sent:* Monday, 23 April, 2018 22:20
> *To:* mailop 
> *Subject:* [mailop] Not receiving Y! local domains complaints
>
>
>
> Good day,
>
>
>
> We stopped receiving complaints from Yahoo's local domains (yahoo.fr,
> Yahoo.es, Yahoo.de) but are receiving them normally from 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
>
> ___
> mailop mailing list
> 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] Salesforce Marketing Cloud EMEA Deliverability Consultant Role - France

[David Hofstee]

Hi Anthony,

I'm not sure what the consensus is on job adverts. I have an opening too.
But I would prefer it if you keep it away from this mailing list.

Email deliverability is a small world. Maybe you can use twitter for job
openings... #email #deliverability #job ...

Yours,


David

On 17 April 2018 at 17:47, Anthony Chiulli  wrote:

> Hi everyone!
>
> The SFMC Deliverability Services team in EMEA has gotten approval for an
> open headcount to add on another Deliverability Consultant. I wanted to
> share the publicly facing job posting with this group in case you know of
> anyone in EMEA who might be interested. The role notes the location as
> London, but it is preferred to be in France, and the recruiter is working
> to change the location to correct. Happy to submit an internal referral as
> well, just DM me!
>
>
> Please help promote and share
>
> https://salesforce.wd1.myworkdayjobs.com/External_Career_Sit
> e/job/United-Kingdom---London/Deliverability-Consultant_JR13170
>
>
> *ANTHONY CHIULLI*
>
> Associate Principal, Deliverability | Salesforce
> Mobile: 303.817.6506
>
>
>
> ___
> mailop mailing list
> 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] BGP Announcements

[David Hofstee]

Hi Ryan,

If spamfilters use machine learning, like the ones at Google, Microsoft,
Yahoo, Proofpoint (and Cloudmark) then they tend to have a lot of inputs.
Including "reputation" on AS and IP which may be dependent on changes in
routing. Because that is one of the tricks that spammers use. This can
cause weird false-positives (good email being filtered). You may not even
know that you are doing something wrong, but you may still end up on the
bad side of filtering because of that.

Thing is, these ML engines are hard to "introspect" (its rules are not laid
out, but are the result of self tuning internal parameters). It decides
itself what is bad and not bad. Not even the people managing the filter may
be able to tell exactly unless they have an example. Or tune it, for that
matter.

So watch those... I would not worry about the rest.

Yours,


David

On 6 April 2018 at 12:21, Ken O'Driscoll via mailop 
wrote:

> On Thu, 2018-04-05 at 12:21 -0600, Ryan Harris via mailop wrote:
> > Could this cause other issues I'm not thinking of?
>
> I think you just need to make sure that whatever you're doing wouldn't look
> like hijacking to a (moderately intelligent) machine learning algorithm.
> And if you're keeping it all under the same AS then it probably wouldn't.
>
> I've never personally encountered a problem which was purely caused by
> reassigning netblocks under the same org.
>
> 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
>



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

[mailop] Just for fun

[David Hofstee]

Test you DNS-foo by reading
https://security.stackexchange.com/questions/182855/is-it-okay-to-publish-a-tlsa-records-for-non-dnssec-cnameed-services

Yours,

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

Re: [mailop] Any Spark New Zealand people here?

[David Hofstee]

Hi,

Thanks for reaching out. I've sent it through the normal channel.

Yours,


David

On 21 March 2018 at 07:25, Simon Lyall <si...@darkmere.gen.nz> wrote:

>
> Spark outsources email to smxemail.com. You could try going via
> emailsupp...@smxemail.com (See https://smxemail.com/support )
>
> If no luck ping me and I'll see if I can find someone.
>
>
>
> On Tue, 20 Mar 2018, David Hofstee wrote:
>
>> No, but I am interested too. I couldn't get a hold of them.
>>
>> Yours,
>>
>>
>>
>> David
>>
>> On 19 March 2018 at 21:38, <josh.na...@oracle.com> wrote:
>>   If anyone has postmaster info for xtra.co.nz (owned by
>>   Spark.co.nz), could you contact me off-list? Trying to look into
>>   a soft bounce issue.
>>
>>   Thanks!
>>
>>   ___
>>   mailop mailing list
>>   mailop@mailop.org
>>   https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>>
>>
>> --
>> --
>> My opinion is mine.
>>
>>
>>
> --
> Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
> "To stay awake all night adds a day to your life" - Stilgar
>
>


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

Re: [mailop] Any Spark New Zealand people here?

[David Hofstee]

No, but I am interested too. I couldn't get a hold of them.

Yours,



David

On 19 March 2018 at 21:38,  wrote:

> If anyone has postmaster info for xtra.co.nz (owned by Spark.co.nz),
> could you contact me off-list? Trying to look into a soft bounce issue.
>
> Thanks!
>
> ___
> mailop mailing list
> 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

[mailop] Surge in Yahoo bounces

[David Hofstee]

Hi,

As some
have
seen there is a spike in Yahoo's "*554 delivery error: dd This user doesn't
have a yahoo.com  account ...@...*" 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] Anyone from Gmail ?

[David Hofstee]

> Do you believe "open rate" metrics are that accurate?
That depends on the domain and the user-agent in question. Some load images
automatically when viewing the message.

>  If bulk senders routinely detect when a user opens messages, that user
is not following basic email safety principles
I am not sure how much tin-foil I can advise you to use. Tracking is
everywhere, in many forms. Not just in email newsletters. So I think this
discussion belongs somewhere else.

Yours,


David

On 6 March 2018 at 18:02, Bill Cole <mailop-20160...@billmail.scconsult.com>
wrote:

> On 6 Mar 2018, at 9:09, David Hofstee wrote:
>
> Hi Vaibhav,
>>
>> So if you have 12% open rate.. It means that for  every (100/12 =) 8.3
>> emails you send, one is relevant. It is my expectation, maybe Brandon
>> knows
>> more, that your emails are not relevant enough. Is this really something
>> the subscribers asked for? Because they lack real engagement.
>>
>
> Do you believe "open rate" metrics are that accurate?
>
> As someone working mostly with non-broadcast B2B email, I have done a fair
> bit of user training and documentation focused on safe email practices. If
> bulk senders routinely detect when a user opens messages, that user is not
> following basic email safety principles.
>
>
> ___
> mailop mailing list
> 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] Anyone from Gmail ?

[David Hofstee]

Hi Vaibhav,

So if you have 12% open rate.. It means that for  every (100/12 =) 8.3
emails you send, one is relevant. It is my expectation, maybe Brandon knows
more, that your emails are not relevant enough. Is this really something
the subscribers asked for? Because they lack real engagement.

We all have "important" customers. That doesn't make it magically work.
They too should send out emails that people want to read. I think your 12%
openrate is pretty low (on the low end of what to accept). Good luck trying
to explain this to your customer.

Yours,


David

P.S. Some metrics:
https://www.marketingcharts.com/digital/email-online-and-mobile-82552/attachment/returnpath-email-deliverability-metric-benchmarks-by-industry-in-2017-mar2018
(and think of "what it can be" rather than "we are just a tad lower").

On 6 March 2018 at 12:48, Vaibhav  wrote:

> Hi,
>
> Recently I started working with one of the top Bank where we have setup
> dedicated infrastructure to send out emails.
>
> As per Gmail postmaster initially Delivery IP, sending domain used to
> carries high reputation with avg. 12% OR with no bounces & less
> unsubscribe. After few days Gmail suddenly started filtering emails as spam
> & reputation at Gmail Postmaster went down.
>
> We look at the historical dataset where we don't see any data point which
> might causes reputation to go down. We are sending emails to double opt in
> dataset, with avg. 10 to 15% user engagement on sent with less bounces &
> unsubscribes. Gmail postmaster show 0% spam rate / feedback loop.
>
> What could be the reason to filter emails as spam ? We tried to reach out
> Gmail postmaster team but could find any help.
>
> Currently we are sending emails with same setup with avg. 5% OR ( might
> few users are getting email in inbox ) where domain still carries low
> reputation & IP's are in HIGH reputation. Its been 15 days where we don't
> see any improvement here.
>
> Can anyone help me over here in terms of what is going wrong here ?
>
> --Vaibhav
>
>
>
> ___
> mailop mailing list
> 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] Microsoft IPs automatically unsubscribing recipients?

[David Hofstee]

I am against scanning everything in order to protect. Because every method
an ESP needs to do to "fix" these bad unsubscribes can just as easily be
spoofed by bad actors (e.g. redirect url to non-malicious content for first
10 minutes). And not all ESPs are even aware of this scanning process (if
they are even that capable*).

The bottom line is that spamfilters cannot pretend to be humans (and act
accordingly). It will be only a short moment until the malicious payload
will be behind the "unsubscribe button" instead of the "unsubscribe page".
What is next, spamfilters pushing the button? This is not the technical
innovation we are looking for. It does not improve the signal to noise
ratio by much.

Just looking at recipients who would be behind the engagement-filter
doesn't do the trick either. You counter the ESPs methods *and *it can only
work if the filter will actually unsubscribe too.

Maybe it is a shifting definition of spamtrap (a content verifying
trap/spamtrap).

Yours,


David

* not trying to badmouth others here ;-)

On 3 March 2018 at 00:53, Dave Warren  wrote:

> On 2018-03-01 16:26, David Carriger wrote:
>
>> Yes, I'm still seeing this. So, an open question:
>>
>> As an ESP, how am I supposed to tell my users to practice good list
>> hygiene and remove unengaged recipients from their lists when my data is
>> being tainted by Google/Microsoft/etc triggering all of my engagement
>> mechanisms (open tracking pixel, tracked links, etc)? These show up as
>> their /most/ engaged recipients.
>>
>> Obviously there are things that can be done on my end (look for all URIs
>> in the email being triggered with a short time frame from IP ranges that we
>> know do this behavior and don't count those as engagement), so I'll tread
>> down that path with our developers. Still, I find it frustrating, and
>> wonder how other people are dealing with this issue.
>>
>
> I don't know if this has already been discussed, but what's the
> User-Agent? Any clues there?
>
>
> ___
> mailop mailing list
> 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] Quick question on Comcast FBL...

[David Hofstee]

We see it too, down to 2011. This was Feb 7th where someone made note of
that. Of IPs that are not sending email anymore.

Yours,



David

On 26 February 2018 at 17:36, Eric Tykwinski  wrote:

> Just last week I’ve noticed a sudden uptick on very old spam
> notifications.  (Some dated back to 2010…)
>
> Just wondering if anyone else is seeing the same and if Comcast knows
> about it.
>
> Doesn’t seem to be effecting our deliverability, but guessing maybe they
> did some changes.
>
>
>
> Sincerely,
>
>
>
> Eric Tykwinski
>
> TrueNet, Inc.
>
> P: 610-429-8300 <(610)%20429-8300>
>
>
>
> ___
> mailop mailing list
> 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

[mailop] TLS support

[David Hofstee]

Hi,

A quick question... Does anyone have numbers on:
- the (volume) percentage of emails sent via TLS (capable mail servers)
- the (volume) percentage of emails sent via TLS where the receiving mta
has a valid certificate
- the (volume) percentage of emails sent via TLS where the receiving mta
uses a valid certificate and supports DANE

Any answer is appreciated. Yours,


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

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

[David Hofstee]

> Then maybe you use my opensource Apache jDKIM library? ;-)
It was a while ago (1,5 years). Can't remember (and I didn't code it myself
as I was preparing the company for an ISO 27k1 audit).

And while I am thinking about how clumsy these emails generally are,
describing the required DNS modifications. Maybe there is room for an RFC
that describes the required DNS modifications. It would allow for more
tooling to be written that can verify such settings.

Yours,



David

On 19 February 2018 at 13:08, Stefano Bagnara <mai...@bago.org> wrote:

> On 19 February 2018 at 12:24, David Hofstee <opentext.dhofs...@gmail.com>
> wrote:
> >>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
> >
> > Why would you need to "manually help" people? SPF and DKIM can
> > be automated. Customers only need instructions for 3 DNS records.
> > Verification of those settings can be automated.
> >
> > In MailPlus you can request this SPF/DKIM setting verification page:
> > https://drive.google.com/open?id=0B3Pxi9-uQ2MtbUdNeDByR3hqcTRHY2NyMk4zU
> VJscTh2clFr
>
> Are you telling me that none of your customers needed help with that?
> Your customers probably have an IQ above average! How many
> customer-support people do you have for every 1000 users of the
> platform?
>
> My users have issues identifying a button when there is only one
> button in the whole page, so we are very dedicated to UX. They don't
> even know who/where to go to alter DNS of their own domain, and there
> are plenty of providers with their own tool to deal with DNS entries.
> We work a lot on helpdesk and for every step you add, even the most
> trivial, we will get more requests.
>
> Last time I checked most big freemium ESP let you do this
> configuration as an option, but they also let you send without
> altering your DNS: maybe they shared my concern.
>
> > It checks if your DNS settings are ok, validate if DMARC settings are not
> > too restrictive and will setup SPF/DKIM automatically if they are.
> Signing
> > is done in Java (and not on the mta). No hands needed anymore.
>
> Then maybe you use my opensource Apache jDKIM library? ;-)
>
> Stefano
>
> >
> > Yours,
> >
> >
> > David
> >
> >
> > On 18 February 2018 at 00:53, Dave Warren <d...@thedave.ca> wrote:
> >>
> >> On 2018-02-17 03:48, Stefano Bagnara wrote:
> >>>
> >>> Unfortunately there are still some server accepting everything and
> >>> sending bounces without headers or malformed bounces.
> >>
> >>
> >> This is not a small group. Every few months I get massive floods of
> >> bounces from some spambot that decided forging my domain is a good idea.
> >>
> >> I didn't even realize this was still a thing when I was running my own
> >> mail server as I've used something similar to BATV for years. But after
> >> switching my personal to a host that doesn't use this technique I have
> begun
> >> to realize just how much garbage goes flying by out there.
> >>
> >>
> >>
> >> ___
> >> mailop mailing list
> >> 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
> >
>
> ___
> mailop mailing list
> 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] VERP in 2018 (Was: RoadRunner Help?)

[David Hofstee]

I think there were (as this was my previous employer) 2 or 3 support crew
per 1000 accounts.

And sure there were questions. But this would only escalate to me if the
technical dept. did not agree to the settings that were prefilled (e.g.
some customers simply demand 2048 bit DKIM). The advantage of this form is
that the link could be forwarded to the people "who did their website" or
"their hosting company". They could implement and verify DKIM/SPF settings
themselves (which was a huge win; most hosting service desks are not that
DKIM/SPF savvy or make tiny mistakes).

We would also let you send without the modifications. But we pushed for
strong authentication. This made the push easier and faster.

Yours,


David

On 19 February 2018 at 13:08, Stefano Bagnara <mai...@bago.org> wrote:

> On 19 February 2018 at 12:24, David Hofstee <opentext.dhofs...@gmail.com>
> wrote:
> >>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
> >
> > Why would you need to "manually help" people? SPF and DKIM can
> > be automated. Customers only need instructions for 3 DNS records.
> > Verification of those settings can be automated.
> >
> > In MailPlus you can request this SPF/DKIM setting verification page:
> > https://drive.google.com/open?id=0B3Pxi9-uQ2MtbUdNeDByR3hqcTRHY2NyMk4zU
> VJscTh2clFr
>
> Are you telling me that none of your customers needed help with that?
> Your customers probably have an IQ above average! How many
> customer-support people do you have for every 1000 users of the
> platform?
>
> My users have issues identifying a button when there is only one
> button in the whole page, so we are very dedicated to UX. They don't
> even know who/where to go to alter DNS of their own domain, and there
> are plenty of providers with their own tool to deal with DNS entries.
> We work a lot on helpdesk and for every step you add, even the most
> trivial, we will get more requests.
>
> Last time I checked most big freemium ESP let you do this
> configuration as an option, but they also let you send without
> altering your DNS: maybe they shared my concern.
>
> > It checks if your DNS settings are ok, validate if DMARC settings are not
> > too restrictive and will setup SPF/DKIM automatically if they are.
> Signing
> > is done in Java (and not on the mta). No hands needed anymore.
>
> Then maybe you use my opensource Apache jDKIM library? ;-)
>
> Stefano
>
> >
> > Yours,
> >
> >
> > David
> >
> >
> > On 18 February 2018 at 00:53, Dave Warren <d...@thedave.ca> wrote:
> >>
> >> On 2018-02-17 03:48, Stefano Bagnara wrote:
> >>>
> >>> Unfortunately there are still some server accepting everything and
> >>> sending bounces without headers or malformed bounces.
> >>
> >>
> >> This is not a small group. Every few months I get massive floods of
> >> bounces from some spambot that decided forging my domain is a good idea.
> >>
> >> I didn't even realize this was still a thing when I was running my own
> >> mail server as I've used something similar to BATV for years. But after
> >> switching my personal to a host that doesn't use this technique I have
> begun
> >> to realize just how much garbage goes flying by out there.
> >>
> >>
> >>
> >> ___
> >> mailop mailing list
> >> 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
> >
>
> ___
> mailop mailing list
> 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] the joys of VERP, was RoadRunner Help?

[David Hofstee]

I've seen many asynchronous bounces where the local part is cut-off after
64 characters... It seems some mta's are pedantic in this regard.

Yours,


David

On 17 February 2018 at 18:46, John Levine  wrote:

> In article  mail.gmail.com> you write:
> >The use of IDs instead of the real original email in the return-path
> >may also be because of length limits.
> >Max length of an email address is 254 chars. If you have to insert it
> >"almost clear" in a return path and change the domain then there are
> >chance your return-path address will be more than 254 chars.
> >so if your original address is "a 242 ti...@example.com" how do you
> >add VERP to it without some sort of obfuscation?
>
> Actually, you're more likely to hit the local-part limit of 64 first,
> but how many real addresses (as opposed to artificial stress tests
> ones) have you seen where that's a problem?
>
> I'm not opposed to using tokens but I don't see it as a security
> issue, just something that might save a lookup in bounce processing.
>
> R's,
> John
>
> ___
> mailop mailing list
> 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] VERP in 2018 (Was: RoadRunner Help?)

[David Hofstee]

>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

Why would you need to "manually help" people? SPF and DKIM can
be automated. Customers only need instructions for 3 DNS records.
Verification of those settings can be automated.

In MailPlus you can request this SPF/DKIM setting verification page:
https://drive.google.com/open?id=0B3Pxi9-uQ2MtbUdNeDByR3hqcTRHY2NyMk4zUVJscTh2clFr

It checks if your DNS settings are ok, validate if DMARC settings are not
too restrictive and will setup SPF/DKIM automatically if they are. Signing
is done in Java (and not on the mta). No hands needed anymore.

Yours,


David


On 18 February 2018 at 00:53, Dave Warren  wrote:

> On 2018-02-17 03:48, Stefano Bagnara wrote:
>
>> Unfortunately there are still some server accepting everything and
>> sending bounces without headers or malformed bounces.
>>
>
> This is not a small group. Every few months I get massive floods of
> bounces from some spambot that decided forging my domain is a good idea.
>
> I didn't even realize this was still a thing when I was running my own
> mail server as I've used something similar to BATV for years. But after
> switching my personal to a host that doesn't use this technique I have
> begun to realize just how much garbage goes flying by out there.
>
>
>
> ___
> mailop mailing list
> 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] Yahoo Support Page

[David Hofstee]

As much as I like to complain, I am not sure I would come to the same
conclusion. It seems like a simple bug.

Yours,


David

On 13 February 2018 at 19:49, Philip Paeps <phi...@trouble.is> wrote:

> 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
>



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

Re: [mailop] Yahoo Support Page

[David Hofstee]

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).

Yours,


David


On 13 February 2018 at 14:38, David Hofstee <opentext.dhofs...@gmail.com>
wrote:

> I created the login a long time ago. That part was done. I guess the form
> is a hit and miss.
>
> I'll just waste more of my time.
>
> Yours,
>
>
> David
>
> On 13 February 2018 at 14:06, Udeme Ukutt <uukutt...@gmail.com> wrote:
>
>> I’ve not had issues submitting stuff through the Yahoo Postmaster forms
>> in the last few weeks - most recent a few days ago. Basically before you
>> try to, you need to (create and then) login to a yahoo email address - then
>> visit postmaster.yahoo.com.
>>
>> Udeme
>> Postmaster at Wish
>>
>> On Tue, Feb 13, 2018 at 7:59 AM David Hofstee <
>> opentext.dhofs...@gmail.com> wrote:
>>
>>> This is still the case... Yahoo cannot be reached for deliverability
>>> issues.
>>>
>>>
>>> David
>>>
>>> On 19 September 2017 at 04:40, Benjamin BILLON via mailop <
>>> mailop@mailop.org> wrote:
>>>
>>>> What's the URL?
>>>> Is it to reach the page, or after you submit the form?
>>>>
>>>>
>>>> --
>>>> <https://www.splio.com>
>>>> Benjamin
>>>>
>>>> 2017-09-19 1:53 GMT+08:00 Scot Berggren <sbergg...@alterian.com>:
>>>>
>>>>> Is anyone on here from Yahoo?
>>>>>
>>>>>
>>>>>
>>>>> I’ve been trying to submit a ticket via their support site, but for
>>>>> the past week keep getting this message:
>>>>>
>>>>> Sorry, there was an error on our end. Please try again later.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> *Scot Berggren* *|* Deliverability and Compliance Manager *|*
>>>>> Alterian US *|* sbergg...@alterian.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
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> My opinion is mine.
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>
>
>
> --
> --
> My opinion is mine.
>



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

Re: [mailop] Yahoo Support Page

[David Hofstee]

I created the login a long time ago. That part was done. I guess the form
is a hit and miss.

I'll just waste more of my time.

Yours,


David

On 13 February 2018 at 14:06, Udeme Ukutt <uukutt...@gmail.com> wrote:

> I’ve not had issues submitting stuff through the Yahoo Postmaster forms in
> the last few weeks - most recent a few days ago. Basically before you try
> to, you need to (create and then) login to a yahoo email address - then
> visit postmaster.yahoo.com.
>
> Udeme
> Postmaster at Wish
>
> On Tue, Feb 13, 2018 at 7:59 AM David Hofstee <opentext.dhofs...@gmail.com>
> wrote:
>
>> This is still the case... Yahoo cannot be reached for deliverability
>> issues.
>>
>>
>> David
>>
>> On 19 September 2017 at 04:40, Benjamin BILLON via mailop <
>> mailop@mailop.org> wrote:
>>
>>> What's the URL?
>>> Is it to reach the page, or after you submit the form?
>>>
>>>
>>> --
>>> <https://www.splio.com>
>>> Benjamin
>>>
>>> 2017-09-19 1:53 GMT+08:00 Scot Berggren <sbergg...@alterian.com>:
>>>
>>>> Is anyone on here from Yahoo?
>>>>
>>>>
>>>>
>>>> I’ve been trying to submit a ticket via their support site, but for the
>>>> past week keep getting this message:
>>>>
>>>> Sorry, there was an error on our end. Please try again later.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> *Scot Berggren* *|* Deliverability and Compliance Manager *|* Alterian
>>>> US *|* sbergg...@alterian.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
>>>
>>>
>>
>>
>> --
>> --
>> My opinion is mine.
>> ___
>> mailop mailing list
>> 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] Yahoo Support Page

[David Hofstee]

This is still the case... Yahoo cannot be reached for deliverability
issues.


David

On 19 September 2017 at 04:40, Benjamin BILLON via mailop  wrote:

> What's the URL?
> Is it to reach the page, or after you submit the form?
>
>
> --
> 
> Benjamin
>
> 2017-09-19 1:53 GMT+08:00 Scot Berggren :
>
>> Is anyone on here from Yahoo?
>>
>>
>>
>> I’ve been trying to submit a ticket via their support site, but for the
>> past week keep getting this message:
>>
>> Sorry, there was an error on our end. Please try again later.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> *Scot Berggren* *|* Deliverability and Compliance Manager *|* Alterian US
>>  *|* sbergg...@alterian.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
>
>


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

Re: [mailop] Mail Transfer Agent Alternatives

[David Hofstee]

So yes, Message Systems have a model that they want you to pay per email.
Maybe not yet, but in the future. If it is on premise or in the cloud, they
don't care. To do that they took over Port25. You are forced to get updates
due to the fact that you need security updates.

Some ESPs have started to implement their own mta (Sendgrid, haven't kept
tabs on others). There is no open source mta that is fast enough. And all
ESPs don't seem to want to cooperate to create one (it doesn't hurt enough,
price wise). You don't want to create a spamming tool either.

Yours,



David



On 5 February 2018 at 08:57, Benjamin BILLON  wrote:

> 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
>
>
> --
>
> *EMRE ÜST*
>
> Deliverability Specialist
>
>
>
> *t.*   +902123430739 <+90%20212%20343%2007%2039>
> *f.*   +902123430742 <+90%20212%20343%2007%2042>
>
> *email: *emre@euromsg.com <%23>
> *skype:* user_name
> *web:* euromsg.com
> 
> Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul
>
>
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
> 
>
>
>
> 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
>
>


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

Re: [mailop] Issues delivering to Hotmail addresses

[David Hofstee]

Something else is going on. Because separate regions is not a problem if
you would store the email "per recipient". Just replicate it and store it
in more than one region. Somehow this is not allowed.

So it also means that they only want to store the email just once. That can
be a functional requirement (once per tenant) or for their anti-spam system
(which probably does not like multi-tenant systems since it would result in
inconsistent results).

Yours,


David

On 24 January 2018 at 05:29, Benjamin BILLON  wrote:

> 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
>



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

[mailop] malware on cloud...

[David Hofstee]

Hi,

I hadn't seen this,
https://blog.knowbe4.com/heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video,
before. Another interesting threat vector (this example specifically aimed
at email).

Yours,


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

Re: [mailop] Hotmail/Outlook feedback loop processing delay?

[David Hofstee]

> It was not on their inbox, so they used search to find all emails from us
and last year's email
> came up. So they clicked on last year's email and opened it. They did
not report it as spam
> yesterday, they only viewed it. They don't use an  email client, they
only use the web interface
> provided by hotmail.
If you have open tracking with https, you can see in what folder the email
was opened (if you log the referer).

Yours,


David

On 10 January 2018 at 08:54, Stefano Bagnara  wrote:

> On 10 January 2018 at 08:16, Sotiris Tsimbonis  wrote:
> > [...] They did
> > not report it as spam yesterday, they only viewed it. They don't use an
> > email client, they only use the web interface provided by hotmail.
>
> I often heard story like this... the fact is that this "i never marked
> it as spam" is always from a non-techie person..
> - Sometimes they lie, because they didn't know you spy on their
> "junking habits", so they simply deny when you ask why they did
> something they didn't know you could "monitor".
> - Sometimes they don't even know what is the spam button (some of them
> think it is like trash, some of them don't know at all).
> - Sometimes they happen to click on stuff without really recognizing they
> did.
>
> We run a SaaS and very often our users say they never did something
> until we dig in the logs and have evidence they really did that, so my
> first think is always "everybody lies" (sometimes they are not really
> aware they are lying, they simply never read/tried to understood and
> thought that "permanently delete" means "hide this for a while").
>
> It is possible there is a bug in the platform, but I still have to get
> similar reports from a trusted source or see the behaviour with my
> eyes. So, I think you should take this at least as an option (and use
> Occam's razor).
>
> > So it's not bulk moving emails to junk using imap. Opening the email
> > yesterday triggered the fbl process somehow.
> >
> > I'm still not quite certain of how it works, but Mihai Costea also
> > posted that 1% of their fbl reports are back from 2016 ...
>
> I don't see anything weird from that. People can mark as spam any
> email, even if the email has been received a lot of time ago.
> He told that he searched the email, maybe they also marked it as spam:
> this kind of action could have the legitimate result to send an FBL
> for an old message.
>
> It sound like an expected distribution:
> 0.1% per month (1% in 10 months) 2 years ago
> 0.4% per month (4% in 10 months) 1 year ago
> 2.5% per month (5% in 2 months) 3 months ago
> 90% per month (90% in 1 the last month).
>
> If you do open-tracking you can see similar distributions with
> messages being opened even after many years. If they are opened after
> years there's nothing weird to see they are sometimes also marked as
> spam after years.
>
> Stefano
>
> ___
> mailop mailing list
> 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] Anyone with a pulse at combell.com?

[David Hofstee]

Hi Philip,

Did you try it with a non-"trouble.is" domain? E.g. an @gmail.com account?

Yours,


David

On 6 January 2018 at 15:32, Philip Paeps  wrote:

> I'm getting repeated spamtrap hits from customers of combell.com.
> Forwarding messages (even just headers) to abuse@ gets bounces:
>
>  ab...@combell.com
>host 217.21.178.56 [217.21.178.56]
>SMTP error from remote mail server after end of data:
>550 5.7.1 Message rejected as spam by Content Filtering.
>
> Asking abuse@ how they'd like to be told about their customers' network
> abuse gets bounced with the same error.  Great!
>
> Does anyone know any humans there?
>
> They're unfortunately too large to block outright.
>
> Thanks.
> Philip
>
> --
> Philip Paeps
> Senior Reality Engineer
> Ministry of Information
>
> ___
> mailop mailing list
> 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] Anyone else seeing "451 4.7.500 Server busy" from Hotmail?

[David Hofstee]

Hi Frank,

The AS values are internal Microsoft codes, unknown to most here. They seem
to be failrly consistent. Microsoft changed their server platform a few
months back. Not everything, such as "when do you see X" is clear yet.

The server may be busy (for the level of reputation of the sending IP etc
etc). I notice different behavior for different customers (on dedicated
IPs). Some handle 90k per hour without any deferrals, others get these
deferrals and get to 30k/IP/hr. Same customer, same moment in time,
different brand domain sender.

You are supposed to "ease off" on the sending rate when you see this too
often. Not sure what the exact specs for "ease off" and "too often" are
(and where the "ease on" part starts).

Yours,


David

On 5 January 2018 at 04:28,  wrote:

> Starting just after 9 pm (U.S. Central) we started seeing a little:
> ubad=14039790, Site (hotmail.com/104.47.10.33) said: 451 4.7.500
> Server busy. Please try again later from [96.31.0.20]. (AS761)
> [DB5EUR03FT004.eop-EUR03.prod.protection.outlook.com]
> ubad=14039790, Site (hotmail.com/104.47.33.33) said: 451 4.7.500
> Server busy. Please try again later from [96.31.0.20]. (AS843)
> [BN3NAM01FT051.eop-nam01.prod.protection.outlook.com]
>
> Target IPs are 104.47.10.33, 104.47.32.33, and 104.47.33.33.
>
> Anyone else see this, or know what Hotmail's antispam (AS) values mean?
>
> Regards,
>
> Frank Bulk
>
>
> ___
> mailop mailing list
> 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] Issue with Gmail Postmaster

[David Hofstee]

Hi,

We recently (in October) added a "default" DKIM signature. You start with a
"low" reputation (as they don't know you). I am pretty sure they
retroactively notched my domain reputation up from medium to high. I
remember being on medium, now I see the reputation going to high on 8th of
December.

So I reviewed the graph for 120 days. In the domain reputation graph they
even display information before there was such a default DKIM signature
(which didn't use to be there). Somehow they are adding other
domain reputation data that they find relevant/reliable enough (coming from
emails without DKIM signatures of that domain). It also seems this graph is
getting more dynamic in nature.

Yours,


David

On 29 December 2017 at 17:20, Julie Ralston via mailop 
wrote:

> Back to normal for me as well.
>
>
>
> -Julie
>
>
>
>
> Julie Ralston
> Email Deliverability Expert
> 1001 Cathedral Street
> Baltimore, MD 21201
> Phone: 410-864-0891 <(410)%20864-0891>
> E-Mail: jrals...@pubsvs.com
> Website: https://pubsvs.com
>
> [image: www.pubsvs.com]
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Benjamin
> BILLON
> *Sent:* Thursday, December 28, 2017 9:05 PM
> *To:* mailop@mailop.org
>
> *Subject:* Re: [mailop] Issue with Gmail Postmaster
>
>
>
> 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 <
> mailop@mailop.org> wrote:
>
> Google changed something early yesterday afternoon as this was fine up
> until then.  Observing this across the board here as well.
>
>
>
>
>
> On Dec 28, 2017, at 7:28 AM, Chris Nagele  wrote:
>
>
>
> I can confirm we are seeing the same for most domains. IP reputation
> is showing many new IPs we don't recognize and domain reputation
> retroactively changed from being high to medium and even low.
>
> --
> Chris Nagele
> CTO, Wildbit
> http://wildbit.com
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
>
>
> --
>
>
> Mohammed Ahmed
>
> Director, Deliverability
>
> Phone # 1-877-AWeber-1 ext 813
>
>
>
> *https://www.aweber.com/email-automation.htm?utm_source=awemail_medium=email_campaign=awteam_content=awteamsign_automations
> *
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
>
>
> --
>
> Luke Martinez
>
> Team Lead | Email Delivery
>
> 520.400.5693 <(520)%20400-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
>
>


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

Re: [mailop] Message recipients column in SNDS

[David Hofstee]

It is even so bad that Microsoft support misinterprets the statistics...
>From a Microsoft ticket (regarding a dedicated IP):

We have investigated your deliverability issue (case ticket:
SR#1407666085). At the current time, your IP address (149.235.15.xx) is
blocked for namespace mining behavior and is not eligible for mitigation.



Please understand, namespace mining behavior is not the same as sending
spam. It is not caused by sending large volumes of email. Namespace mining
behavior is identified when Outlook.com sees requests to validate large
numbers of possible email addresses without sending (or attempting to send)
equal numbers of emails. Namespace mining is usually the result of a
compromise (of the server, the network, or some user accounts), or a
misconfiguration in the email system setup.



This is the most recent incidents of namespace mining behavior.



 IP address: <*149.235.15.124*>

Day

# Mails

# RCPTs

#Diff

11/14/2017

12,098

28,021

15923





As you can see in the table above the number of RCPT requests is
significantly higher than the number of actual emails sent. In normal
situations, these numbers of RCPT requests would be very close to the
number of emails sent. It is important that you take steps to investigate
the namespace mining behavior. The root causes must be addressed as soon as
possible.



Obviously my logs showed that only '4xx' deferrals accounted for the
difference. The 5xx bounce rate was well under 1%.

David

On 2 November 2017 at 21:33, Emre Üst |euro.message| 
wrote:

> Hello Maarten ,
>
> Errors you have received,  returned to normal?
>
> We too ,detected large difference between these numbers,
>
> RCPT
> commands  111829
>
> DATA
> commands 106093
>
> Message
> recipients 1215
>
>  and we only see
>
> 451 4.7.500 Server busy. Please try again later from []. (AS3114) [
> AM5EUR02FT027.eop-EUR02.prod.protection.outlook.com]" while connected
> from () to hotmail-com.olc.protection.outlook.com (104.47.4.33)
>
> Thank you
>
>
> --
>
> *EMRE ÜST*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> mailop mailing list
> 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] 5.7.1 bounce codes

[David Hofstee]

Analyze the Diagnostic-Code text first, that is for sure. You can expect
anywhere between 1000 and 2000 regex rules to get to 99%+
effectiveness. (E)Smtp codes are bad for primary bounce
handling rules, they work fine as a backup.

I would state N is 3 or 4. But I would not remove the recipient from the
list unless the first 5xx in the 5xx-series is 2 to 4 weeks old. This
overcomes the "inbox full" during holidays and gives time to solve blocking
problems (for e.g. daily senders).

Yours,


David

On 11 December 2017 at 19:36, Al Iverson  wrote:

> If you use a counter-based bounce processing system that eventually
> invalidates repeatedly 5xx bouncing recipients, I wouldn't exclude 5.7.1
> response codes from that process. If your sending client isn't actively
> addressing the issue and working with you to get the block removed, then
> continuing to pound at that locked door is not only pointless, but
> considered rude by some. If you know the issue wasn't driven by mailing to
> those same subscribers, then it quite possibly makes sense to re-set their
> status to mailable, but only after the issue is addressed. Trying to exempt
> certain bounce codes from applying to address suppression seems like
> something that would be forever imperfect and you'll just be chasing after
> it down the road, dealing with its imperfections.
>
> Regards,
> Al Iverson
>
> On Mon, Dec 11, 2017 at 11:43 AM, Maarten Oelering <
> maar...@postmastery.net> wrote:
>
>> I would not say exclusively. Code 5.7.1 is also used for “Relay access
>> denied” for example. This bounce is often caused by typo domains that end
>> up at a default MX. From my experience, it is better to match a bounce
>> category first on the text, and then on the status code.
>>
>> For the actions, I agree that bounces due to “blocks” etc should *not*
>> be counted against the recipient (which is typically implied by “soft”).
>> There should be 3 different actions related to bounces: remove recipient
>> immediately (“hard”), remove recipient after N consecutive bounces
>> (“soft”), and count on campaign level but ignore on recipient level.
>>
>> Maarten Oelering
>> Postmastery
>>
>> On 11 Dec 2017, at 16:41, Alexander Burch 
>> wrote:
>>
>> 5.7.1 codes are used exclusively for policy blocks (IP blacklisted,
>> content deemed spammy etc).
>>
>> Gmail uses it for DMARC rejections.
>>
>> Hotmail also uses 5.7.1 when an IP is outright blocked.
>>
>> This type of bounce confuses me a little. It certainly shouldn't be used
>> to mark the recipient as invalid, and it shouldn't be treated as a soft
>> bounce either (using the traditional 3 strike rule). But most ESPs have
>> 5.7.1. listed as a "hard bounce" in their documentation. That seems wrong.
>>
>> Of course you will need to address the actual block/policy issue, so
>> these bounces are important to monitor. But the bounce code shouldn't
>> affect the recipients "status" in any email system, which is what a "hard
>> bounce" would do.
>>
>> My conclusion is that these types of bounces should have no bearing on
>> the recipient's "status", and they shouldn't be classified as "hard" or
>> "soft", but rather ignored.  Has anyone else come to a different conclusion?
>>
>> Thanks,
>> Alex
>>
>>
>> Alex Burch
>> ActiveCampaign / Deliverability Lead
>> (800) 357-0402
>> abu...@activecampaign.com
>> 1 N. Dearborn St., Chicago , Il 60602, United States
>> 
>> 
>> 
>> ___
>> 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
> http://www.aliverson.com
> http://www.spamresource.com
>
> ___
> mailop mailing list
> 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

[mailop] Different From domain and Reply-To domain

[David Hofstee]

Hi,

Can people here share their experience (or spamfilter configuration) with
differing 5322.From and 5322.Reply-To domains in larger volumes of
email? Is it a problem, if so, where? If it is a problem, are there
requirements so that legitimate email is accepted?

Any info and opinions on this is appreciated. Obviously, my customer is
owner of the two domains. His customer care is done by a holding company.
One can say there is a legitimate reason. I'm just looking if this is a
possible cause of problems, or not.

Yours,


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

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

[David Hofstee]

Maybe this... https://twitter.com/certbund/status/933674851092566017


David

On 24 November 2017 at 04:31, Shane Clay via mailop 
wrote:

> Hi All
>
>
>
> I can’t figure this one out so looking for some help from people in the
> know. One of our clients has a postfix mail relay server used for relaying
> emails from photocopiers/internal software systems out to the world.
>
>
>
> Below I’ve pasted the headers of one. Office 365 / Outlook chucks them in
> the junk mail folder with a message “This sender failed our fraud detection
> checks and may not be who they appear to be.”
>
>
>
> From what I can see, the email is matches SPF and is passing SPF/DMARC
> checks. I can’t understand what it is seeing as wrong.
>
>
>
> Any ideas?
>
>
>
> Shane
>
>
>
>
>
>
>
>
>
>
>
> Received: from SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) by
>
> SY3PR01MB1145.ausprd01.prod.outlook.com (10.171.0.11) with Microsoft SMTP
>
> Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
> id
>
> 15.20.239.5 via Mailbox Transport; Fri, 24 Nov 2017 03:23:28 +
>
> Received: from ME1PR01CA0132.ausprd01.prod.outlook.com (10.171.9.145) by
>
> SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) with Microsoft
> SMTP
>
> Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
> id
>
> 15.20.260.4; Fri, 24 Nov 2017 03:23:27 +
>
> Received: from ME1AUS01FT014.eop-AUS01.prod.protection.outlook.com
>
> (2a01:111:f400:7eb4::204) by ME1PR01CA0132.outlook.office365.com
>
> (2603:10c6:200:1b::17) with Microsoft SMTP Server (version=TLS1_2,
>
> cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.260.4 via Frontend
>
> Transport; Fri, 24 Nov 2017 03:23:27 +
>
> Received: from mail.stcolumba.sa.edu.au (103.219.120.34) by
>
> ME1AUS01FT014.mail.protection.outlook.com (10.152.232.114) with Microsoft
>
> SMTP Server id 15.20.178.5 via Frontend Transport; Fri, 24 Nov 2017
> 03:23:26
>
> +
>
> Received: from KM269386 (unknown [10.102.10.54])
>
> by mail.stcolumba.sa.edu.au (Postfix) with ESMTP id
> 95A4BC0BAE24
>
> for ; Fri, 24 Nov
> 2017 13:53:14 +1030 (ACDT)
>
> From: Simon Flaherty 
>
> To: Simon Flaherty 
>
> Subject:
>
> Thread-Index: AQHTZNOYCcOVafuWzkOoKK7iRk6SuQ==
>
> Date: Fri, 24 Nov 2017 03:32:02 +
>
> Message-ID: <20171124140202000ab70f.simon.flahe...@stcolumba.sa.edu.au>
>
> Content-Language: en-AU
>
> X-MS-Exchange-Organization-AuthSource: ME1AUS01FT014.eop-AUS01.prod.
> protection.outlook.com
>
> X-MS-Has-Attach: yes
>
> X-MS-Exchange-Organization-Network-Message-Id: 7b477dc8-ad88-4e86-092d-
> 08d532eab9f3
>
> X-MS-TNEF-Correlator:
>
> *received-spf: Pass (protection.outlook.com
> : domain of stcolumba.sa.edu.au
> *
>
> *designates 103.219.120.34 as permitted sender)*
>
> *receiver=protection.outlook.com ;
> client-ip=103.219.120.34;*
>
> *helo=mail.stcolumba.sa.edu.au ;*
>
> x-ms-publictraffictype: Email
>
> authentication-results: spf=pass (sender IP is 103.219.120.34)
>
> smtp.mailfrom=stcolumba.sa.edu.au; stcolumba.sa.edu.au; dkim=none (message
>
> not signed) header.d=none;stcolumba.sa.edu.au; *dmarc=pass* action=none
>
> header.from=stcolumba.sa.edu.au;compauth=pass reason=100
>
> x-microsoft-exchange-diagnostics: 1;SYXPR01MB1151;7:
> DnxrWG6h0x38Y2EwYd7DEFPIAttOlbuTEZYmD/+ZbnoP0Fl74xE8fI/
> MVEs1qvQPqsa2Gvgs6tN2+Gc0i1fgde8YkGz0CLD+BAXOUzvG4VzNhuJXVPMKQMR9PyXZ4V
> KaCv+PjtDvevqdEb+5BmGQK1fDvhcktBv0nzYWNxT+LoIAP/
> 4KQejWFVfF13wo9rRSzHjK6U9nqcx6+98hdB6lUv33MRcZFfaTxUDk56lukHj
> h6kFqcnM6vd2W6bCpINFnqR2QsI7KnIvm9am8YJ2X6g67gbITzvKHyyC2x/fRZ8s=
>
> x-forefront-antispam-report: CIP:103.219.120.34;IPV:NLI;
> CTRY:;EFV:NLI;SFV:SPM;SFS:(6009001)(8046002)(298032)(
> 438002)(189002)(199003)(2876002)(25636003)(305945005)(
> 567704001)(620011)(84326002)(5406001)(2171002)(
> 6266002)(589011)(81156014)(81166006)(74482002)(2351001)(
> 86152003)(14003)(42882006)(6916009)(101346004)(2148043)(003)(
> 566031)(5416004)(1076002)(63106013)(106002)(77096006)(
> 50986999)(500011)(568964002)(106466001)(54356999)(564344004)(
> 104016004)(356003)(37006003)(512874002)(2476003)(1096003)(
> 287071)(88552002)(86362001)(462011)(189998001)(429038);DIR:
> INB;SFP:;SCL:5;SRVR:SYXPR01MB1151;H:mail.stcolumba.sa.edu.au;FPR:;SPF:
> Pass;PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
> ;MX:1;A:1;CAT:SPM;LANG:en;SFTY:9.11;
>
> x-ms-office365-filtering-correlation-id: 7b477dc8-ad88-4e86-092d-
> 08d532eab9f3
>
> x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(49563074)(
> 121220049038)(71702078);SRVR:SYXPR01MB1151;
>
> x-ms-traffictypediagnostic: SYXPR01MB1151:
>
> x-ms-exchange-transport-endtoendlatency: 00:00:02.2240358
>
> 

Re: [mailop] Does JMRP send everything? (Was: Re: Hotmail, green SNDS and junk folder placement)

[David Hofstee]

Hi Michael,

I recently wrote:
> My question would be: If Microsoft does not want all complaining
recipients removed / listwashed, which I can understand, why not provide
anonymous feedback on bad senders? Provide similar info like Google is
providing (with the Feedback-ID or sender domain). Why then provide FBL at
all?

My current remark would be that it is beneficial for us to have a decent
example set of people who complain. It makes it easier to confront the
customer and locate the source of problems. I think 1:5 to 1:20 should be
sufficient for that purpose (depending on the volume of that sender
domain). .

I also think that anonymous feedback is still a good idea. Maybe only for
authenticated emails (with aligned SPF/DKIM)? Gives ESPs a reason to (force
customers to) authenticate in line with DMARC.

Yours,



David


On 21 November 2017 at 09:25, Benjamin BILLON via mailop 
wrote:

> Hi all,
>
> I come to confirm the interest of the community in this question (was:
> "Does JMRP provide all or almost all the complaints through FBL as
> disclosed in the Live Postmaster page?").
>
> @Michael> we understand this topic could be out of your direct scope and
> we deeply appreciate every efforts you do to put the case on the right desk.
> I'm discussing (through tickets) with the SNDS Support these days, and we
> see discrepancy on Complaints numbers between what we receive from SNDS,
> what Microsoft sees internally, and the FBL we receive (respectively 29, 1
> and 3, for a given IP in a given time range).
> The other weirdness is that with these (objectively low) numbers, the
> messages get a BCL of 8.
>
> Also, I'm sure that any sender participating in this mailing-list would
> gladly provide his help and data if it can help anyone at Microsoft, so let
> us know!
>
> Cheers,
> --
> 
> Benjamin
>
> 2017-11-03 5:05 GMT+08:00 Luis E. Muñoz :
>
>>
>>
>> On 2 Nov 2017, at 12:24, Michael Wise via mailop wrote:
>>
>> Apologies for the delay.
>>
>> No apologies required. Instead, thank you again for your assistance!
>>
>> -lem
>>
>
>
> ___
> mailop mailing list
> 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] Outlook says "mail accepted for delivery" but it never shows up

[David Hofstee]

Hi Andrew,

But in your case you may have some differing "ip reputation" to account
for. For me the only difference was the html layout. Nothing else was
changed.

I have to say this was years ago. I generally do not spend so much time on
a single message.

Yours,


David

On 22 November 2017 at 17:03, Andrew Wingle <awin...@listrak.com> wrote:

> Hi David,
>
>
>
> I can attest to the same issue and the replication of the issue. We have
> found some scenarios where the same email will deliver to specific domain
> on one IP and not of the other. I cannot say that we have seen a different
> result by “cleaning” the HTML up. Seems that the blackholing has increased
> significantly over the past few weeks if other metrics are indeed
> indicative of this problem.
>
>
>
> e.g.
>
> This is for the same exact message. Nothing about the messages are
> changed. Messages are DKIM signed and have SPF-passing. IPs are given to
> show an example only.
>
>
>
> recipient domain  sender IP result
>
> x...@hotmail.com142.0.83.00 accepted and delivered
>
> a...@outlook.com   142.0.83.00 accepted but never found
> (blackholed)
>
>
>
> recipient domain  sender IP result
>
> x...@hotmail.com142.0.83.01 accepted but never found
> (blackholed)
>
> a...@outlook.com   142.0.83.01 accepted and delivered
>
>
>
> For the message that is received in the mailbox there is nothing unique
> about the header results to give way to what may have happened to the other
> recipient’s message.
>
>
>
> Regards,
>
> Andrew
>
>
>
>
>
> *ANDREW D. WINGLE*
>
>
>
> 717-625-7857 <(717)%20625-7857> direct
>
> 
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *David
> Hofstee
> *Sent:* Wednesday, November 22, 2017 10:40 AM
> *To:* mailop <mailop@mailop.org>
> *Subject:* Re: [mailop] Outlook says "mail accepted for delivery" but it
> never shows up
>
>
>
> Hi Klaus,
>
>
>
> No, actually it was perfectly repeatable. We couldn't believe it either.
> Since this was a notification email of the ESP application we really wanted
> to know why it was dropped by Microsoft so we rinsed and repeated...
>
>
>
>
>
>
>
> David
>
>
>
> On 22 November 2017 at 10:42, Klaus Ethgen <klaus+mai...@ethgen.de> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> Am Mi den 22. Nov 2017 um 10:21 schrieb David Hofstee:
> > It certainly could also have to do with the html content formatting. I
> have
> > seen that a cleaner html layout suddenly allowed my email.
>
> Well, that is just a random coincident. I have even plain text mails
> dropped by microsoft.
>
> Regards
>Klaus
> - --
> Klaus Ethgen   http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen <kl...@ethgen.ch>
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
>
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloVRoYACgkQpnwKsYAZ
> 9qyEJQv8Ddn+dXzEI/ALtf1MGTu8DqavikaOiBo7fP4jhU9RFdmRRqTJ9nfPo9eU
> LYcnHnk32KIkUJ//RgmhbzvQfLfmoI8gjLublMdiGUZvrsGIPbHDIrhSVzh0XMOe
> wGl9gXK7Pqf8rh+EHBwKT14Lxf6do4PNGFiP8YDC8VNR2vjW0x3IOhEQmIE/NJgM
> 6RaE5cDv8h5PPmNKwdLxw7v5N1ZHHSw1yuOHZ3fP5Ck6gRpqcqUk8MVoINPvidf9
> ugYDSUJgBSCgZ3Jv4WhZ/4YvwaGIWAPefDhfBsmCcyj5bqr/C3074rPHbmsenttJ
> cXGTgRQT52vBGe0WQIf5rUmA1DEHDXyDwtQDKINUoE4VfoSDvyyIs049U4Nes7UY
> SXRjKM8UdnHmK5cbeBqRHBRXehFsRWq0rJ6uVaChtA1XVnJGmUwv18YebNwgVllS
> c/0w2bV5voPgTzpgWhA+xGnyud4ogSQ41zVMDT6MEZH7n/DeZQcKpZfZZ8YF6cmI
> hnQH6fWj
> =6qLG
> -END PGP SIGNATURE-
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
>
> --
>
> --
>
> My opinion is mine.
>



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

Re: [mailop] Outlook says "mail accepted for delivery" but it never shows up

[David Hofstee]

Hi Klaus,

No, actually it was perfectly repeatable. We couldn't believe it either.
Since this was a notification email of the ESP application we really wanted
to know why it was dropped by Microsoft so we rinsed and repeated...



David

On 22 November 2017 at 10:42, Klaus Ethgen <klaus+mai...@ethgen.de> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> Am Mi den 22. Nov 2017 um 10:21 schrieb David Hofstee:
> > It certainly could also have to do with the html content formatting. I
> have
> > seen that a cleaner html layout suddenly allowed my email.
>
> Well, that is just a random coincident. I have even plain text mails
> dropped by microsoft.
>
> Regards
>Klaus
> - --
> Klaus Ethgen   http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen <kl...@ethgen.ch>
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
>
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloVRoYACgkQpnwKsYAZ
> 9qyEJQv8Ddn+dXzEI/ALtf1MGTu8DqavikaOiBo7fP4jhU9RFdmRRqTJ9nfPo9eU
> LYcnHnk32KIkUJ//RgmhbzvQfLfmoI8gjLublMdiGUZvrsGIPbHDIrhSVzh0XMOe
> wGl9gXK7Pqf8rh+EHBwKT14Lxf6do4PNGFiP8YDC8VNR2vjW0x3IOhEQmIE/NJgM
> 6RaE5cDv8h5PPmNKwdLxw7v5N1ZHHSw1yuOHZ3fP5Ck6gRpqcqUk8MVoINPvidf9
> ugYDSUJgBSCgZ3Jv4WhZ/4YvwaGIWAPefDhfBsmCcyj5bqr/C3074rPHbmsenttJ
> cXGTgRQT52vBGe0WQIf5rUmA1DEHDXyDwtQDKINUoE4VfoSDvyyIs049U4Nes7UY
> SXRjKM8UdnHmK5cbeBqRHBRXehFsRWq0rJ6uVaChtA1XVnJGmUwv18YebNwgVllS
> c/0w2bV5voPgTzpgWhA+xGnyud4ogSQ41zVMDT6MEZH7n/DeZQcKpZfZZ8YF6cmI
> hnQH6fWj
> =6qLG
> -END PGP SIGNATURE-
>
> ___
> mailop mailing list
> 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] Outlook says "mail accepted for delivery" but it never shows up

[David Hofstee]

Hi Mathieu,

It certainly could also have to do with the html content formatting. I have
seen that a cleaner html layout suddenly allowed my email. Same IP, same
sender, same text, same layout, different html. That made the difference
between dropping the email and letting it through at Microsoft.

Yours,


David

On 21 November 2017 at 14:07, Mathieu Marnat  wrote:

> This is indeed the issue : everything is set up correctly.
>
> SNDS has a "View IP Status" page that is supposed to tell you when there
> is a block, there are also SMTP replies for that. Instead, Outlook just
> replies "accepted for delivery" when it is in fact blocked.
>
> What is even more curious about this is that some of the IPs blocked are
> green on SNDS, and they accepted to lift the block. So, was the block
> legitimate in the first place ? I tend to doubt it.
>
>
> Mathieu.
>
>
> ___
> mailop mailing list
> 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] Random question about complaints

[David Hofstee]

Have seen this too. Our CEO triggered an FBL from Microsoft. The email was
sent from our corporate mail server... He kept wondering why he would no
longer be able to forward anything to his hotmail account. That was fun.


David

On 15 November 2017 at 19:45, Nick Schafer  wrote:

> Thanks all! Very helpful and inline with what I was thinking!
>
> Nick Schafer
> Technical Account Manager, Mailgun 
> Add me on LinkedIn
> 
>
> On Wed, Nov 15, 2017 at 12:27 PM, Ken O'Driscoll 
> wrote:
>
>> On Wed, 2017-11-15 at 11:56 -0600, Nick Schafer wrote:
>> > My question is, is there anything that could inadvertently trigger a
>> spam
>> > complaint for a recipient without their knowing? My hunch is some sort
>> of
>> > mailbox add on or something to that extent but wanted to hear others
>> > thoughts.
>> >
>> > Of course, the recipient may have accidentally clicked "spam" or "junk"
>> > and they just forgot :)
>>
>> Some users hit "spam" when they want to unsubscribe, others when they want
>> to move a mail out of their inbox.
>>
>> Some users also consider their trash folder to be a valid place for
>> storing
>> previous correspondence.
>>
>> The user in question could also have created an automatic filter that
>> matched a particular key word and marked those emails as spam.
>>
>> Bottom line is that you don't know what they're doing, how they use email
>> or how a mailbox provider will treat some of their actions (particularly
>> automated ones).
>>
>> Occasional false positives are part of the course.
>>
>> 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
>
>


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

Re: [mailop] A proposal for automated management of mail sending limits

[David Hofstee]

Hi Ken,

The part after the snippet, is where I explain why I said that.

Only in recent years has PowerMTA 4.5 added some more granular options,
maybe after me complaining about it. It used to be per (set of) domains
only (and the added routing). I looked at the 4.5 features and I still
presume this falls short. I don't know if you have seen how Message
Systems' "Adaptive Delivery" works? It only works for about 75 ISPs and
only for fixed domains (barely adequate in my opinion). Not sure what Green
Arrow can do.

The problem I see is that it requires extensive tuning. Small shops don't
do that because they lack expertise, data and time. If we want email to
remain accessible, we should remove this obstacle.

Yours,


David

On 14 November 2017 at 16:24, Ken O'Driscoll <k...@wemonitoremail.com> wrote:

> On Tue, 2017-11-14 at 10:05 +0100, David Hofstee wrote:
> > I agree that it is a problem. I do think this could be done at connection
> > time only. Of of the tricky parts is that all mail servers I know have
> > trouble with throttling.
> [...snip...]
>
> Traditional MTAs often respond by queuing and re-trying. That works for
> small delays, such as "Server Busy - Try Later" but doesn't really scale
> for the throttling experienced during bulk sending. You can use multiple
> queues but that only results in email often being delayed unnecessarily.
>
> However, Specialist MTA designed for bulk sending, such as GreenArrow or
> PowerMTA can be configured to control mail flow on a very granular level on
> a per provider, IP, MX etc. basis. They also support dynamically changing
> mail flow in response to throttling.
>
> So legitimate bulk emails sent though a specialist MTA aren't typically
> unduly hindered by pre-acceptance throttling etc.
>
> But I do think that this issue isn't as much an engineering problem as a
> communications one.
>
> 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
>



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

Re: [mailop] A proposal for automated management of mail sending limits

[David Hofstee]

Hi Ken,

I agree that it is a problem. I do think this could be done at connection
time only. Of of the tricky parts is that all mail servers I know have
trouble with throttling. They can throttle on a (set of) recipient
domain(s), but not on a cluster of MXs from e.g. Microsoft. E.g. they put
hotmail, outlook, msn in one queue but forget to put email from businesses
that use Office365 in the same queue. In order to fix that more easily, the
mail server should disclose an identifyer where the volume should be
counted under. In that way a server could know when a new connection/domain
is part of that throttling (and shut that connection down if necessary).

e.g.
250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps [QUIT here if you
realize it would violate the throttling quota]
250-THROTTLING-CONNECTIONS 10
250-THROTTLING-EMAILS-CONNECTION 20
250-THROTTLING-RATE-MINUTE 20
250-THROTTLING-RATE-HOUR 200
250-THROTTLING-RATE-DAY 500
250-THROTTLING-DATASIZE-CONNECTION 100MB

or
250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps
250-THROTTLING-GRAYLISTING-MINUTE 120

It would then be up to the MTA to group all these domains under that
identifier and abide to the throttling requirements. One thing is that
these throttling parameters must be adjustable in the same connection (so
they can react to emails you send).

Yours,


David



On 13 November 2017 at 20:41, Ken O'Driscoll  wrote:

> On Mon, 2017-11-13 at 09:58 -0800, Steve Atkins wrote:
> > (If this proposal were coming out of a group of major ISPs or a few of
> > the larger inbound mail appliance or service providers as "this is
> > something we want to do" I'd consider it differently than it coming from
> > the high volume email deployer side of things. There's a long history of
> > bulk mail senders going "just tell us exactly what we need to do so
> > you'll deliver our email, and we'll do it!" and it's not something that
> > ever really leads anywhere.)
>
> I understand this sentiment but I believe these days the only reason that
> most of them want to know "what the rules are" is because they want to
> comply but it's often not evident how.
>
> The quality (and existence) of postmaster portals and knowledge bases
> varies greatly. The informative value of SMTP error messages varies
> greatly. The ability to communicate with a postmaster varies greatly.
>
> You can't really blame them (particularly the smaller ones) for sometimes
> being confused about what's needed to get their transactional or opt-in
> email into inboxes.
>
> 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
>



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

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

Hi Alexander,

>  Size of message: I'm not sure how we should handle this. The sender/ESP
did send out a correct message, but Google decided to cut off content.
Who's to blame?
The sender. He knows that by sending to Gmail, it will be cut off. Or he
should now.  He could add the unsubscribe button at the top as an
alternative (but does not). Anyway, in effect there is no unsubscribe link.
Would you allow an unsubscribe link in white text on a white background?
Very light gray on white? Your rules should reflect that too.

>  That's why not every complaint gets feedback but is still used and
highly appreciated.
Well, maybe I expected something differently. E.g. a reply the next
business day (as a means to say that matters are looked into and how they
are dealt with). Because "no reply" means, in my book, that nothing
happened (call it "industry standard"). It certainly does not motivate
people to complain if you don't respond.

So I don't think that being a CSA member is "bad". But I don't see the
"good" or "exceptional" as part of your plan to make the deliverability
landscape a better place. Just some compromise by committee. And in
practice, some say your header is already a small spam indicator. The CSA
seems to lag and not lead. I would really like it to be the opposite
(otherwise I would not take time to respond).

Yours,


David

On 2 November 2017 at 13:59, Alexander Zeh <alexander@eco.de> wrote:

> Hello David,
>
> thanks for the welcome. :)
> About your questions:
>
> - Complaint policy: We distinct between two different types of complaints.
> First we have what we call a "spam click". That's basically FBL data. These
> are completely anonymous of course. We simply see "spam click rates" and
> act if the rate of spam clicks in comparison to the number of emails
> received exceeds a certain threshold.
> The other kind of complaints are individual user complaints. This is a
> whole different topic, because if someone tells us "Hey, I just received an
> email from someone I never gave my consent to" that's way more serious than
> a simple click in a webinterface from my ISP which can happen by accident.
> But in these cases, there are still "false positives", like people who
> forgot that they subscribed, people who received kind of embarrassing
> content, like the newsletter from a dating site, and get caught by somebody
> who shouldn't know it. So the complaint team checks these complaints and
> works with the complainant and the ESP (who did send the email in behalf of
> e.g. the dating site) to find out the exact cause of the problem so it can
> be fixed. Most of the time, if there is a real issue with the opt-in
> process of a sender the complaint team receives multiple complaints for the
> same sender in a short period of time. That's why not every complaint gets
> feedback but is still used and highly appreciated.
> Anyway.. as we operate in Germany and take data protection very serious we
> ask the complainant for explicit consent to allow us to share his personal
> information (his email address) with the ESP who sent the email to work on
> the issue. So from a process perspective and a legal perspective, these
> individual user complaints can't be handled anonymously.
>
> -Oversight: Yes, of course. We have people and tools who check that. But
> of course we never see the full picture of each and every single email sent
> by every certified sender. Hints from receivers are also highly appreciated.
>
> -Unsubscribing:
> - Size of message: I'm not sure how we should handle this. The sender/ESP
> did send out a correct message, but Google decided to cut off content.
> Who's to blame?
> - List-Unsubscribe: Of course we check every ESP in the certification
> process. But we can't check and monitor every single sent message. This
> goes back to the "Oversight" question. If we see this in our monitoring, or
> if we get the hint by a receiver we can work on that. I'd like to contact
> you off-list about the samples you showed, so we can take actions against
> the responsible sender.
>
> - Leadership: As you can see by Tobias reaction, the opinions around
> authentication differ. To make that clear: The CSA criteria are not made up
> by me and my colleagues, nor are they based on opinions. They are the
> results of the different needs and requirements by all participating ISPs
> and technology partners. We gather all the feedback, try to find the best
> possible solution and discuss them with our partners, again. Finally every
> change made to the admission criteria need to be approved by the CSA
> committee, who I mentioned early consists of two ISP partners and two ESPs.
> Right now SPF and DKIM are mandatory for CSA sende

Re: [mailop] mail.ru google and DMARC

[David Hofstee]

> And where the heck does mail.ru publish it's DMARC policy via DNS?

dig txt _dmarc.mail.ru



David

On 2 November 2017 at 13:28, Benoit Panizzon  wrote:

> Dear List
>
> I have come across a strange problem.
>
> One of our customers is forwarding his emails to his google account.
>
> We do implement SRS to rewrite the envelope sender to match our SPF
> record.
> All other headers are preserved, in case they are DKIM Signed.
>
> Google rejects the emails with:
>
> : host
> gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
> Unauthenticated email from mail.ru is not accepted due to domain's
> 550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
> domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
> https://support.google.com/mail/answer/2451690 to learn about the
> 550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
> of DATA command)
>
> Ok I have not yet stumbled over a lot of email senders using DMARC. So
> I read on: https://en.wikipedia.org/wiki/DMARC
>
> Did I get that right? DMARC checks that the envelope-from and From:
> header are 'aligned'?
>
> Well how the hell should that work when an email is being forwarded?
>
> SPF requires that I rewrite the envelope sender, DKIM requires that I
> don't alter the signed From: Header, DMARC requires that I do alter the
> From: Header?
>
> And where the heck does mail.ru publish it's DMARC policy via DNS?
>
> mail.ru has address 217.69.139.201
> mail.ru has address 94.100.180.201
> mail.ru has address 217.69.139.200
> mail.ru has address 94.100.180.200
> mail.ru name server ns3.mail.ru.
> mail.ru name server ns1.mail.ru.
> mail.ru name server ns2.mail.ru.
> mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
> 900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
> mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
> mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1
>
> _spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
> ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
> ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
> ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
> ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
> ip4:5.61.239.144/32 ~all"
>
> Well his somehow looks like a broken SPF record. Anyway ~all would
> specify softfail and not reject.
>
> Can anyone help putting the puzzle together?
>
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?
>
> And yes I know, email forwarding is considered bad(tm), but it is still
> widely used.
>
> -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
>



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

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

Hi Tobias,

> I'm working for an ESP who is member of the CSA and ECO and I'm one of
the biggest contender on the authentication requirements front, I don't
think that DMARC is an ESP responsibility, but think that an ESP should
provide everything necessary so that a Brand can use DMARC.
So you agree with me? Good.

> By forcing the ESP community of CSA to implement DMARC we would not help
our customers, we would simply give them a false feeling of having done
something, that does not solves the underlying problem.
I did not say DMARC. I said DMARC-type authentication (SPF and DKIM aligned
to sender domain). I specifically made that distinction because I agree
that requiring (a) DMARC (policy) is not our job.

That said: As an ESP you are not required to support DKIM and SPF aligned
to the sender domain according to the CSA. Therefore an ESP could become a
member and their customers may not be able to follow the advise to
implement DMARC (as given in the guidelines, paragraph 3.10).

Yours,


David

On 2 November 2017 at 13:00, Tobias Herkula <tobias.herk...@optivo.com>
wrote:

> I'm working for an ESP who is member of the CSA and ECO and I'm one of the
> biggest contender on the authentication requirements front, I don't think
> that DMARC is an ESP responsibility, but think that an ESP should provide
> everything necessary so that a Brand can use DMARC. By forcing the ESP
> community of CSA to implement DMARC we would not help our customers, we
> would simply give them a false feeling of having done something, that does
> not solves the underlying problem.
>
> Kind regards,
>
> Tobias Herkula
> --
> optivo GmbH
> Product Management (Infrastructure)
> 
> From: mailop <mailop-boun...@mailop.org> on behalf of David Hofstee <
> opentext.dhofs...@gmail.com>
> Sent: Thursday, November 2, 2017 11:19
> To: Alexander Zeh
> Cc: mailop@mailop.org
> Subject: Re: [mailop] About the Certified Senders Alliance
>
> Hi Alexander,
>
> Welcome to Mailop. A few somewhat criticising questions on the CSA:
> - Complaint policy: What is the complaint policy for recipients? I tried
> to find it, but could not. Is anonymity guaranteed? Also not available in
> the data protection policy as found on the website. Please consider
> creating one.
> - Oversight: Do you have a group of people that monitor compliance of
> senders (and not just complaints)?
> - Unsubscribing. I subscribed to a few newsletters but I seem to notice a
> high "does not follow policy"-rate. Two examples (of 3 subscriptions,
> headers provided below):
>  - Size of message: Google clips large messages. This is often where
> the unsubscribe link is. I did not see an unsubscribe link in this message.
>  - List-Unsubscribe: Missing the required URL (requirement 2.21 of
> your admission criteria, see https://certified-senders.org/
> wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf ). Were these not
> tested at admission?
> - Leadership: I think the authentication requirements in your policy are
> outdated. An ESP does not even need to support DMARC-type authentication
> nor is it a requirement for its customers to prove they are the real
> senders. Do you agree? Do you think the CSA should lead in setting
> requirements on these topics? Is the CSA able to change such requirements?
> Or is the CSA afraid of the current customer base (who might protest to
> adding authentication)? I would like to hear CSA's opinion on that.
>
> Yours,
>
>
> David
>
> Example of message too large; the unsubscribe link is no longer visible in
> Gmail:
> X-CSA-Complaints: whitelist-complai...@eco.de<mailto:whitelist-complaints@
> eco.de>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="msg_border_bwvx"
> Date: Thu, 14 Sep 2017 22:01:07 -0700
> To: xyz
> From: HSE24 TV Programm <newslet...@angebote.hse24.de newslet...@angebote.hse24.de>>
> Reply-To: HSE24 TV Programm <serv...@hse24.de<mailto:serv...@hse24.de>>
> Subject: Hui...jetzt wird's richtig stylisch
>
> Example of List-Unsubscribe not having URL:
> Date: Wed, 25 Oct 2017 15:01:33 + (GMT)
> From: TUI <t...@email.tui.nl<mailto:t...@email.tui.nl>>
> Reply-To: t...@email.tui.nl<mailto:t...@email.tui.nl>
> To: xyz
> Message-ID: <43699742.JavaMail.app@rbg62.f2is>
> Subject: Welkom bij TUI
> MIME-Version: 1.0
> Content-Type: multipart/alternative; boundary="=_Part_334583_
> 459599753.150234563453456"
> x-mid: 2369485
> X-CSA-Complaints: whitelist-complai...@eco.de<mailto:whitelist-complaints@
> eco.de>
> x-rpcampaign: sp2375598
> Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
> x-job: 23755

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

Hi Alexander,

Welcome to Mailop. A few somewhat criticising questions on the CSA:
- Complaint policy: What is the complaint policy for recipients? I tried to
find it, but could not. Is anonymity guaranteed? Also not available in the
data protection policy as found on the website. Please consider creating
one.
- Oversight: Do you have a group of people that monitor compliance of
senders (and not just complaints)?
- Unsubscribing. I subscribed to a few newsletters but I seem to notice a
high "does not follow policy"-rate. Two examples (of 3 subscriptions,
headers provided below):
 - Size of message: Google clips large messages. This is often where
the unsubscribe link is. I did not see an unsubscribe link in this message.

 - List-Unsubscribe: Missing the required URL (requirement 2.21 of your
admission criteria, see
https://certified-senders.org/wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf
). Were these not tested at admission?
- Leadership: I think the authentication requirements in your policy are
outdated. An ESP does not even need to support DMARC-type
authentication nor is it a requirement for its customers to prove they are
the real senders. Do you agree? Do you think the CSA should lead in setting
requirements on these topics? Is the CSA able to change such requirements?
Or is the CSA afraid of the current customer base (who might protest to
adding authentication)? I would like to hear CSA's opinion on that.

Yours,


David

Example of message too large; the unsubscribe link is no longer visible in
Gmail:
X-CSA-Complaints: whitelist-complai...@eco.de
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="msg_border_bwvx"
Date: Thu, 14 Sep 2017 22:01:07 -0700
To: xyz
From: HSE24 TV Programm 
Reply-To: HSE24 TV Programm 
Subject: Hui...jetzt wird's richtig stylisch

Example of List-Unsubscribe not having URL:
Date: Wed, 25 Oct 2017 15:01:33 + (GMT)
From: TUI 
Reply-To: t...@email.tui.nl
To: xyz
Message-ID: <43699742.JavaMail.app@rbg62.f2is>
Subject: Welkom bij TUI
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_Part_334583_459599753.150234563453456"
x-mid: 2369485
X-CSA-Complaints: whitelist-complai...@eco.de
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 


On 1 November 2017 at 17:33, Alexander Zeh  wrote:

> Hello everyone,
>
> a friend informed me about a topic going on about the Certified Senders
> Alliance on this mailing list. That’s why I joined it.
> I work for the CSA for many years now.
> First and foremost of all:
> It is definitely not true that a sender can join the CSA without any
> vetting. That statement bothered me a lot, because it’s a plain lie. Maybe
> because important information was lost in some communication between more
> than two parties, I don’t want to assume ill intent by anybody. In fact
> from every sender who wants to get certified and be whitelisted only about
> 10% make it through the whole process and are approved. Btw: the
> certification needs to be confirmed by the certification committee in which
> 2 seats out of 4 are major ISP partners.
> I totally agree that if you have delivery issues it shouldn’t be the first
> step to reach out any certification program to fix it. And this is not how
> CSA works. If a sender has delivery issues, in 99% these problems are
> justified and self made. So what the CSA does is, that in the process we
> find potential issues and help senders to align with current best practices
> aka. the CSA admission criteria.  This whole process can take weeks and
> months and still many senders don’t achieve a certification in the end,
> because we take that very serious.
> Anybody on this mailing list, please feel free to have a look at our
> criteria and see for yourself if they are reasonable or not. As everything
> we do is completely transparent, you can find them on
> https://certified-senders.org/library either at the end, or you can
> select the type “CSA specific” to filter.
>
> Sorry about this rant-ish post, but we try our best to improve overall
> quality of senders, so the initial post kind of annoyed me.
>
> Anyway. I am open for discussion either here, direct with me or for
> example on the next M3AAWG meeting in person.
>
> Best
> Alex
>
> --
>
> Best regards
>
>
> Alexander Zeh
>
>
> Engineering Manager
>
>
> ---
>
>
> eco - Association of the Internet Industry
>
> Certified Senders Alliance
>
>
> Lichtstrasse 43h
>
> 50825 Cologne
>
> Germany
>
>
> phone: +49 (0) 221 - 70 00 48 - 171 <+49%20221%20700048171>
>
> fax: +49 (0) 221 - 70 00 48 - 111 <+49%20221%20700048111>
>
> mobile: +49 (0) 171 - 657 2628 <+49%20171%206572628>
>
> e-mail: alexander@eco.de
>
> web: 

Re: [mailop] Certified Senders Alliance

[David Hofstee]

The rules they offer are "normal" for an ESP. I have complained personally,
a couple of times (to the address they make you add in the headers). Did
not get any response on that (repeatedly).

Microsoft and Yahoo are partners of the CSA. Terry posted something on
it but I can't remember what they do with that membership. Personally the
only value I see is an open communication channel for senders/receivers if
something goes wrong. At least that is what I would expect.

Yours,


David

On 1 November 2017 at 16:26, Steve Atkins  wrote:

>
> > On Nov 1, 2017, at 6:28 AM, Alexander Burch 
> wrote:
> >
> > What is the general opinion of the Certified Senders Alliance? Does
> anyone find it impactful for delivery? They offered to let us join without
> any vetting, just sent us a bill for $___ without any questions. If there
> is no vetting process I have a hard time seeing how it would validate any
> sender as trustworthy.
>
> The advice they offer is good, and if you follow it it will likely improve
> your delivery[1], regardless of whether you pay them or are added to their
> whitelist. Just like the other certification programs.
>
> If your mail is marginal / borderline enough that it's getting blocked,
> but also marginal / borderline enough that it's stats aren't so bad and you
> can contact the ISP to have them have a postmaster put eyeballs on your
> mailstream, and they're an ISP that uses CSA data, then your being listed
> there might, if the stats are otherwise 50/50, persuade the postmaster to
> give you the benefit of the doubt.
>
> e.g. https://blogs.msdn.microsoft.com/tzink/2017/07/06/how-we-
> use-the-certified-senders-alliance-ip-reputation-list/
>
> There are lots of other things you can do to signal the virtue of your
> policies and procedures, and buying your way into certification should be
> nearer the end of that list than the beginning.
>
> Cheers,
>   Steve
>
> [1] You can get advice just as good, and sometimes better, from places
> that aren't asking you to buy your way into a certification program.
>
> --
> -- Steve Atkins -- https://wordtothewise.com/
> ___
> mailop mailing list
> 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] Hotmail, green SNDS and junk folder placement

[David Hofstee]

This is also news to me. Wow. I also wondered why Yahoo recipients seemed
so picky but I didn't draw the right conclusion (that recipients are the
same everywhere and something was wrong with the MS metrics).

My question would be: If Microsoft does not want all complaining recipients
removed / listwashed, which I can understand, why not provide anonymous
feedback on bad senders? Provide similar info like Google is providing
(with the Feedback-ID or sender domain). Why then provide FBL at all?

A second question is: What does the 0.3% spam rate limit, as described in
the SNDS FAQ, mean. Given this information that is. Should we multiply our
FBL rates with a number (6?) to get that 0.3%?

Yours,


David

On 30 October 2017 at 01:26, Benjamin BILLON via mailop 
wrote:

> Hi Bill,
>
> Although we try to rationalize as much as possible, I believe most ESPs
> are aware that each ISP is different (if some ESPs aren't aware of that
> they should look at the SMTP replies), there's not one single universal
> metric. There are plenty of metrics, and of course different for ISP. But
> when one of the metrics is totally off chart, or not interpreted as it's
> supposed to do, well, that's never good. Metrics aren't truth, they're just
> indicators that we then have to interpret, so when Michael says something
> which is not what the JMRP page itself says, that changes something.
> Probably if it wasn't an ISP as big as Hotmail it wouldn't be such an issue.
>
>
>
> --
> 
> Benjamin
>
> 2017-10-30 5:22 GMT+08:00 Bill Cole  scconsult.com>:
>
>> On 28 Oct 2017, at 12:03 (-0400), Benjamin BILLON via mailop wrote:
>>
>> Mhh I'm not sure to follow how it's related. Your freemail accounts are
>>> then absolutely not reactive, ok.
>>>
>>
>> None of my addresses are "reactive" to HTML in bulk email. Even when I've
>> affirmatively subscribed to a list or putatively given a sender implicit
>> permission to market at me at a real address, the only URLs in commercial
>> email I've ever used are unsub links that I've sanity-checked.
>>
>> So if the sender was doing things good
>>> enough, he shouldn't be sending to those at the first place (I guess you
>>> don't subscribe your spamtraps to newsletters just for fun or watching
>>> the
>>> world burn),
>>>
>>
>> Right. The only way a sender has any of those addresses is ultimately
>> from mailbox provider breaches, dictionary attacks, and typos in
>> unconfirmed subscriptions.
>>
>> and if he was doing things even better, those would stop
>>> receiving emails at some points anyway as they'll be considered
>>> "inactives", and therefore not targetable anymore. Which is a policy that
>>> senders (not all, definitely not all of them as of today) enforce because
>>> reputation systems take recipients' reactivity into account, not because
>>> the consent is withdrawn or some other direct request from the recipient.
>>>
>>
>> I don't believe I've ever experienced a legitimate sender doing that:
>> seems extreme and a bit unwise. I suppose whether a sender does that is
>> largely dependent on the characteristics of the recipients. The last time I
>> was involved on the sending side of supposedly "tracked" campaigns we had
>> solid evidence that more users reacted "out of band" (jumps in normal
>> logins correlated to campaigns) than supposedly "opened" messages based on
>> image retrieval.
>>
>> What does that have to do with JMRP, and how having even less reliable
>>> metrics is a good thing?
>>>
>>
>> I'm just noting that what ESPs call "metrics" are fundamentally different
>> across different mailbox providers and audiences. Microsoft JMRP numbers
>> are only directly comparable to Microsoft JMRP numbers, NOT to similar
>> feedback from other providers. That should not be news to you. It's not
>> good or bad, it just IS. A faith in ANY feedback metrics being
>> quantitatively accurate reflections of what happened with a piece of email
>> after delivery (beyond simplistic objective facts like URL retrieval) is at
>> odds with reality.
>>
>>
>>
>>
>> --
>> Bill Cole
>> b...@scconsult.com or billc...@apache.org
>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>> Currently Seeking Steady Work: https://linkedin.com/in/billcole
>>
>> ___
>> 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
>
>


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

Re: [mailop] Any information for the MX mail.h-email.net

[David Hofstee]

forgot to share...


On 20 October 2017 at 10:13, David Hofstee <opentext.dhofs...@gmail.com>
wrote:

> Yeah. There is a whole slew of mail servers that will not relay to actual
> recipients that want your email. These are basically domains for rent and
> you don't know who is renting them ( e.g. https://www.mcafee.com/threat-
> intelligence/domain/default.aspx?domain=mail.b-io.co or
> https://www.threatminer.org/domain.php?q=mail.b-io.co ).
>
> See https://www.robtex.com/dns-lookup/mail.h-email.net under "sharing IP
> numbers" for more domains of the same operator. There are more *operators*
> but this is the largest one.
>
> Yours,
>
>
> David
>
> On 19 October 2017 at 16:16, Emanuel <emanuel.gonza...@donweb.com> wrote:
>
>> Hello,
>>
>> On this server respond domains similar to real domains such as
>> hotmail.com, example hotmial.com, hotmai.fr.
>>
>> On it safe to lock the MX?
>>
>> Regards,
>>
>> Emanuel.
>> --
>> [image: envialosimple.com] <http://www.envialosimple.com>
>> Emanuel Gonzalez
>> Deliverability Specialist
>> emanuel.gonza...@donweb.com
>> www.envialosimple.com
>> [image: by donweb] <http://www.envialosimple.com>
>>
>> Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son
>> confidenciales, de uso exclusivo para el destinatario del mismo. La
>> divulgación y/o uso del mismo sin autorización por parte de DonWeb.com
>> queda prohibida.
>> DonWeb.com no se hace responsable del mensaje por la falsificación y/o
>> alteración del mismo.
>> De no ser Ud el destinatario del mismo y lo ha recibido por error, por
>> favor, notifique al remitente y elimínelo de su sistema.
>> Confidentiality Note: This message and any attachments (the message) are
>> confidential and intended solely for the addressees. Any unauthorised use
>> or dissemination is prohibited by DonWeb.com.
>> DonWeb.com shall not be liable  for the message if altered or falsified.
>> If you are not the intended addressee of this message, please cancel it
>> immediately and inform the sender
>> Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem
>> conter dados confidenciais ou privilegiados.
>> Se você os recebeu por engano ou não é um dos destinatários aos quais ela
>> foi endereçada, por favor destrua-a e a todos os seus eventuais anexos ou
>> copias realizadas, imediatamente.
>> É proibida a retenção, distribuição, divulgação ou utilização de
>> quaisquer informações aqui contidas.
>> Por favor, informenos sobre o recebimento indevido desta mensagem,
>> retornando-a para o autor.
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
>
> --
> --
> My opinion is mine.
>



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

Re: [mailop] unique/shared public DKIM keys per domain?

[David Hofstee]

Didn't Google mention they wanted the age of the keys to count in the spam
score?

Old keys tend to have a longer timeframe to get stolen I guess. Maybe a
frequent key changes is an indicator of having good ops practices which
result in fewer incidents? Funny enough, I have only ever met one customer
that wanted to refresh its 1024 bit keys.

Yours,


David

On 10 October 2017 at 05:15, Benjamin BILLON via mailop 
wrote:

> Hi John,
>
> > Do you?
> In the way I tried to express it, yes.
> Gmail recently said that the selector, or the change of the selector, can
> have a role in their anti-spam and reputation system. Just because it's an
> element of the email, and that it can indicate something.
> It is not used for _reputation_ in its purest, simpliest form (value of d=
> is good, value of d=is bad), but it is one of the thousands thinks that
> might have a non-null, even if negligible, weight in the whole system.
> S, technically,an ISP's scientist or even just tech guy, won't say
> that these elements are not part of the reputation system. But the public
> should understand "nope, they're not".
> I don't know if the other main ISPs include s= or other things in their
> decision system, I believe they do. Maybe tomorrow they won't. And the day
> after tomorrow, they will again.
>
> That being said, the main point is that if you have deliverability issues,
> probably related to the reputation of a domain name, the incidence of s= or
> the public key are not the first things to worry about. Lack of consent,
> irrelevant content, bad list hygiene and too much communication pressure
> are by far the first causes of problems.
>
> Cheers,
>
>
> --
> 
> Benjamin
>
> 2017-10-10 10:56 GMT+08:00 John Levine :
>
>> In article 

Re: [mailop] List-Unsubscribe support

[David Hofstee]

And I found out that Yandex, ICloud web interface and Protonmail support it.

Does anyone know what the requirements for Google or Live.com are to show
the unsubscribe link (anything more specific than "reputation")? Is volume
from that specific sender required? Aligned SPF/DKIM authentication?
Because getting to see the button is inconsistent for IP addresses with
good reputation (one newsletter showed it, another from my personal domain
did not, same IP pool, both cases had aligned SPF/DKIM authentication).

I also found that Google has the unsubscribe button, sometimes, for emals
without the List-Unsubscribe header. Not sure what will happen then.

Thanks,


David

On 3 October 2017 at 14:21, David Hofstee <opentext.dhofs...@gmail.com>
wrote:

> Hi,
>
> Does anyone have a list of the web/mail client support of the
> List-Unsubscribe header? The list-unsubscribe.com site does not seem to
> have it.
>
> *Free mail addresses & web interface:*
> Live.com/Office365 -- only support the mailto
> Gmail  -- supports the first listed method
> Yahoo -- does not support it (? did not seem to work with mail that had
> header)
> Fastmail
> GMX
> AOL
> Proton
> Zoho
> Yandex
> ICloud
>
> *OSS/Free web interfaces *
> Dovecot
> ...
>
> *Mail clients*
> Outlook
> Thunderbird  -- requires plugin to support it
> Apple iOS -- supports it
> ...
>
> Any remarks on this are appreciated. Thanks,
>
>
> David
>
>


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

[mailop] List-Unsubscribe support

[David Hofstee]

Hi,

Does anyone have a list of the web/mail client support of the
List-Unsubscribe header? The list-unsubscribe.com site does not seem to
have it.

*Free mail addresses & web interface:*
Live.com/Office365 -- only support the mailto
Gmail  -- supports the first listed method
Yahoo -- does not support it (? did not seem to work with mail that had
header)
Fastmail
GMX
AOL
Proton
Zoho
Yandex
ICloud

*OSS/Free web interfaces *
Dovecot
...

*Mail clients*
Outlook
Thunderbird  -- requires plugin to support it
Apple iOS -- supports it
...

Any remarks on this are appreciated. Thanks,


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

Re: [mailop] Contact Cloudmark ?

[David Hofstee]

Hi Vick,

You are raffling back. So I hope I am clarifying the right part.

My point with Co-registration: It does not work because there are other
motivations for people subscribing (and therefore other expectations).
Other motivations than just wanting to receive the actual email (e.g.
receiving an Ipad). Because the recipient barely knows the other 3rd party
that (s)he is registering with.

So even if you try to set expectations in the clearest of ways, with a very
good opt-in process, you will end up with many people hitting the spam
button. Conclusion: It does no work even if it should.

I am not sure where your sentence "never contact me again" is about. Please
clarify.

Yours,


David

On 20 September 2017 at 14:16, Vick Khera <vi...@khera.org> wrote:

> On Wed, Sep 20, 2017 at 4:30 AM, David Hofstee <
> opentext.dhofs...@gmail.com> wrote:
>
>> E.g. co-registration. In my opinion, many of the companies I met that did
>> that, just use it for "want to win an Ipad? Register here". This translates
>> to "spam me with your emails for a chance of happiness". So basically these
>> emails are unwanted. It is something else they are after, but not the
>> email. Unsubscribing is usually a problem as well (you should be able to
>> unsubscribe as easily as you
>>
>
> Do you really expect raffles like that to imply "never contact me again"?
> That's not just unrealistic, it is the exact opposite of what people
> expect.
>
> ___
> mailop mailing list
> 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] Contact Cloudmark ?

[David Hofstee]

Hi James,

Your website indicates you provide services that "just do not work" for
email. It may be legally allowed but that does not mean your recipients
want and expect those emails.

E.g. co-registration. In my opinion, many of the companies I met that did
that, just use it for "want to win an Ipad? Register here". This translates
to "spam me with your emails for a chance of happiness". So basically these
emails are unwanted. It is something else they are after, but not the
email. Unsubscribing is usually a problem as well (you should be able to
unsubscribe as easily as you subscribed; which is technically difficult if
you sell your list to 20 organisations). I have never seen it work even if
executed perfectly and fool-proof (bigger fools exist than you can imagine).

So people complain on these emails. The definition of spam. It does not
work. Similar stuff for your other services. Be happy you are not on
Spamhaus. Change business model while you can.



David


On 19 September 2017 at 15:32, James Hoddinott  wrote:

> You appear to do epending. This pretty much ends any discussion.
>
> On 18 September 2017 at 16:38, Romain Cambien via mailop <
> mailop@mailop.org> wrote:
>
>> Hello,
>>
>> Friday, Cloudmark blocked multiple IPs on our main IP bloc.
>> I tried the reset form and multiple contact forms from their website
>> without any response.
>>
>> How can I contact the support to discuss our problem ?
>>
>> Thanks.
>>
>> --
>> Romain Cambien
>> Directeur Technique
>>
>> [image: WebRivage]  [image: OptinCollect]
>> 
>> [image: société du groupe WebRivage] 
>>
>>
>> ___
>> 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
>
>


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

Re: [mailop] Contact Cloudmark ?

[David Hofstee]

Hi Romain,

Not sure if you know this: Most blacklists require you to "solve your
problem" first. Not sure if they want to discuss it with you, as it is your
problem and not theirs (I'm fairly certain they won't like to discuss it
with you).

They do read and respond to the forms filled, generally within one business
day. So I guess they have a reason not to respond.

Yours,


David

On 18 September 2017 at 17:38, Romain Cambien via mailop 
wrote:

> Hello,
>
> Friday, Cloudmark blocked multiple IPs on our main IP bloc.
> I tried the reset form and multiple contact forms from their website
> without any response.
>
> How can I contact the support to discuss our problem ?
>
> Thanks.
>
> --
> Romain Cambien
> Directeur Technique
>
> [image: WebRivage]  [image: OptinCollect]
> 
> [image: société du groupe WebRivage] 
>
>
> ___
> mailop mailing list
> 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] Hotmail "Organization queue quota exceeded."

[David Hofstee]

There seem to be MS issues in receiving email. See
https://portal.office.com/servicestatus . Is this from today only?

Yours,


David

On 18 September 2017 at 15:18, Benjamin BILLON via mailop  wrote:

> Hello,
>
> I'm hearing about replies like "450 4.7.3 Organization queue quota
> exceeded" for .fr Microsoft domains (hotmail/live/outlook).
> I didn't receive any myself, but I still wonder if anyone ever heard of
> this?
>
> Google only has 6 results for this, only 2 are relevant, and dated of 2014
> ..
>
> Cheers,
> --
> 
> Benjamin
>
> ___
> mailop mailing list
> 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] amusing dns failure, pgsurveying.com

[David Hofstee]

Hi Carl,

Interesting setup. What do you mean by 'clever'? Because I am not sure
what this setup will gain them.

Yours,


David

On 30 August 2017 at 18:55, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> If you do much work in email / spam control, you end up seeing some of
> the many ways that folks manage to screw up their DNS records. But this
> one is amusing. Two disconnected sets of dns servers, both sets
> referenced from the .com servers. Each set has their own serial number
> and different content. Clever.
>
>
> dig pgsurveying.com. ns @h.gtld-servers.net  +norecur +nodnssec
> +nocookie
>
> ;; AUTHORITY SECTION:
> pgsurveying.com.172800  IN  NS  ns1.p06.dynect.net.
> pgsurveying.com.172800  IN  NS  ns3.p06.dynect.net.
> pgsurveying.com.172800  IN  NS  ns2.p06.dynect.net.
> pgsurveying.com.172800  IN  NS  ns4.p06.dynect.net.
> pgsurveying.com.172800  IN  NS  ns1-08.azure-dns.com.
> pgsurveying.com.172800  IN  NS  ns2-08.azure-dns.net.
> pgsurveying.com.172800  IN  NS  ns3-08.azure-dns.org.
> pgsurveying.com.172800  IN  NS  ns4-08.azure-dns.info.
>
>
>
> dig pgsurveying.com. ns @ns1.p06.dynect.net. +short
> ns4.p06.dynect.net.
> ns1.p06.dynect.net.
> ns3.p06.dynect.net.
> ns2.p06.dynect.net.
>
> dig pgsurveying.com. soa @ns1.p06.dynect.net. +short
> ns1.p06.dynect.net. sysops.pressganey.com. 23 3600 600 604800 900
>
>
>
> dig pgsurveying.com. ns @ns1-08.azure-dns.com +short
> ns1-08.azure-dns.com.
> ns2-08.azure-dns.net.
> ns3-08.azure-dns.org.
> ns4-08.azure-dns.info.
>
> dig pgsurveying.com. soa @ns1-08.azure-dns.com +short
> ns1-08.azure-dns.com. sysops.pressganey.com. 20 3600 600 604800 900
>
>
>
> dig patients.pgsurveying.com. txt @ns1-08.azure-dns.com +short
> "\"v=spf1 +a:smtp1.pgsurveying.com +a:smtp2.pgsurveying.com
> +a:smtp3.pgsurveying.com +a:smtp4.pgsurveying.com -all\""
>
> dig patients.pgsurveying.com. txt @ns1.p06.dynect.net. +short
> "v=spf1 +a:smtp1.pgsurveying.com +a:smtp2.pgsurveying.com
> +a:smtp3.pgsurveying.com +a:smtp4.pgsurveying.com -all"
>
>
> Note the extra set of quotes which breaks the spf record on the version
> from the azure servers. Either nobody reads sys...@pressganey.com, or
> they don't care. A note was sent there 30 days ago.
>
>
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlmm7doACgkQL6j7milTFsHp8wCfXOTSsKJG7gcC+Czf1iq2qSSv
> UcUAn3VsCHRtiS+KWugU1GfcapaUGA+g
> =7zwN
> -END PGP SIGNATURE-
>
>
>
> ___
> mailop mailing list
> 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] mail.protection.outlook.de IPv6 broken

[David Hofstee]

You are right. But there exist so many domain setups that are borken (IPv6
issues, backup MX that won't accept email, disk that are full, ...).
Because email is complex for most. What was the reason you posted it here?

You could 'reroute' the email to an IPv4 sending IP when pattern X is
replied. I'm sure it won't be the last domain where this is seen.

Yours,


David

On 11 August 2017 at 11:53, Wolfgang Breyha  wrote:

> Hi!
>
> I tried to send E-Mail to the Domain ispa.at which is part of the
> office365
> cloud, which obviously has a broken setup:
>
> Reporting-MTA: dns; grace.univie.ac.at
>
> Action: failed
> Final-Recipient: rfc822;x...@ispa.at
> Status: 5.0.0
> Remote-MTA: dns; ispa-at.mail.protection.outlook.de
> Diagnostic-Code: smtp; 550 5.2.1 Service Unavailable, [ispa.at] does not
> accept email over IPv6 [FRAGER01FT003.eop-ger01.prod.protection.outlook.de
> ]
>
>
> Either you announce a MX with  RRs or you do not. Rejecting Mail this
> way breaks E-Mail for ispa.at badly.
>
> $ host -t mx ispa.at
> ispa.at mail is handled by 10 ispa-at.mail.protection.outlook.de.
> $ host ispa-at.mail.protection.outlook.de.
> ispa-at.mail.protection.outlook.de has address 51.5.80.10
> ispa-at.mail.protection.outlook.de has address 51.4.80.10
> ispa-at.mail.protection.outlook.de has IPv6 address 2a01:4180:4050:800::10
> ispa-at.mail.protection.outlook.de has IPv6 address 2a01:4180:4051:800::10
>
> I will report this to the owner of the Domain as well.
>
> With kind regards,
> Wolfgang Breyha
> postmaster at univie.ac.at
> --
> Wolfgang Breyha  | http://www.blafasel.at/
> Vienna University Computer Center | Austria
>
> ___
> mailop mailing list
> 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] RFC question on smtp replies...

[David Hofstee]

Yes, I know. The subsequent RFCs 2821 and 5321 are equally unclear on this,
I think.

But it is a bit weird to say the human-readable text is for humans only.
Since it is transferred via SMTP, the RFC should define how to handle it.
And it is ambiguous. I would like option 1 best.

David

On 7 July 2017 at 12:03, Vladimir Dubrovin <dubro...@corp.mail.ru> wrote:

>
> Hello David.
>
> RFC 821 is outdated, use RFC 2821 as proposed or RFC 5321 as a draft for
> SMTP. Also, there is an RFC 3463, it adds extended status codes and you
> should probably read it.
>
> According to RFC, only code (and potentially extended status code) are
> intended for machine interpretation. The rest of response is a
> human-readable text, which should not be automatically interpreted. So, as
> a human, you are absolutely free to use it in any reasonable way. You can
> either leave it as is, or remove status codes, or concatenate it  in the
> single line (since it's a human readable form, you should probably replace
> CRLF + status code + delimiter characters with a whitespace, because in
> human-readable form you do not expect the words to be wrapped or the lines
> to contain extra spaces).
>
> 07.07.2017 12:27, David Hofstee пишет:
>
> Hi,
>
> I've an interesting RFC question. In an SMTP reply, one can have single
> line or multiline replies. E.g.
>
> 521 single line reply
>
> or
>
> 521-Line one
> 521-Line two
> 521 Line three
>
> See also https://tools.ietf.org/html/rfc821#page-50 .
>
> My question is: The reply is an answer that is, necessarily, formatted for
> SMTP. But how should the multiline answer be interpreted? What is its
> 'value'.
>
> *option 1: Remove superfluous return codes and s. E.g.:*
> 521 Line oneLine twoLine three
>
> *or option 2: Remove superfluous return codes but keep . E.g.*
> 521 Line one
> Line two
> Line three
>
> *or option 3: Remove superfluous s. E.g.*
> 521-Line one521-Line two521 Line three
>
> *or option 4: Convert s into '\r\n' to make it a one line answer.
> E.g.*
> 521-Line one\r\n521-Line two\r\n521 Line three
>
> *or option 5: Keep everything. Eg. *
> 521-Line one
> 521-Line two
> 521 Line three
>
> The RFC does not really state that. So I am not quite sure how that should
> be logged correctly. Where the formatting starts and what 'value' it is
> supposed to represent. When I look at other standards (e.g.
> http://json.org), the formatting and what it is to represent, is more
> clear.
>
> This came up when I saw 3 different outputs in different MTA's (1,4 and
> 5). Not sure if I have to file a bugreport to my favorite MTA supplier.
>
> Can anyone say something smart about how the reply should be seen?
>
> Yours,
>
>
>
> David
>
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Vladimir Dubrovin
> @Mail.Ru
>
>


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

[mailop] RFC question on smtp replies...

[David Hofstee]

Hi,

I've an interesting RFC question. In an SMTP reply, one can have single
line or multiline replies. E.g.

521 single line reply

or

521-Line one
521-Line two
521 Line three

See also https://tools.ietf.org/html/rfc821#page-50 .

My question is: The reply is an answer that is, necessarily, formatted for
SMTP. But how should the multiline answer be interpreted? What is its
'value'.

*option 1: Remove superfluous return codes and s. E.g.:*
521 Line oneLine twoLine three

*or option 2: Remove superfluous return codes but keep . E.g.*
521 Line one
Line two
Line three

*or option 3: Remove superfluous s. E.g.*
521-Line one521-Line two521 Line three

*or option 4: Convert s into '\r\n' to make it a one line answer.
E.g.*
521-Line one\r\n521-Line two\r\n521 Line three

*or option 5: Keep everything. Eg. *
521-Line one
521-Line two
521 Line three

The RFC does not really state that. So I am not quite sure how that should
be logged correctly. Where the formatting starts and what 'value' it is
supposed to represent. When I look at other standards (e.g. http://json.org),
the formatting and what it is to represent, is more clear.

This came up when I saw 3 different outputs in different MTA's (1,4 and
5). Not sure if I have to file a bugreport to my favorite MTA supplier.

Can anyone say something smart about how the reply should be seen?

Yours,



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

Re: [mailop] SNDS - Low Inboxing

[David Hofstee]

> During the two week stretch of engagement concentration we saw opens from
8 - 11%. The tricky part is expanding the list to good and interested
contacts that have experienced bulk folder placement and probably aren't
checking the spam folder.

That is a pretty low open rate for any standard. I would expect at least
15-20% open rates. Good good marketing emails are in the 40% range
(transactional up to 80%). Is that the percentage minus the mails and
subsequently lower openrates at MS?

Because if you send an email you would expect people to read it. If they
don't then it is unwanted email (which is translated into the word spam).
One might question where that threshold should be, but it is not upto the
sender to have specific expectations on that. One might say your customer
is an outlyer compared to regular marketing email.

Yours,


David

P.S. I have not whitnessed lower openrates at Gmail due to the bulk
tab. Maybe open rates were 1 or 2% lower (not significant; statistically).

On 29 June 2017 at 22:23, Chris Truitt  wrote:

> Hi Laura,
>
> Thanks for your feedback.
>
> The email volume overall is not that high. There are many sends in the low
> thousands, some in the low hundreds. It's actually rare to see a single
> delivery to a group of contacts that exceeds 10k. The list is comprised of
> a great deal of hcp (healthcare practitioner) addresses, hospital and
> clinic addresses. Turnover is also a factor that can lead to recycled spam
> traps. I believe that attrition among residents is in part the reason that
> some specialists will use their freebee addresses rather than a hospital or
> some other clinic domain address.
>
> The sender also has some methods of list cleaning and regularly pulls
> unengaged contacts out of the contact list after a few deliveries. In our
> world confirmed/double opt-in is a good way to reduce complaints and trap
> hits, but that is a really, really tough sell. Most marketers expect to
> lose over 50% of sign ups. I'm totally with you on this, I just haven' been
> able to sell it.
>
> Smart Screen is about how your recipients are reacting to the message. The
> actual recipients receiving the mail. Not test panels, not trap accounts
> but based on how your recipients are acting with the mail that you are
> sending them. So the folks who are getting the mail from Merck don’t want
> it and Hotmail is reacting to that and filtering based on that. Fix the
> “wantedness” of the mail first.
>
> So we know complaints isn't and has never really been an issue. The
> wantedness doesn't seem to be a problem with any other top ISP.
> How much of a factor is engagement with Smart Screen? Are they approaching
> Gmail levels of sophistication?
>
> During the two week stretch of engagement concentration we saw opens from
> 8 - 11%. The tricky part is expanding the list to good and interested
> contacts that have experienced bulk folder placement and probably aren't
> checking the spam folder.
>
>
>
> On Thu, Jun 29, 2017 at 12:50 PM, Laura Atkins 
> wrote:
>
>>
>> On Jun 29, 2017, at 8:51 AM, Chris Truitt  wrote:
>>
>> Hi Laura,
>>
>> Our complaint rates are very low. The oncologists all have a direct
>> relationship with Merck and have signed up to receive mail. The content
>> directly pertains to cancer treatments in this example. They also spent two
>> weeks sending to a core list of contacts with a strong history of
>> engagement, and this didn't make a dent on the report.
>>
>>
>> So smart screen measures for a longer period than 2 weeks.
>>
>> To your point, we saw higher open rates as would be expected when sending
>> to engaged contacts. No complaints and no trap hits during this time, but
>> it seems the message content is still flagged by smart screen.
>>
>>
>> Low complaint rates are easy to get these days if you are regularly
>> sending through an ESP with access to a FBL. They’re so trivial to get to
>> acceptable levels I don’t really ever pay attention to complaint rates
>> unless they’re high.
>>
>> Smart Screen is about how your recipients are reacting to the message.
>> The actual recipients receiving the mail. Not test panels, not trap
>> accounts but based on how your recipients are acting with the mail that you
>> are sending them. So the folks who are getting the mail from Merck don’t
>> want it and Hotmail is reacting to that and filtering based on that. Fix
>> the “wantedness” of the mail first.
>>
>> I have put less emphasis on snds in my report. The sender will continue
>> to concentrate sends on engaged contacts, but it seems like they are
>> getting placed in a category with the traditional pharma content we've come
>> to know and hate. Ideally I'd like to see if there's a way for us to have
>> the sender identified as legitimate and get around some of the content
>> constraints.
>>
>>
>> I don’t actually think that’s the issue. Smart Screen is based on
>> recipient feedback directly to 

Re: [mailop] Any PlusNet (UK) admins on this list?

[David Hofstee]

Hi Daniel,

You are not providing any detail and I presume you are new here. The
question you ask is too broad to provide a good answer. Most people here
make their question much more specific, including details, so that it can
get answered.

Please read up and be more specific. Some resources for you (on what you
should to adhere to; not sure what the emails are about). If you have
questions on these, we might be able to answer:
- https://www.spamhaus.org/faq/section/Marketing%20FAQs
-
https://securityintelligence.com/the-art-and-science-of-how-spam-filters-work/
- https://blogs.msdn.microsoft.com/tzink/

Have fun reading.


David

On 20 June 2017 at 15:47, Daniel Hadfield  wrote:

> We're seeing issues with a clients mail being rejected as "spam"
>
> But they don't seem to be on a blacklist, was wondering if someone can
> help shed some light on it
>
> ___
> mailop mailing list
> 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] Google email hosting and abuse handling?

[David Hofstee]

For the most part I agree. Maybe there should be a mechanism to ensure that
dangerous content is flagged in such a way that it is 'disarmed' (or very
explicitly flagged) but available for research. Not all abuse@ departments
require, or are equiped, to work with viruses.

Yours,


David

2017-05-04 11:03 GMT+02:00 :

> > From: Brandon Long
>
> > To whitelist abuse@domain, you would need to:
>
> > This won't disable our blatant spam blocking a smtp-time, however.  And
> > there is no way to disable the antivirus blocking either (I see some
> folks
> > who complain about that as well).
>
> I think that by default addresses abuse @ every domain
> must accept without any spam and virus filtering (including smtp-time)
> messages with Subject containing one of subscrings (case-independent):
> fwd, forward, spam, complain, virus, trojan, phish, abuse.
> Also messages in ARF format.
> Greylisting for 3 min is OK. As is use of a DNSBL such as CBL.
> Even greylisting-if-in-CBL-or-no-FCRDNS is quite effective.
>
> ___
> mailop mailing list
> 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] Is Yahoo! breaking the RFC 5321 for an Implicit MX?

[David Hofstee]

It may have to do with squatted/parked domains and/or port 25 being closed
by a firewall. Parked domains generally have A records for showing ads but
often do not have MX records (or an open port 25). Instead of getting a
bounce immediately, you may have to wait for a timeout when the sender
makes a simple typo.

And then there are cases when parked domains do have port 25 open and/or an
MX record. Different discussion.


David Hofstee
OpenText

2017-04-19 3:50 GMT+02:00 John Levine <jo...@taugh.com>:

> In article <92c77841-5260-5c05-c3e6-56671eeb2...@pccc.com> you write:
> >However, under RFC 5321, section 5.1, I had always thought that without
> >an MX, the system should revert to using the A record as an implicit MX.
>
> You are correct.
>
> On the other hand, these days domains that expect mail generally do
> have MX records, so I can't blame them for treating the lack of MX
> as a signal that the address is bogus.
>
> R's,
> John
>
> ___
> mailop mailing list
> 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] UOL Spam Compliant Format

[David Hofstee]

Hi Jay,

There is a 0.01% of background noise of people who complain. And that
is not due to the senders abuse*. So if you send 1BN emails, small
ESP, there would be 100.000 complaints per year like that. In my opinion
those addresses should be blocked automatically.

Now anything above 0.1% or 0.2% complaint rate... Those rates are much
higher than normal and should be taken care of properly. It is also very
easy to explain a customer that 10x to 20x complaint rates are
exceptional. This is also about the rate stated by Microsoft in their SNDS
(0.3%). I think some, like Yahoo, want lower complaint rates but I have no
numbers for that.


David Hofstee
OpenText

* I have seen people press the spam button mere minutes after filling in
the subscribe form which was as clear as can be. Subscribers sometimes
just can't find the unsubscribe link, forgot they opted in, sometimes the
translation of the button becomes 'unwanted email', people think the spam
button is appropriate for all marketing email even though they opted in or
they just don't care.

2017-04-18 7:47 GMT+02:00 Jay Hennigan <mailop-l...@keycodes.com>:

> On 4/17/17 9:57 PM, Brian Sisolak wrote:
>
> UOL sends spam complaints to one of our ESPs (IBM), where someone clicks
>> the opt-out link in the spam report (contained in the original email
>> body sent to the end-user) .
>>
>
> So listwashing? Spam complaints aren't just an alternate unsubscribe
> mechanism. They're an indication that your mail is being sent to people who
> never asked for it. Granted some people are lazy/stupid. I see occasional
> feedback loop complaints for obviously transactional and personal email.
> From AOL especially. If this is happening more than occasionally and your
> mail is bulk advertising, you should ensure that your list is bonafide
> confirmed opt-in.
>
> The opt-out link is not working, which is
>> very concerning to us and our ESP.
>>
>> Our theory is that UOL is stripping out a URL parameter (only in spam
>> reports) that contains the user’s email address. We pass that value to
>> auto-populate the opt-out form and run client-side validation. As there
>> is no email parameter in the URL, the validation fails. We have plenty
>> of data that UOL users are opting out. Our theory is that the email
>> parameter only seems to be stripped out from the Spam Complaint.
>>
>
> Almost all spam complaint and feedback loop systems redact email addresses
> in the headers. Most will go further and redact anything that looks like am
> email address anywhere in the body of the spam. This is to minimize the
> incidence of spammers who just list-wash the complaints and continue to
> send to dirty lists. Spammers often mung the addresses in embedded links
> either by full encryption or just replacing the "@" with some other
> character to get around this.
>
> but the =bri...@trilogyinteractive.com
>> <mailto:bri...@trilogyinteractive.com> gets replaced with an X in
>> original body that is forwarded to our ESP:
>>
>
> Yep. Deliberate redaction by the spam reporting mechanism. Your ESP should
> be questioning the quality of your list as a whole, not just listwashing
> individual complaints.
>
> Do you closed-loop confirm opt-in status of all addresses in your list
> before adding them? If not, why not?
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



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

Re: [mailop] UPC / Liberty Global: No retries after tempfail (greylisting)?

[David Hofstee]

Hi Benoit,

I have forwarded your email to an email admin @UPC. He is a busy man, not sure 
if he will respond. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Benoit Panizzon" <benoit.paniz...@imp.ch>
Aan: mailop@mailop.org
Verzonden: Dinsdag 3 januari 2017 10:51:29
Onderwerp: [mailop] UPC / Liberty Global: No retries after tempfail 
(greylisting)?

Hello

Due customer complaints I started inspecting our logfiles for UPC
anomalies.

Indeed, UPC seems to have migrated it's email services from austria
(chello.at ip range) to a Liberty Global IP range in NL

This range is not yet whitelisted by SWINOG or DNSWL.org so our
infrastructure applies greylisting.

And I also see, that delivery is attempted only once, never overcoming
greylisting unless the sender tries again within the right time window.
Worse! The sender does not get any kind of error back, that his email
did not get delivered.

Opening at trouble ticket at UPC switzerland is probably useless as in
the past they were unable to forward those ticket to the mail
infrastructure operators. Also email to the 'postmaster' of the
affected customer domain never get replied.

So does anyone have a direct contact to the operators of the UPC email
infrastructure in the netherlands?

Does anyone know the IP range UPC uses for it's upcmail.net service?
They don't use SPF where I could extract the ranges and whitelist them.

Kind regards

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

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

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

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

Re: [mailop] Storing 821 envelope recipients in an 822.Header?

[David Hofstee]

The X- type headers are deprecated... https://tools.ietf.org/html/rfc6648

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "John Levine" <jo...@taugh.com>
Aan: mailop@mailop.org
Cc: st...@blighty.com
Verzonden: Woensdag 7 december 2016 04:40:30
Onderwerp: Re: [mailop] Storing 821 envelope recipients in an 822.Header?

In article <5ef35d60-7f27-4b35-b2e8-53a20aa61...@blighty.com> you write:
>I know there's no standard header for storing the envelope recipients for a 
>message (for good reason, especially
>when it comes to Bccs) but there are times when it's useful.
>
>Does anyone know of a system that does that? I'm stashing them in "X-Rcpt-To" 
>at the moment, for lack of anything
>better, but if there's even a marginal ad-hoc standard for it I'd like to be 
>consistent.

Oh, and some MTAs put them in Delivered-To: lines at the top of the message, 
after
the Return-Path:.

R's,
John

___
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 many more RBL's do we really need?

[David Hofstee]

The Live.com Spam-butten, in Dutch, translates into 'unwanted mail'. Ok... 
Sure. Whatever. 


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Dominique Rousseau" <d.rouss...@nnx.com>
Aan: mailop@mailop.org
Verzonden: Dinsdag 30 augustus 2016 14:37:45
Onderwerp: Re: [mailop] How many more RBL's do we really need?

Le Tue, Aug 30, 2016 at 05:08:21AM -0400, Neil Schwartzman [n...@cauce.org] a 
écrit:
[...]
> I saw, and continue to see to this day, error in reporting from *all*
> such sources (they are myriad, probably numbering in a couple of dozen
> these days), they are no more endemic to AOL than any other provider. 

I never saw what the UI looks like, for AOL users,...

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

[mailop] SNDS data missing

[David Hofstee]

Hi, 

Do more people see SNDS weirdness? On Sunday I only see the results for half of 
a day (Sunday 8 PM to Monday 8 AM CEST). Saturday is not displayed at all. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

[David Hofstee]

I for one welcome the explicit blocks of email. They tell me simply what is 
wrong so I can (let people) fix things. What I really hate is the "possible 
spam detected"-like messages. I don't have time to check all 40 domains in the 
email and all IPs involved for those domains (and then usually not finding 
badness). I like to nitpick and find bad stuff, but that stretches it. Explicit 
blocks make my life easier.

So even if you weigh RBLs it would be nice to see the most important reason 
stated in the smtp reply. You could even change that behaviour given the 
reputation of the sender. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Anne P. Mitchell" <amitch...@isipp.com>
Aan: "Michael Wise via mailop" <mailop@mailop.org>
Verzonden: Maandag 29 augustus 2016 19:08:58
Onderwerp: Re: [mailop] How many more RBL's do we really need?

> using Barracuda's RBL for high scoring, and not for outright blocking.

I think that in this day and age, this is true for *any* list - black-, white-, 
reputation- (yes, even ours).  Whitelists can also have false positives - even 
pay for play ones, because while full-on spammers may not pay to be on a 
whitelist, or for reputation certification, etc,  organizations that are 
whitehat can experience personnel changes in their email and marketing 
departments, and an organization can go from blindingly white to a shade of 
grey overnight. 

Plus, even more now than ever, what one receiving system may think of as 'spam' 
another may think of as 'legitimate email our users just didn't know they 
wanted'.  In fact, that's why we take pains to make a point that our lists are 
*not* whitelists - they are lists where receivers can get information about the 
specific practices of the senders - so, like Rob said - use them for scoring, 
not for outright blocking (well, accepting, in our case).

Anne

Anne P. Mitchell, 
Attorney at Law
Legislative Consultant
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Asilomar Microcomputer Workshop Committee
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell



___
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 many more RBL's do we really need?

[David Hofstee]

It see it as typical that one receives a baseline of 0.02% or 0.01% complaints 
for legitimate senders where the opt-in process is fine and dandy. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 


Van: "Eric Henson" <ehen...@pfsweb.com> 
Aan: "Suresh Ramasubramanian" <ops.li...@gmail.com> 
Cc: mailop@mailop.org 
Verzonden: Maandag 29 augustus 2016 16:26:09 
Onderwerp: Re: [mailop] How many more RBL's do we really need? 



The relationship between Barracuda and EmailReg.org isn’t very clear. At the 
very least, Barracuda is sponsoring EmailReg.org, providing them with 
equipment, IP space, and referrals. Emailreg.org claims the $20/year is to keep 
spammers from abusing the service. 



http://spamassassin.1065346.n5.nabble.com/emailreg-org-pretty-good-white-list-td67383.html
 




I should mention that Rob McElwen—who I see just posted—runs a good RBL, I 
stopped using it earlier this year because we started using the Barracuda RBL 
when we bought our Barracuda appliances. Rob posted in the thread above that 
emailreg.org is legit. 



Mathias—I’m referring to transactional emails (“We have received your order”, 
“we have shipped your order”) as well as replies to emails from the customer 
(1.Customer emails, “where is my order?”, 2. Email agent replies, “we shipped 
it yesterday”, 3. customer marks reply as spam). Take a look at 
http://www.pfsweb.com/what-we-do/omni-channel-operations.php and 
http://www.pfsweb.com/clients/ and you should get a pretty good idea of what 
these emails look like. 








From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com] 
Sent: Monday, August 29, 2016 9:04 AM 
To: Eric Henson 
Cc: mailop@mailop.org 
Subject: Re: [mailop] How many more RBL's do we really need? 





Does Barracuda still operate that paid whitelist? 



--srs 



On 29-Aug-2016, at 7:28 PM, Eric Henson < ehen...@pfsweb.com > wrote: 





I’ve done lots of RBL testing, for years, and the only RBLs that I’m using are 
the ones that are effective and don’t have false positives: Barracuda RBL and 
Spamhaus Zen (paid). But I still do my best to keep my mail servers off the 
other lists; usually this just means I stop sending email from one of my 
gateways for a week. I also had to sign up for the AOL junk reporting service 
because their users are too stupid to know the difference between the “delete” 
button and the “report junk” button. 




___ 
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] Facebook/Twitter, advice/anyone here?

[David Hofstee]

You can fix the bounce handling problem for 97%+ of the bounces. You just have 
to put in a lot of effort to make it smarter (which LinkedIn should put in). Or 
they can buy a custom bouncehandler from us ;-). 

So I don't agree to the 'just keep emailing and ignore bounces' thing either. 
And I don't see why the 550's, telling that there is a technical issue in your 
PTR, do not count (after a number of those). Because you either fix the issue 
or stop mailing to recipients that will not receive it. A month is a fine time 
to fix issues (any issue). 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Michelle Sullivan" <miche...@sorbs.net>
Aan: "Brandon Long" <bl...@google.com>
Cc: "mailop" <mailop@mailop.org>
Verzonden: Woensdag 17 augustus 2016 01:19:27
Onderwerp: Re: [mailop] Facebook/Twitter, advice/anyone here?

Brandon Long wrote:
> I'm not sure what they're supposed to do.

Bounce handling/hard failing wouldn't be a bad thing... I have facebook 
getting 550 User Unknown for the same email address for over 6 months 
now  that's when it gets ridiculous...  (Well done Steve for the 
article on this problem) you know, I get  with the whole ESP 5xx's are 
not hard fails argument (even though I disagree personally) .. but 
seriously... if the same email address gives you 5xx responses 
(particularly 550's) for a month you have to question the validity of 
the argument.

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

[mailop] Gmail now requires DKIM / SPF

[David Hofstee]

Gmail now requires SPF or DKIM: 
http://googleappsupdates.blogspot.nl/2016/08/making-email-safer-with-new-security-warnings-in-gmail.html
 

Not sure why it it calls it authenticated when it is not aligned with the 
'From'-domain (like DMARC does). Technically it is, but not by the sender 
itself. I was hoping for a strong authentication booster ;-). 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcop blows a fuse.

[David Hofstee]

It is too easy to get an IP* listed on Spamcop (without filing spamcop 
complaints). They don't see that as a security bug.

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

* By that I mean someone else's. 

- Oorspronkelijk bericht -
Van: "Michael Rathbun" <m...@honet.com>
Aan: mailop@mailop.org
Verzonden: Woensdag 3 augustus 2016 01:22:55
Onderwerp: [mailop] Spamcop blows a fuse.

This server sends a spam feed to Spamcop (it's Nadine, in fact).

So, of course, the IP is now listed on Spamcop.

Every day, it's something new.

mdr
-- 
  Human beings are perhaps never more frightening than when they are
  convinced beyond doubt that they are right.
  -- Laurens Van Der Post, The Lost World of The Kalahari


___
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 421 is sometimes a permanent failure?

[David Hofstee]

They should 5xx an over quota too. Just clogging up queues. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Jeffry Dwight" <jeffry.dwi...@greyware.com>
Aan: mailop@mailop.org
Verzonden: Donderdag 16 juni 2016 23:25:21
Onderwerp: [mailop] GMail 421 is sometimes a permanent failure?

Today I noticed the following response from GMail after submission of email:

421-4.7.0 [x.x.x.x  15] Our system has detected that this message is
421-4.7.0 suspicious due to the nature of the content and/or the links within.
421-4.7.0 To best protect our users from spam, the message has been blocked.
421-4.7.0 Please visit
4.7.0  https://support.google.com/mail/answer/188131 for more information.
f77si267316oig.47 - gsmtp

Contrary to what 421 means generally ("try again later"), and contrary to
GMail's own documentation page

https://support.google.com/a/answer/3726730?hl=en

where it says that 421 4.7.0 means "Try again later, closing connection"

I find that trying again later always results in the same code, and it's
therefore a permanent failure like 5xx would be. The particular email I saw in
the logs was a newsletter from a publisher to an author, with links to new
releases. Spammy in nature, maybe, but certainly solicited, and nothing really
out of the ordinary. 

I noticed it only because our system saw the 421 code and dutifully kept
requeuing for retry until the max number of attempts had been reached.

Am I misunderstanding what 421 means after DATA or BDAT, or is GMail replying
with the wrong code? Surely if it means to reject the email out of hand, it
should say so, shouldn't it?

We currently treat a 5xx reply after DATA or BDAT as a permanent failure, and
don't retry. We treat 4xx replies after DATA or BDAT as temporary, and queue for
retry. How should we handle it?

Jeffry


___
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] Mailchimp / Mandrill App: European VS US Privacy Laws

[David Hofstee]

If you want to create a digital opt-in, that is transferrable between ESPs et 
al, you need:

the digital opt-in to tell you:
- who the recipient is
- what the allowed sender-domain or sender-email address is that you want to 
permit sending emails to you (rfc5322-to)
- when the opt-in was created
- how long the opt-in is valid (so that an opt-in can vanish if you don't use 
it! Very important.)
- where/how to verify the digital signature

the sender must:
- use DMARC (to also avoid criminals being able to steal the opt-in). 

the ESP must be able to
- verify it online (possibly before or during sending an email)
- provide the opt-in with the mail being sent
- refresh it automatically (e.g. be able to request a refresh after sending an 
email)
- if a customers leaves; provide the customer with fresh digital opt-in's. 

for mail hosting orgs; it must be able to
- integrate it in current mta setups
- have a user-interface to guide this process for the end-user
- be able to work with a mixed-system (mails with and without digital opt-in)

the recipient-domain should/must:
- have some sort of policy to advise that senders may (or must) use digital 
opt-in. Useful for changing to such a system. 
- tell where/how to verify the digital signature

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Michael Wise via mailop" <mailop@mailop.org>
Aan: "Ted Cooper" <ml-mailop...@elcsplace.com>, mailop@mailop.org
Verzonden: Zaterdag 11 juni 2016 03:11:12
Onderwerp: Re: [mailop] Mailchimp / Mandrill App: European VS US Privacy Laws

Keep that one sign-up message.
It's a very small per-user piece of data, and it would certainly be proof 
enough and to spare for me.

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

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Ted Cooper
Sent: Friday, June 10, 2016 5:17 PM
To: mailop@mailop.org
Subject: Re: [mailop] Mailchimp / Mandrill App: European VS US Privacy Laws

On 11/06/16 09:29, Michael Wise via mailop wrote:
> 
> ... when the server receives it, it gets authenticated.
> Or did you forget this?

That doesn't help when attempting to provide "proof" of signup at some future 
date - it will simply be a message with a DKIM sig that can no longer be 
confirmed. I don't store old key information and I don't think anyone else 
does. I'm not going to trust a 3rd party to say "it was signed when I got it! I 
swear!" - it may as well be made up.



___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop=01%7c01%7cmichael.wise%40microsoft.com%7c62b7f00ad8f542153c4f08d3918e7fa4%7c72f988bf86f141af91ab2d7cd011db47%7c1=NTM%2b8ppZaN3fK9zFumEUP97%2fD7Pd2m8OtjfZ96KQNWk%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

Re: [mailop] "One-Click" List-Unsubscribe URIs

[David Hofstee]

Same here, auto-unsubscribe presumed. The https is a nice addition that I will 
pass along. I hope that all implementations can handle https. Did people 
verify? 

I treat it nearly as strict as a feedbackloop. All streams (of my customer X) 
to the recipient will cease permanently. I cannot expect Gmail (or others) to 
differentiate between specific permissions that my customer uses and filter 
accordingly. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 


Van: "Gil Bahat via mailop" <mailop@mailop.org> 
Aan: "tobias herkula" <tobias.herk...@optivo.de> 
Cc: mailop@mailop.org 
Verzonden: Donderdag 9 juni 2016 11:40:56 
Onderwerp: Re: [mailop] "One-Click" List-Unsubscribe URIs 

FWIW I understood that the policy of large recipients is to already 'demand' 
and 'assume' that the URLs in List-Unsubscribe behave as 1-clicks and that 
mailto: links can also be triggered from backend systems. That was the 
requirement that I passed to our R I'd be happy if anyone from a large 
recipient can comment on that - not sure what would happen if it didn't indeed 
function like this, or if there are separate streams and this shuts off only a 
specific stream or what happens if the users regrets unsubscribing and 
re-activates it. 
Regards, 

Gil Bahat, 
Director of Online Operations, 
Magisto Ltd. 

On Thu, Jun 9, 2016 at 12:32 PM, < tobias.herk...@optivo.de > wrote: 


Hi List, 

I'm working on a document about a topic that came out of an open 
roundtable discussion at M³AAWG, it is more or less a way for mail 
senders to signal that a URI in the List-Unsubscribe Header has 
"One-Click" functionality and therefore can be triggered by backend 
systems to provide MUA users a better way to unsubscribe from bulk 
commercial mail that is reputable enough. 

We as an ESP implemented it for our customers so if you are curious 
about it, there is a chance that you already getting traffic with this 
feature enabled. 

I'm writing here because I'm looking for more input about it and if it 
interesting enough for ISPs or MUA provider. 

It's a public document and I welcome requests with updates... 
https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt 

For people on the road a copy of the document is attached to this 
mail... 


Kind regards, 

/ Tobias Herkula 

-- 
optivo GmbH 
Head of Deliverability & Abuse Management 
Wallstraße 16 
10179 Berlin 
Germany 

Tel: +49(0)30-768078-129 
Fax: +49(0)30-768078-499 

Email: mailto: t.herk...@optivo.com 
Website: http://www.optivo.com 
Linkedin: http://www.linkedin.com/in/tobiasherkula 

Commercial register: HRB 88738 District Court Berlin-Charlottenburg 
Executive board: Dr. Rainer Brosch, Thomas Diezmann 
Vat reg. no.: DE813696618 

optivo A company of Deutsche Post DHL Group 

___ 
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] Microsoft/Hotmail discards mails

[David Hofstee]

I'm dazzled by users here... Isn't the junk-box supposed to hold junk? Wow. 

Maybe there should be more junk-boxes for the various shades of grey :-). 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Renaud Allard via mailop" <mailop@mailop.org>
Aan: mailop@mailop.org
Verzonden: Donderdag 9 juni 2016 09:14:35
Onderwerp: Re: [mailop] Microsoft/Hotmail discards mails

Hi,

On 06/09/2016 04:08 AM, Michael Wise via mailop wrote:
> 
> At one point, Hotmail tried to turn off the delete action for sufficiently 
> spammy, and just delivered it into Junk; Customers complained. Loudly. 

Is there a public place/forum/whatever where people complained loudly? I
am just curious to see their arguments about this.

Best Regards


___
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] Truncate DNSBL

[David Hofstee]

I don't know if it is reliable. It is not well-known afaik.

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Renaud Allard via mailop
Verzonden: woensdag 4 mei 2016 12:26
Aan: mailop@mailop.org
Onderwerp: Re: [mailop] Truncate DNSBL



On 05/04/2016 11:38 AM, David Hofstee wrote:
> Well, v4bl is not a reliable blacklist. I would ignore any listing there. 
> 
> So his IP is only listed, afaik, on the Truncate list (which is why he mailed 
> to the list in the first place). 
> 

Is Truncate BL a reliable blacklist either?

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

Re: [mailop] Truncate DNSBL

[David Hofstee]

Well, v4bl is not a reliable blacklist. I would ignore any listing there. 

So his IP is only listed, afaik, on the Truncate list (which is why he mailed 
to the list in the first place). 


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Renaud Allard via mailop
Verzonden: woensdag 4 mei 2016 08:05
Aan: mailop@mailop.org
Onderwerp: Re: [mailop] Truncate DNSBL

Hello

On 05/04/2016 01:39 AM, Vick Khera wrote:
> My monitoring service just notified me that an IP from my shared 
> general outbound pool is listed on the Truncate DNSBL. This is really 
> the first I've heard of this list. From what I read on their web 
> pages, they claim that an IP is only listed if > 95% of the mail they 
> detect is spam. I personally find this quite improbable coming from my 
> systems.
> 
> Overall, the messages in that pool are statistically identical across 
> IPs as everything is round-robin delivered. I'm measuring about 0.02% 
> spam complaint rate, Hotmail SNDS is reporting "green", AOL postmaster 
> says the stream is clean. There is nothing different about these 
> numbers for a very long time.
> 
> The IP in question is 199.83.97.5.
> 
> Questions:
> 
> 1) is this list used to cover a consequential number of inboxes?
> 2) is this list true to their self-proclaimed description of 95% spam 
> required?
> 2a) if so, how would the data from the FBLs and from hotmail and AOL 
> be so different?
> 


When checking on http://dnsbl-check.info/?checkip=199.83.97.5 you are listed on 
2 DNSBLs.
I never heard of truncate DNSBL before but it's easy to get over 95% spam if 
they have only a few "sniffers", just send one unique message looking spammy to 
their "sniffers", and you are good to go with 100% spam.



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

Re: [mailop] Still seeing Microsoft 5.4.0 issues?

[David Hofstee]

Hi Maarten,

Thanks. Now I see them too. They used to be direct bounces. These are the 
reporting mta’s() since 29-3:

dsnReportingMTA  count(*)
dns;BAY004-MC2F3.hotmail.com1
dns;COL004-MC6F33.hotmail.com  215


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

Van: mailop [mailto:mailop-boun...@mailop.org] Namens Maarten Oelering
Verzonden: donderdag 31 maart 2016 22:01
Aan: Michael Wise
CC: Josh Nason; mailop
Onderwerp: Re: [mailop] Still seeing Microsoft 5.4.0 issues?

I just queried some data at google scale and found bounces with “5.4.0” 
(nothing more). These are all remote (asynchronous) bounces.
The source of the bounce is 
COL004-OMC4SXX.hotmail.com<http://COL004-OMC4SXX.hotmail.com> where XX varies. 
The recipient domain is mostly hotmail.com<http://hotmail.com>, but also other 
Microsoft domains.
The number varies per day but is a tiny fraction of the volume. Highest numbers 
of these bounces on 03/11, 03/14, 03/23, and today. But they have been there at 
least since 01/01 (and probably before).

Maybe this can help to clear it up.

Maarten Oelering
Postmastery

On 30 mrt. 2016, at 23:04, Michael Wise 
<michael.w...@microsoft.com<mailto:michael.w...@microsoft.com>> wrote:

Is the, “5.4.0 “ the entire bounce code / response?
If there’s more, we need to know to build a case.
If that’s it, that should be enough, but we need to know which it is.

Aloha,
Michael.
--
Michael J Wise | Microsoft | 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] On Behalf Of Joel Beckham
Sent: Wednesday, March 30, 2016 1:53 PM
To: Josh Nason <jna...@dyn.com<mailto:jna...@dyn.com>>
Cc: mailop <mailop@mailop.org<mailto:mailop@mailop.org>>
Subject: Re: [mailop] Still seeing Microsoft 5.4.0 issues?

Not seeing any here.

On Wed, Mar 30, 2016 at 7:01 AM, Josh Nason 
<jna...@dyn.com<mailto:jna...@dyn.com>> wrote:
Hi all -- we continue to see Action: failed/Status: 5.4.0 bounces for emails 
sent to Hotmail, Outlook, and Microsoft domains. I assume others are seeing the 
same?

Microsoft friends, any idea on a resolution time? This feels like it's taking a 
while to be resolved.

--
<~WRD000.jpg><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdyn.com%2f=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=kOH1GObS%2f%2f%2bKupADC6jjq7awTjZsWI2XtEFn35jTEC8%3d>

<~WRD000.jpg><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=DhW5pUq6%2bWITpsJKs%2bZWE%2bjzECqQW6y8Mm59Ph9yuNE%3d>
   
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyninc=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=gDi9eHoI51qNg1It73YJ0Cz3gmIElv9S9UrRbLQEWmg%3d>
 
<~WRD000.jpg><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=CaToMOiBJCLiT5nFeRbY%2fQno3ONdBCNkgoIm%2fJ5ZkzE%3d>
   
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyninc=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=gDi9eHoI51qNg1It73YJ0Cz3gmIElv9S9UrRbLQEWmg%3d>
 
<~WRD000.jpg><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flinkedin.com%2fcompany%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=Vh5TJiH10ssKqxkX3PI2VWEuPZ5F%2fB3ATuctipGpK5M%3d>
Josh Nason / Email Reputation Manager
<~WRD000.jpg> +1 603-289-1244<tel:%2B1%20603-289-1244> | 
@JoshNason<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fjoshnason=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2bEX2RF0nebwRI1mw%2bOzVVnDXkj%2bz5NtdFl3VnvrMCng%3d>
Email is hot! This is 
why<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.linkedin.com%2fpulse%2fwhy-email-marketing-original-form-social-media-josh-nason%3ftrk%3dprof-post=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=KewzDx2BI1QJgWkPm0ME0YtBT1BPB7uNUYVWuxx7HkA%3d>
 it's the original form of social media.

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

Re: [mailop] Still seeing Microsoft 5.4.0 issues?

[David Hofstee]

Hi Josh,

I don’t see it at all. I used to.

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Josh Nason
Verzonden: woensdag 30 maart 2016 15:01
Aan: mailop@mailop.org
Onderwerp: [mailop] Still seeing Microsoft 5.4.0 issues?

Hi all -- we continue to see Action: failed/Status: 5.4.0 bounces for emails 
sent to Hotmail, Outlook, and Microsoft domains. I assume others are seeing the 
same?

Microsoft friends, any idea on a resolution time? This feels like it's taking a 
while to be resolved.

--

[http://dyn.com/wp-content/uploads/2013/08/dyn-logo-esignature.png]<http://dyn.com/>

[http://dyn.com/wp-content/uploads/2013/08/esignature-icon-dyn-twitter.png] 
<http://twitter.com/dyn><http://twitter.com/dyninc> 
[http://dyn.com/wp-content/uploads/2013/08/esignature-icon-dyn-facebook.png] 
<http://facebook.com/dyn><http://twitter.com/dyninc> 
[http://dyn.com/wp-content/uploads/2013/08/esignature-icon-dyn-linkedin.png] 
<http://linkedin.com/company/dyn>

Josh Nason / Email Reputation Manager
[http://dyn.com/wp-content/uploads/2013/08/esignature-icon-phone.png] +1 
603-289-1244<tel:%2B1%20603-289-1244> | 
@JoshNason<http://www.twitter.com/joshnason>

Email is hot! This is 
why<https://www.linkedin.com/pulse/why-email-marketing-original-form-social-media-josh-nason?trk=prof-post>
 it's the original form of social media.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spike in "554 Transaction failed" from Microsoft properties

[David Hofstee]

Not yet...

x...@live.nl:2016-02-10 20:00:05+0100,ret-uid-...@bounces.mailplus.nl,smtp;554 
Transaction failed,mx2.hotmail.com (207.46.8.199),46.31.52.5,207.46.8.199
x...@live.nl:2016-02-10 20:04:42+0100,ret-uid-...@bounces.mailplus.nl,smtp;554 
Transaction failed,mx2.hotmail.com (207.46.8.199),46.31.52.5,207.46.8.199
x...@hotmail.com:2016-02-10 
20:57:35+0100,ret-uid-...@bounces.mailplus.nl,smtp;554 Transaction 
failed,mx2.hotmail.com (207.46.8.199),46.31.53.6,207.46.8.199
x...@hotmail.com:2016-02-11 03:51:27+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx1.hotmail.com (207.46.8.199),46.31.52.130,207.46.8.199
x...@hotmail.com:2016-02-11 
04:06:50+0100,ret-uid-...@bounces.mailplus.nl,smtp;554 Transaction 
failed,mx1.hotmail.com (207.46.8.199),46.31.52.14,207.46.8.199
x...@hotmail.com:2016-02-11 08:31:47+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx4.hotmail.com (207.46.8.199),46.31.52.130,207.46.8.199
x...@hotmail.com:2016-02-11 09:02:41+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx4.hotmail.com (207.46.8.199),46.31.52.133,207.46.8.199
x...@hotmail.com:2016-02-11 09:07:09+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx4.hotmail.com (207.46.8.199),46.31.52.130,207.46.8.199
x...@hotmail.com:2016-02-11 09:18:09+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx4.hotmail.com (207.46.8.199),46.31.52.133,207.46.8.199
x...@hotmail.com:2016-02-11 09:21:13+0100,fm-...@return.flowmailer.net,smtp;554 
Transaction failed,mx4.hotmail.com (207.46.8.199),46.31.52.133,207.46.8.199


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

-Oorspronkelijk bericht-
Van: Michael Wise [mailto:michael.w...@microsoft.com]
Verzonden: woensdag 10 februari 2016 20:32
Aan: David Hofstee; mailop@mailop.org
Onderwerp: RE: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

The number should be tending towards 0.0% shortly if not already.

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

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of David Hofstee
Sent: Tuesday, February 9, 2016 11:50 PM
To: mailop@mailop.org
Subject: Re: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

Hi Michael,

To put a number on small: From my side, 0.2% is not arriving. Yours sincerely,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands
-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Wise
Verzonden: woensdag 10 februari 2016 02:49
Aan: frnk...@iname.com; mailop@mailop.org
Onderwerp: Re: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

It's Not Just You.
It's being actively investigated, and it appears the impact is small...
But rest assured it is most certainly being looked at.

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


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of frnk...@iname.com
Sent: Friday, February 5, 2016 10:36 PM
To: mailop@mailop.org
Subject: Re: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

Thanks for the additional data points -- so it isn't just me.

What's nasty is that the messages are kicked back to the sender, not just 
delayed.

Frank

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Frank Bulk
Sent: Friday, February 05, 2016 5:27 PM
To: mailop@mailop.org
Subject: [mailop] Spike in "554 Transaction failed" from Microsoft properties

Today we had an abnormal number of messages that failed to deliver to Microsoft 
properties due to "554 Transaction failed".

We had 31 today, but only 6 over the previous 7 days.

Now some are email blasts from churches, so perhaps they are emailing specific 
content, but I don't know what the "554 Transaction failed" means.

Frank

Here's a sanitized list from today:

 5 08:52:28.00 [104824074] Failed <redac...@mtcnet.net> <redac...@hotmail.com> 
18208 <000501d16024$d63bafa0$82b30ee0$@net> "Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (207.46.8.167) said in response to MAIL FROM (554 Transaction failed)"
 5 08:55:19.00 [104824142] Failed <redac...@mtcnet.net> <redac...@msn.com>
183286 <56B4B7C3.49.03428@GERRIT-PC> "Site 
https://na01.safelinks.protection.outlook.com/?url=msn.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011d

Re: [mailop] Spike in "554 Transaction failed" from Microsoft properties

[David Hofstee]

Hi Michael,

To put a number on small: From my side, 0.2% is not arriving. Yours sincerely,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands
-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Wise
Verzonden: woensdag 10 februari 2016 02:49
Aan: frnk...@iname.com; mailop@mailop.org
Onderwerp: Re: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

It's Not Just You.
It's being actively investigated, and it appears the impact is small...
But rest assured it is most certainly being looked at.

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


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of frnk...@iname.com
Sent: Friday, February 5, 2016 10:36 PM
To: mailop@mailop.org
Subject: Re: [mailop] Spike in "554 Transaction failed" from Microsoft 
properties

Thanks for the additional data points -- so it isn't just me.

What's nasty is that the messages are kicked back to the sender, not just 
delayed.

Frank

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Frank Bulk
Sent: Friday, February 05, 2016 5:27 PM
To: mailop@mailop.org
Subject: [mailop] Spike in "554 Transaction failed" from Microsoft properties

Today we had an abnormal number of messages that failed to deliver to
Microsoft properties due to "554 Transaction failed".

We had 31 today, but only 6 over the previous 7 days.

Now some are email blasts from churches, so perhaps they are emailing
specific content, but I don't know what the "554 Transaction failed" means.

Frank

Here's a sanitized list from today:

 5 08:52:28.00 [104824074] Failed <redac...@mtcnet.net>
<redac...@hotmail.com> 18208 <000501d16024$d63bafa0$82b30ee0$@net> "Site
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (207.46.8.167) said in response to MAIL FROM (554 Transaction
failed)"
 5 08:55:19.00 [104824142] Failed <redac...@mtcnet.net> <redac...@msn.com>
183286 <56B4B7C3.49.03428@GERRIT-PC> "Site 
https://na01.safelinks.protection.outlook.com/?url=msn.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=yeET3nRGkfNKjqnW6xQh2p%2b66plN%2fw%2bdEHSUSFMP5Ys%3d
 (207.46.8.167) said
in response to MAIL FROM (554 Transaction failed)"
 5 09:07:09.00 [104825044] Failed <redac...@premieronline.net> "[127.0.0.1]
Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (207.46.8.199) said in response to MAIL FROM (554
Transaction failed)"
 5 12:05:35.00 [104837331] Failed <redac...@premieronline.net>
"[199.120.69.25] Site 
https://na01.safelinks.protection.outlook.com/?url=live.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=dvlk2p56HE4bfdWLj%2ba2xWIzVSHcK0sKG3ARwLD4CsI%3d
 (207.46.8.167) said in response to MAIL FROM
(554 Transaction failed)"
 5 14:37:36.00 [104845849] Failed <redac...@premieronline.net> "[127.0.0.1]
Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (65.55.33.135) said in response to MAIL FROM (554
Transaction failed)"
 5 14:37:36.00 [104845849] Failed <redac...@premieronline.net> "[127.0.0.1]
Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (65.55.33.135) said in response to MAIL FROM (554
Transaction failed)"
 5 14:37:36.00 [104845849] Failed <redac...@premieronline.net> "[127.0.0.1]
Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5l%2bjALWkM%2f6ldcrVwviqIzHxoWI97c7oAI%3d
 (65.55.33.135) said in response to MAIL FROM (554
Transaction failed)"
 5 14:37:36.00 [104845849] Failed <redac...@premieronline.net> "[127.0.0.1]
Site 
https://na01.safelinks.protection.outlook.com/?url=hotmail.com=01%7c01%7cmichael.wise%40microsoft.com%7c01a56ea54d96445b8b0708d32ec123d0%7c72f988bf86f141af91ab2d7cd011db47%7c1=Zz%2bIzRcOA5