Re: [mailop] Force double opt in for marketing list companies per email address

[Matt V via mailop]

On 2020-06-05 10:09 a.m., Atro Tossavainen via mailop wrote:

Furthermore, I explicitly indicated that it was the consensus that the
GDPR makes it effectively impossible for them to do what you believe I
said, which I did not. It has been discussed in so many M3AAWG meetings
and between meetings, and Simon McGarr's talk "So you want to be a data
controller" was more or less on this subject.

I don't know how you have managed to read exactly the opposite of my
intentions into my words, I can only conclude that it must have to do
with my awkward non-native use of the language because all other
explanations seem so futile. Here is what I said, for a recap.


Most ESPs want to remain as data processors under GDPR and do not want 
to be put in a position of being a data controller. Utilizing data 
across multiple accounts has some very interesting impacts in regards to 
the responsibility of the controller/processor or controller/controller 
relationships of data.


As for ESPs and the emails that they process on behalf of their clients, 
bounces are processed and removed but each ESPs has different thresholds 
for how this should be done - business logic and all.


 * ESP1 - might remove from an individual list, but nothing stops a
   client from uploading a new list every time they mail. Thus giving
   the appearance of neglecting bounces.
 * ESP2 - might remove only after a third consecutive 5.x.x where it is
   clear the user is unknown - This addresses Luke's comments on
   bounces for things like account disablement/re-activation for
   billing issues
 * ESP3 - Might bounce an address at the client level, but allow a
   brand to over write that flag with a new upload
 * ESP 4 - might not allow people to re-enable bounces ever...
 * ESP5 - might suppress multiple bounces from multiple clients across
   the board for all accounts <<< This has significant GDPR
   implications that the individual client suppression doens't.
 * ESP x - might do some or all of the above...

I've seen all of these scenarios over the years, each has a different 
benefit/risk - but what I can say is that every ESP I've ever worked 
for/with had a different way of doing this. But they all processed 
bounces as best they could and updated their rules on regular timelines. 
Why? Because the standards for bounces get applied in wonky ways at each 
ISP - so really the standard is non-standard.


This is as much a client education piece as it is an industry 
implementation piece. If every ESP knew that 5.5.1 meant the exact same 
thing then they could treat them all the same, but having seen '4.5.1 
Unknown user', and '5.5.0 - Try again later' errors over the years ESPs 
work with the data they are given to the best of their abilities and 
within the laws that are applicable to them and their clients.


I recommend you try working with them vs calling them out as being bad 
actors - These teams (especially the Mailchimp team) works very hard, 
harder than most hosting companies i would imagine, to stop abusive 
behaviour from their networks sending billions of emails around the 
world. From stopping fraudulent sign-ups to, stopping the use of 
purchased lists, to shutting down accounts that get complaints - mind 
you much faster than many other companies that might be part of the same 
abusive message on the content hosting or domain hosting side of the house.


--
~
MATT

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

Re: [mailop] SendGrid Abuse unresponsive

[Matt V via mailop]

On 2020-05-05 11:09 p.m., Andy Smith via mailop wrote:

I've been told by at least one Sendgrid person that they have requested 
membership to the list and are awaiting administrator approvals...



--
~
MATT


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

Re: [mailop] Hehehe.. SenderScore alert.. from March of 2018

[Matt V via mailop]

Not a senderscore person... but this is likely this is the result of an 
end user reporting an old email as spam instead of deleting it.


I would hazard the FBL generates based on the date the use takes an 
action regardless of how old the message is - it likely doesn't even 
look at the original send date.


Once it's sent to you, you can decide if you care to process it or not 
if you feel it's to old to action.


--
~
MATT VERNHOUT

On 2020-04-21 1:29 p.m., Michael Peddemors via mailop wrote:

Just arrived in the fbl mailbox..

This is a Mail.Ru Abuse Report for an email message received from 
domain .com, IP 104.128.152.18, on Sat, 24 Mar 2018 06:00:01 
+.



Version: 1
Original-Mail-From: Аврора 
Source: Mail.Ru
Abuse-Type: complaint
Subscription-Link: https://fbl.returnpath.net/manage/subscriptions/498767
Feedback-Type: abuse
User-Agent: ReturnPathFBL/2.0
Arrival-Date: Sat, 24 Mar 2018 06:00:01 +
Original-Rcpt-To: 551e59781913c107bf57e24df614d...@bk.ru
Reported-Domain: REDACTED.com
Source-Ip: 104.128.152.18

We talked about this once before, but I think getting a report from 
TWO (2) years ago is just NOISE...


Any SenderScore ppl can weigh in on this?






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

Re: [mailop] Thoughts on DNAME for email service providers

[Matt V via mailop]

Brian,

The ESPs I've worked at in the past asked clients to delegate a 
subdomain via NS to their systems and then managed that on behalf of the 
clients account:


   subdomain.client.com  in  NS  DNS01.ESP.com

   subdomain.client.com  in  NS  DNS02.ESP.com

Clean, relatively simple, and well supported buy more DNS providers.

Cheers,

--
~
MATT VERNHOUT

On 2020-04-03 2:29 p.m., Brian Toresdahl via mailop wrote:
I'm setting up a new ESP, and taking a fresh look at how to send on 
behalf of customers with their domain, authenticating with all the 
things: SPF, DKIM, DMARC. My target customers is not necessarily very 
technical, and was curious about how to simplify this experience.


I know that DNAME records exist, but I've always been curious why I 
haven't seen them in the wild at ESPs (yet). They seem like an 
interesting, perhaps ideal mechanism for my use case.


As a reminder:
"A DNAME-record is used to map / rename an entire sub-tree of the DNS 
name space to another domain. It differs from the CNAME-record which 
maps only a single node of the name space."


RFC 6672 shows that DNAME has the status of "PROPOSED STANDARD": 
https://tools.ietf.org/html/rfc6672


Implementation:
If a customer is comfortable sending as "From: 
u...@subdomain.example.com ", they 
would be instructed to delegate "subdomain.example.com 
" to our ESP with DNAME, and then our 
systems can setup SPF, DKIM, DMARC without any further customer input.


Question(s) for this group:
1. Can I expect DNAME to even be supported by receiving email servers, 
given that the RFC is a "proposed standard".

2. Are there limitations I'm not aware of otherwise.
3. Or some battle scars from using DNAME, that this group might be 
willing to share?
4. I'm still not clear on the DMARC lookup rules for subdomains. In 
the absence of DMARC records on the subdomain, the DMARC record on 
organization domain becomes the policy. It sounds like in the case of 
DNAME, would one have to setup explicit DMARC records on several 
subdomains too, since I still would not control the organizational domain?


--

Brian Toresdahl



___
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] More spam via bluehornet.com

[Matt V via mailop]

Bluehornet is now Mapp digital, Lots of legitimate companies use their 
services to send email.


I'm not sure if there are here, but if you haven't yet I'd suggest 
sending to their abuse desk for review.


--
~
MATT VERNHOUT


On 2020-03-03 12:09 p.m., Daniele Nicolodi via mailop wrote:

Hello,

I am still receiving significant ammout of spam through bluehornet.com,
the samples I am looking at now are from ctravelonline.com and they
contain a very useful unsubscribe link

https://echo7.bluehornet.com/ems/messagefooter/preview/html/%%OPTOUT%%

which looks very much like the expansion of a macro in a template
failed, and that redirect to a service login page to which obviously I
don't know the credentials.

Is there anyone at bluehornet.com doing a minimum of quality assurance
on what their customers send out? Does anyone know how any legitimate
customer of bluehornet.com? The temptation to simply siphon all mail
from bluehornet.com to /dev/null is great.

Thank you.

Cheers,
Dan


___
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] Proofpoint contact

[Matt V via mailop]

Contacting postmaster@is typically the right place to start based on all 
the advice given in the past.


--
~
MATT


On 2020-02-05 9:56 a.m., Fusco, Brendan via mailop wrote:
If anyone from Proofpoint could please contact me off list regarding 
caching of a malformed DMARC record, that would be appreciated.


Brendan Fusco
DePaul University, Information Services

___
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] BIMI

[Matt V via mailop]

Zack,

Funny you mention JPMC as they are already working towards supporting 
future requirements of BIMI by getting a VMC for their logos, which is 
part of the planned implemetation of the BIMI standard.


https://www.businessinsider.com/jpmorgan-chase-using-verified-mark-certificate-to-combat-fraud-2019-9

A fake domain owner would not be able to get the required certificate 
and validate their domain. While this is not currently a requirement 
it's been planned from the start of the working group. Current 
implementations require, DMARC at enforcement, a good reputation, and 
some level of trust from the MBPs. As a working group we are still 
defining this section and working with the MBP members to define how 
this should look from both a sending and a receiving side - more to come 
on this in the new year.


Publishing a record doesn't mean it's going to be honoured by any of the 
receiving platforms.


--
~
MATT VERNHOUT


On 2019-12-06 9:43 a.m., Zack Aab via mailop wrote:
Of the following two domains, one is owned by a major bank and locked 
down securely with DMARC and the other one currently costs $12 on 
GoDaddy (it's even discounted!), can you tell which is which?

supp...@jpmorganchasebank.com 
supp...@jpmorganandchasebank.com 
(No particular reason I picked Chase bank, I just crawled around the 
whois looking for a good bank company example a while back and bumped 
into this one first.)


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

Re: [mailop] Best Re-engagement Email

[Matt V via mailop]

On 2019-09-19 2:41 a.m., Hal Murray via mailop wrote:

If you think I'm not engaging because your web-bugs aren't working, you could 
ask me if I still want to be on your list.


This is the exact purpose of a re-engagement message - Hey we noticed 
you've not reading/engaging with our emails in an extended period of 
time, do you still want to receive them?


Basically asking your subscribers "are you still interested in our 
emails otherwise we will stop".


For all the hate about marketing emails you would think this is the 
exact type of responsible behaviour you'd want from them.


--
~
MATT


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