Re: [mailop] Google: 'Low reputation of the sending domain'

[Tom Ivar Helbekkmo via mailop]

Ken O'Driscoll via mailop  writes:

> Mailing lists etc. breaking your DKIM signature is pretty much
> expected behaviour and not a reason to disavow it entirely.

...and that doesn't need to be a problem, either, now that modern
mailing list software knows how to play nice with DMARC, like e.g. this
very list does.  If you're on lists that don't do this, you should let
the list admin know about it, so they can fix their configuration.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

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

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

[Laura Atkins via mailop]

> On 3 Jun 2020, at 16:59, Robert L Mathews via mailop  
> wrote:
> 
> On 6/2/20 6:35 AM, Tim Bray via mailop wrote:
>> Is there way I could force my email address to be double opt in?
>> Like register with you, confirm my address, and then any of your
>> customers who try to add me, I get a `please confirm` email.
> 
> If large ESPs who consider themselves reputable added a consistent
> header saying whether the subscription had been confirmed ("double opt
> in"), that could be used in combination with DKIM source verification to
> provide positive and negative filtering.

You do know that spammers run ESPs and consider themselves reputable, yes? How 
useful will the header be when they start putting it in even when the mail 
isn’t confirmed? 

> Then Mailchimp and their customers could decide for themselves whether
> the improved inbox placement is worth the claimed hassle of double-opt-in.

Do you have evidence of the improved inbox placement? 

laura 

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

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

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







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

[mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Benoît Panizzon via mailop]

Hi Gang

Tanks for the various feedback, learning a log :-) I found one issue
caused by domain alignment in DMARC.

We use two domains:

imp.ch (our company)
breitband.ch (our service brand)

Our Support Case System (RT/3) uses a global configured envelope sender:
 but depending on the Queue, a different Header From:
supp...@breitband.ch

Did I get this right? This is not possible anymore when a DMARC
entry is published? The envelope sender domain and From: domain MUST be
aligned and in the case of 'strict' match, be identical and for
'relaxed' match may contain a subdomain?

There is now way to have different envelope and from domains?

I guess many ESP sending newsletters do the same, put their bounce
processor in the envelope from and a customer supplied From: Address
into the header.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Laura Atkins via mailop]

> On 4 Jun 2020, at 11:06, Benoît Panizzon via mailop  wrote:
> 
> Hi Gang
> 
> Tanks for the various feedback, learning a log :-) I found one issue
> caused by domain alignment in DMARC.
> 
> We use two domains:
> 
> imp.ch (our company)
> breitband.ch (our service brand)
> 
> Our Support Case System (RT/3) uses a global configured envelope sender:
>  but depending on the Queue, a different Header From:
> supp...@breitband.ch
> 
> Did I get this right? This is not possible anymore when a DMARC
> entry is published?

It is possible, if you are signing with a DKIM d= of the domain in the 
5321.from address. 

> The envelope sender domain and From: domain MUST be
> aligned and in the case of 'strict' match, be identical and for
> 'relaxed' match may contain a subdomain?

If you are relying solely on SPF authentication for DMARC then the 5321.from 
and the 5322.from need to be in the same domain. If you have a strict match 
designated in your DMARC record then the domains must match exactly. 

> There is now way to have different envelope and from domains?

You can have, and many senders do, have different envelope and from domains. In 
this case they’re either not authenticating the 5322.from with DMARC or they 
are relying on DKIM alignment for DMARC.

> I guess many ESP sending newsletters do the same, put their bounce
> processor in the envelope from and a customer supplied From: Address
> into the header.

There are different approaches ESPs use. But DMARC authentication can happen 
with DKIM *or* SPF passing and aligning. Many ESPs also have the customer use 
their own domain in the 5321.from, and then point that at their bounce 
handlers. 

laura

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

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

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







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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Andrew C Aitchison via mailop]

On Thu, 4 Jun 2020, Benoît Panizzon via mailop wrote:

[ Not replying to the list as this may be off topic,
  but you are welcome to bring it back on list if you wish. ]


Hi Gang

Tanks for the various feedback, learning a log :-) I found one issue
caused by domain alignment in DMARC.


Looking at the header of that email I noticed two other things, which
may not be relevant but do not look good:

Received: from thor.imp.ch ([157.161.4.18])
  by chilli.nosignal.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
  (Exim 4.84_2) (envelope-from ) id 1jgmmY-0005st-DM
  for mailop@mailop.org; Thu, 04 Jun 2020 11:07:36 +0100
Received: from chewbacca.woody.ch (wotan0.imp.ch [157.161.4.49])
  by thor.imp.ch (8.15.2/8.13.3) with ESMTPS id 054A6DNL098412
  version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
  for ; Thu, 4 Jun 2020 12:06:13 +0200 (CEST)
  (envelope-from benoit.paniz...@imp.ch)
X-Authentication-Warning: thor.imp.ch: Host wotan0.imp.ch [157.161.4.49]
  claimed to be chewbacca.woody.ch
Date: Thu, 4 Jun 2020 12:06:12 +0200
To: mailop@mailop.org

1. Exim 4.84_2 was released in March 2016.
The current release is 4.94 (warning: that has changes that mean you
*will* need to edit your exim config ...).

2. X-Authentication-Warning: ...
If your servers don't fully trust your machines ...
(I see that chewbacca.woody.ch is IPv6 only).

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Stuart Henderson via mailop]

On 2020/06/04 12:05, Andrew C Aitchison via mailop wrote:
> On Thu, 4 Jun 2020, Benoît Panizzon via mailop wrote:
> 
> [ Not replying to the list as this may be off topic,
>   but you are welcome to bring it back on list if you wish. ]

Unfortunately this is one of those mailing lists using modern software
that messes with From headers so that doesn't always go so well :)


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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Benoît Panizzon via mailop]

Hi Laura

> It is possible, if you are signing with a DKIM d= of the domain in
> the 5321.from address. 

We use only SPF at the moment. There are many systems which send emails
to 'external' recipients with the @imp.ch domain. It would take some
time to find ways to deploy DKIM in this very mixed environment.

So I guess using only SPF and DMARC with a reject policy will not work
if the envelope sender and from domain do not align.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Ken O'Driscoll via mailop]

On Thu, 2020-06-04 at 12:06 +0200, Benoît Panizzon via mailop wrote:
> Our Support Case System (RT/3) uses a global configured envelope
> sender: but depending on the Queue, a different
> Header From:supp...@breitband.ch

We use RT too and same problem if a queue is whitelabeled to use a
client domain for outsourced support. One kludge is to get the MTA to
re-write the 5321.From (side-wide return-path) based on the 5322.From
(queue From) for outbound and, to keep the bounce processor happy,
reverse it back to the site-wide one for inbound emails. There is
obviously a DNS component too which I'm not getting into.
Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[John Levine via mailop]

In article <20200604133652.13ea3...@chewbacca.woody.ch> you write:
>So I guess using only SPF and DMARC with a reject policy will not work
>if the envelope sender and from domain do not align.

If you can't reliably sign with a DKIM signature that matches the
From: domain, and you care if your mail gets delivered, you will be
very sad if you publish any DMARC policy other than p=none.

DMARC is not a magic bullet for all mail. It's an anti-phishing tool
designed for senders with specific mail profiles, and a big part of
the profile is being able to authenticate all of your mail in the
limited ways that DMARC handles.




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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[John Levine via mailop]

In article <20200604112224.gt65...@symphytum.spacehopper.org> you write:
>On 2020/06/04 12:05, Andrew C Aitchison via mailop wrote:
>> On Thu, 4 Jun 2020, Benoît Panizzon via mailop wrote:
>> 
>> [ Not replying to the list as this may be off topic,
>>   but you are welcome to bring it back on list if you wish. ]
>
>Unfortunately this is one of those mailing lists using modern software
>that messes with From headers so that doesn't always go so well :)

Good point.  Mailing lists have only been adding subject tags since the 1980s.


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

[mailop] SPF notification question

[Liam Fisher via mailop]

Quick question to the hive mind about SPF.What do you usually do for domains that have broken SPF records?  I mean the ones affecting your inbound to local delivery.Do you notify the sender and what's the usual process?

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

Re: [mailop] SPF notification question

[Jaroslaw Rafa via mailop]

Dnia  4.06.2020 o godz. 10:05:02 Liam Fisher via mailop pisze:
> What do you usually do for domains that have broken SPF records?  I
> mean the ones affecting your inbound to local delivery.

Well, as SPF is a fundamentally flawed idea, I don't check SPF (nor DKIM,
nor DMARC) at all on incoming mail. I only use them on outbound mail, mostly
to satisfy Google ;).

In my opinion, the only case you should care about SPF is when a domain
publishes "-all" as the ONLY entry in the SPF record, ie. it indicates that
it doesn't send mail at all. (But I don't even bother to check this :)) 

I rather like to rely on old fashioned methods like RBLs, manual black/white
lists and content analysis for spam filtering.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

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

Re: [mailop] SPF notification question

[Michael Rathbun via mailop]

On Thu, 4 Jun 2020 10:05:02 -0400 (GMT-04:00), Liam Fisher via mailop
 wrote:

>What do you usually do for domains that have broken SPF records?

SpamAssassin adds 7.5 points, enough for classification as spam, absent any
mitigating factors.  This is generally a desired outcome.

>Do you notify the sender and what's the usual process?

I can't imagine doing that.  There would be hundreds of notifications daily to
domains used once by spammers (or misused by spammers) with no practical
outcome that I can perceive.  And my day job is our customers' deliverability.

mdr
-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella


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

Re: [mailop] SPF notification question

[Michael Peddemors via mailop]

Wow! Open ended question, and also depends on the SPF record..

Some you WANT to block at the edge (aside from the whole email 
forwarding thing) and some you may simply want to filter.


But by rejecting, that IS a notification .. hehehe..

However, for many individuals out there trying their best to run an 
email server, they have a hard enough time getting DNS right... let 
alone SPF..


This is where is is probably best to 'be kind to the animals'.. UNLESS 
of course, it is something important that is likely to get 
forged/faked/phished like a bank.


But in reality, most of us are too busy to spend time on reporting.. 
Assume if it is broken, they will notice pretty quickly anyways.. The 
big guys rejecting your email is often when people first start looking 
at SPF..


But during this difficult time, we want to be nice to our neighbours 
when we can be, and phishing attack rates never higher.. So, if you can 
spare the cycles.. sure.. why not..


But when a bank screws up on their SPF.. yeah, the best thing is to 
block them, and that will get their attention ;)  For them, we need to 
set them to higher standards.. IMHO


Other opinions?

On 2020-06-04 7:05 a.m., Liam Fisher via mailop wrote:

Quick question to the hive mind about SPF.


What do you usually do for domains that have broken SPF records?  I mean 
the ones affecting your inbound to local delivery.


Do you notify the sender and what's the usual process?

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

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

604-682-0300 Beautiful British Columbia, Canada

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

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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Laura Atkins via mailop]

> On 4 Jun 2020, at 12:36, Benoît Panizzon  wrote:
> 
> Hi Laura
> 
>> It is possible, if you are signing with a DKIM d= of the domain in
>> the 5321.from address. 
> 
> We use only SPF at the moment. There are many systems which send emails
> to 'external' recipients with the @imp.ch domain. It would take some
> time to find ways to deploy DKIM in this very mixed environment.
> 
> So I guess using only SPF and DMARC with a reject policy will not work
> if the envelope sender and from domain do not align.

Alignment is the underlying DMARC mechanism. No alignment == no DMARC. 

laura 

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

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

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







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

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

[Luke via mailop]

I cant tell if this the thing about ESPs not removing bounces is a joke or
not. All of the major ESPs have logic for adding bad addresses to
suppression lists. Of course their users can choose to unsuppress, but ESPs
certainly remove bounces. Seems like most people here should know this.
Maybe I'm missing something about your comment?

On Wed, Jun 3, 2020, 11:30 PM Atro Tossavainen via mailop 
wrote:

> > For me, it was noticing how, despite getting 550'd for an extended
> period of
> > time, Mailchimp just keeps hammering away at the address, never dropping
> it
> > from the list.  That, too, is not the behaviour of a responsible ESP.
>
> As I keep saying, we would not have a business at all if any ESPs actually
> removed bounces. So thank you to everyone who doesn't. If there are
> entities that do, I don't know which ones they are. :-D
>
> Way back when, some people who are also on this list kept complaining
> that simply keeping domains registered without an A and MX (causing
> NXDOMAIN for mail delivery) is not a proper bounce, because you (as the
> sending entity) are somehow not able to trust the results your own
> servers produce, but have to get third party validation for the fact
> that an address doesn't exist (which I think is totally bass-ackwards),
> but anyway, we started 550 5.1.1'ing addresses during the timeout period
> of new domains we acquire, and still, no change.
>
> There is also the issue that anything that Operator X finds out while
> processing data for Customer X1 cannot apply to Customer X2 because
> anything to the contrary makes Operator X a DATA CONTROLLER in their
> own right from the perspective of the GDPR and what did I say about
> that just a few messages ago?
>
> --
> Atro Tossavainen, Founder, Partner
> Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
> Tallinn, Estonia
> tel. +372-5883-4269, http://www.koliloks.eu/
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Ralph Seichter via mailop]

* John Levine via mailop:

> Mailing lists have only been adding subject tags since the 1980s.

I do not wish to delve into whether these tags are useful or not, but
rewriting subjects or bodies invalidate existing DKIM signatures.

I recommend using separate domains, or subdomains, for regular business
and for mailing lists, combined with separate DMARC policies, e.g.
'quarantine' for example.org and 'none' for mlists.example.org.

-Ralph

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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Alan Hodgson via mailop]

On Thu, 2020-06-04 at 13:36 +0200, Benoît Panizzon via mailop wrote:
> 
> So I guess using only SPF and DMARC with a reject policy will not work
> if the envelope sender and from domain do not align.

Using DMARC p=reject without DKIM is broken anyway. You cannot control
how or where your recipients forward their email (and I promise you many
of them forward it to Gmail from IP addresses that are not in your SPF
record).
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Robert L Mathews via mailop]

On 6/4/20 2:50 AM, Laura Atkins via mailop wrote:
> You do know that spammers run ESPs and consider themselves reputable,
> yes? How useful will the header be when they start putting it in even
> when the mail isn’t confirmed? 

My point was that if a large ESP started doing this, *and* the ESP did
it reliably and honestly, *and* receiving entities noticed and believed
that the ESP did it reliably and honestly, then a receiving entity could
decide to start weighting that header positively for mail from that ESP.

I wasn't suggesting that anyone would trust such a header without strong
evidence that a particular ESP was doing it reliably and honestly.

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

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

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

[Laura Atkins via mailop]

> On 4 Jun 2020, at 16:55, Robert L Mathews via mailop  
> wrote:
> 
> On 6/4/20 2:50 AM, Laura Atkins via mailop wrote:
>> You do know that spammers run ESPs and consider themselves reputable,
>> yes? How useful will the header be when they start putting it in even
>> when the mail isn’t confirmed? 
> 
> My point was that if a large ESP started doing this, *and* the ESP did
> it reliably and honestly, *and* receiving entities noticed and believed
> that the ESP did it reliably and honestly, then a receiving entity could
> decide to start weighting that header positively for mail from that ESP.
> 
> I wasn't suggesting that anyone would trust such a header without strong
> evidence that a particular ESP was doing it reliably and honestly.

What is your mechanism for that trust? If the answer is “someone will figure it 
out” then there’s no point in even suggesting such a header. No one will bother 
implementing such a header until there’s a mechanism and no one is going to 
spend their time figuring out how to make your suggestion work. 

I will also say there is such a thing as spam to a COI address. Like, I 
confirmed my subscription to one retailers list and they start mailing me 
advertising for a different brand of theirs (has happened). Or I confirm my 
subscription to one company and they go out of business and sell off their COI 
list to the highest bidder (has happened). Or I confirm my address for one type 
of email and the brand decides to expand their marketing and send me mail for a 
completely different thing (has happened). Or I confirm my address and then 
unsubscribe but the company changes ESPs and forgets to take their unsub list 
with them. 

The underlying issue is unless what you’re proposing can address those very 
normal and common cases, there’s no point in the header itself.

laura 

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

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

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







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

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

[Robert L Mathews via mailop]

On 6/4/20 9:10 AM, Laura Atkins via mailop wrote:
> What is your mechanism for that trust? If the answer is “someone will
> figure it out” then there’s no point in even suggesting such a header.

Well, I would disagree with that, actually. Much of this is automated on
the recipient end at large receivers, and if it so happens that messages
from a certain large ESP that contain a certain header are only half as
likely to be manually flagged as spam as other messages from that ESP,
that would be likely to show up in a bayesian/AI classification system.

In general, it's in the interest of senders to provide *any* clues they
can that certain messages they send are more likely to be legitimate. It
doesn't need to be a header; a large ESP signing COI messages with a
different DKIM selector would be a similar clue that could be used.
Differentiation of mail stream types helps everyone.

Even on the human side, it seems people spend vast amounts of time
looking for clues about mail they can use to filter it -- I've seen
people trying to guess whether certain ESP mail is COI or not based on
the sending IP address ranges. If people are willing to do things like
that, I think they'd be willing to use any other clues reputable senders
provide.

But I may be wrong.


>I will also say there is such a thing as spam to a COI address.

Yes, definitely. Doing such a thing would be unhelpful to the sender,
because it would make systems trust the "clue" from that sender less
than they otherwise would.

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

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

[mailop] Attention Michael Wise - need your assistance

[Marc Goldman via mailop]

Hi Michael, 

I sent you an email the other day (that may have been overlooked) 

Have a case (SRX1502275554ID) that I asked you to check on for me that was 
denied mitigation even though we just took over this 1 IP a week ago.

You can contact me off list for anything you need.

Thanks!

Marc Goldman

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

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

[Andrew Wingle via mailop]

https://en.wikipedia.org/wiki/Evil_bit

Also
>In general, it's in the interest of Spammers to provide *any* clues they can 
>that certain messages they send are more likely to be legitimate

FTFY

-Andrew 

-Original Message-
From: mailop  On Behalf Of Robert L Mathews via 
mailop
Sent: Thursday, June 04, 2020 1:44 PM
To: mailop@mailop.org
Subject: Re: [mailop] Force double opt in for marketing list companies per 
email address

On 6/4/20 9:10 AM, Laura Atkins via mailop wrote:
> What is your mechanism for that trust? If the answer is “someone will 
> figure it out” then there’s no point in even suggesting such a header.

Well, I would disagree with that, actually. Much of this is automated on the 
recipient end at large receivers, and if it so happens that messages from a 
certain large ESP that contain a certain header are only half as likely to be 
manually flagged as spam as other messages from that ESP, that would be likely 
to show up in a bayesian/AI classification system.

In general, it's in the interest of senders to provide *any* clues they can 
that certain messages they send are more likely to be legitimate. It doesn't 
need to be a header; a large ESP signing COI messages with a different DKIM 
selector would be a similar clue that could be used.
Differentiation of mail stream types helps everyone.

Even on the human side, it seems people spend vast amounts of time looking for 
clues about mail they can use to filter it -- I've seen people trying to guess 
whether certain ESP mail is COI or not based on the sending IP address ranges. 
If people are willing to do things like that, I think they'd be willing to use 
any other clues reputable senders provide.

But I may be wrong.


>I will also say there is such a thing as spam to a COI address.

Yes, definitely. Doing such a thing would be unhelpful to the sender, because 
it would make systems trust the "clue" from that sender less than they 
otherwise would.

--
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

___
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] Force double opt in for marketing list companies per email address

[Matthew Grove via mailop]

Hi,

Just to clarify, Mailchimp does remove addresses from specific lists when
we receive a hard bounce. Atro is correct; we do not suppress hard bounced
addresses globally across all of our users for a number of reasons. Each
user's list is self contained in that respect.

In the past, allowing each user to bounce an address independently has
caused some receivers to believe that we are not responding to hard bounces
at all. That's not true, but I definitely understand where the perception
is coming from.

Of course, there is always a remote possibility that some misconfiguration
on our side is causing us to reclassify your specific bounce message. You
can compare our *X-MC-User* header to verify that we are not suppressing
the address at the user level. If you think this might be the case, feel
free to reach out to me off-list, and we'll troubleshoot the issue.

Then again, if you are looking for global suppression, you can reach out to
our abuse team to see if that can be arranged.


Cool,
Matthew
delivery.mailchimp.com


On Thu, Jun 4, 2020 at 11:13 AM Luke via mailop  wrote:

> I cant tell if this the thing about ESPs not removing bounces is a joke or
> not. All of the major ESPs have logic for adding bad addresses to
> suppression lists. Of course their users can choose to unsuppress, but ESPs
> certainly remove bounces. Seems like most people here should know this.
> Maybe I'm missing something about your comment?
>
> On Wed, Jun 3, 2020, 11:30 PM Atro Tossavainen via mailop <
> mailop@mailop.org> wrote:
>
>> > For me, it was noticing how, despite getting 550'd for an extended
>> period of
>> > time, Mailchimp just keeps hammering away at the address, never
>> dropping it
>> > from the list.  That, too, is not the behaviour of a responsible ESP.
>>
>> As I keep saying, we would not have a business at all if any ESPs actually
>> removed bounces. So thank you to everyone who doesn't. If there are
>> entities that do, I don't know which ones they are. :-D
>>
>> Way back when, some people who are also on this list kept complaining
>> that simply keeping domains registered without an A and MX (causing
>> NXDOMAIN for mail delivery) is not a proper bounce, because you (as the
>> sending entity) are somehow not able to trust the results your own
>> servers produce, but have to get third party validation for the fact
>> that an address doesn't exist (which I think is totally bass-ackwards),
>> but anyway, we started 550 5.1.1'ing addresses during the timeout period
>> of new domains we acquire, and still, no change.
>>
>> There is also the issue that anything that Operator X finds out while
>> processing data for Customer X1 cannot apply to Customer X2 because
>> anything to the contrary makes Operator X a DATA CONTROLLER in their
>> own right from the perspective of the GDPR and what did I say about
>> that just a few messages ago?
>>
>> --
>> Atro Tossavainen, Founder, Partner
>> Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
>> Tallinn, Estonia
>> tel. +372-5883-4269, http://www.koliloks.eu/
>>
>> ___
>> 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] Handling of Hard Bounces - Topic Change

[Michael Peddemors via mailop]

On 2020-06-04 12:08 p.m., Matthew Grove via mailop wrote:

Hi,

Just to clarify, Mailchimp does remove addresses from specific lists 
when we receive a hard bounce. Atro is correct; we do not suppress hard 
bounced addresses globally across all of our users for a number of 
reasons. Each user's list is self contained in that respect.


More for my curiosity than anything else.. Let's assume that MailChimp 
has a spam outbreak, an ISP or RBL adds the IP address, and the 
receiving MTA treats it with a hard bounce (5.XX).


On your 'shared' flows, then all other streams, not only the offending 
list, would also get the hard bounce.. do you remove everyone that gets 
the 5.xx at that point?


Isn't there some form of 'second effort', eg record the number of 5.xx 
received from emails directed to that recipient? To deal with temporary 
problems, such as MTA system misconfiguration, resource exhaustion that 
might also generate a 5.xx hard bounce?


Then again, if you are looking for global suppression, you can reach out 
to our abuse team to see if that can be arranged.


Aside from putting that work load on the recipient, there will always be 
some innocents with legitimate notifications that sign up with 
MailChimp, you have good sales teams ;) And maybe one of the future ones 
will be important.. and if they DID want global suppression, I think it 
would be easier for the user/admin to simply block it at their end ;)


But, as a previous poster pointed out, transparency is key..


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

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

604-682-0300 Beautiful British Columbia, Canada

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

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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[John Levine via mailop]

In article <871rmukg4q@wedjat.horus-it.com> you write:
>* John Levine via mailop:
>
>> Mailing lists have only been adding subject tags since the 1980s.
>
>I do not wish to delve into whether these tags are useful or not, but
>rewriting subjects or bodies invalidate existing DKIM signatures.

Yes, we knew that 15 years ago when we published the DKIM specs.

>I recommend using separate domains, or subdomains, for regular business
>and for mailing lists, combined with separate DMARC policies, e.g.
>'quarantine' for example.org and 'none' for mlists.example.org.

I agree that it is not a great idea to mix mailing lists and other
correspondence in the same domain. It is equally a bad idea to mix
mailboxes used by actual people and role addresses that send bulk mail.


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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Brandon Long via mailop]

On Thu, Jun 4, 2020 at 8:28 AM Ralph Seichter via mailop 
wrote:

> * John Levine via mailop:
>
> > Mailing lists have only been adding subject tags since the 1980s.
>
> I do not wish to delve into whether these tags are useful or not, but
> rewriting subjects or bodies invalidate existing DKIM signatures.
>
> I recommend using separate domains, or subdomains, for regular business
> and for mailing lists, combined with separate DMARC policies, e.g.
> 'quarantine' for example.org and 'none' for mlists.example.org.
>

Why?

For one, I'm not sure what you're recommending, either:
1) Host mailing lists on a separate domain
2) Send mail to mailing lists on a separate domain

If you're recommending #1, sure, there are benefits to that, though it's
clearly not strictly necessary.  Having a different DMARC policy
for the mailing list domain isn't that useful since the mailing list sends
very few messages "from" the mailing list (slightly more in the case of
5322.From header rewriting, of course).  It's also usually a fairly
controlled domain only used for the mailing list software, so making sure
the SPF and DKIM are correct is pretty trivial, so the looser DMARC setting
doesn't seem to make much sense.

If you're talking about #2, I probably wouldn't recommend that breakdown,
but I do know folks who have split domains for the "product" and the
employees, ie yahoo.com vs yahoo-corp.com, foo.net vs foo.com, etc.  We
played with that a bit when we were first rolling out DMARC predecessor,
adding a googlers.com domain.  Ultimately, we decided that leaving a domain
open that can be spoofed defeats the purpose of DMARC.  I mean, it also
points to the ultimate problem with DMARC, which is people fall for
phishing even from non-exact or even completely wrong domains, so all of
this is just about moving the needle and not SOLVING THE PROBLEM ONCE AND
FOR ALL, so everything is a continuum and everyone needs to understand and
make the right choices for them.

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

Re: [mailop] Handling of Hard Bounces - Topic Change

[Matthew Grove via mailop]

>More for my curiosity than anything else.. Let's assume that MailChimp
>has a spam outbreak, an ISP or RBL adds the IP address, and the
>receiving MTA treats it with a hard bounce (5.XX).
>
>On your 'shared' flows, then all other streams, not only the offending
>list, would also get the hard bounce.. do you remove everyone that gets
>the 5.xx at that point?

We assign an "activity score" to every email address. This score increases
with opens and clicks, and it decreases in the absence of opens and clicks.
Email addresses with a positive activity score will not be removed on the
first hard bounce. Instead, that hard bounce will set the email address's
activity score to 0. A second hard bounce would then cause the address to
be removed from the list.

Additionally, we make an attempt to reclassify certain hard bounces that go
out of their way to implicate an issue unrelated to the validity of the
email address or the signup. For instance, some bounce messages
indicate spam content or phishing links. Feeding those kinds of bounce
messages into the regular process that simply removes an address from a
list would not be very effective for identifying and removing malicious
email. To your point, bounces that indicate IP blocks would also negatively
impact users who were not guilty of sending spam over that shared IP.

So to answer your question, we have a few ways of addressing hard bounces
when those bounce messages indicate the validity of the email address and
the signup are not under dispute.

>Isn't there some form of 'second effort', eg record the number of 5.xx
>received from emails directed to that recipient? To deal with temporary
>problems, such as MTA system misconfiguration, resource exhaustion that
>might also generate a 5.xx hard bounce?

So starting at the bottom... A lot of bounces that result from
misconfiguration or resource exhaustion will cause deferrals which our
system treats differently than what we call hard and soft bounces. A bounce
means that we will stop trying to send a particular piece of content from a
particular user to a particular email address, and we may take further
action to modify the status of the email address on the user's list. When
we get a deferral message, we stop trying to deliver any email to the
deferred domain from that sending IP for a period of time. Any emails
queued up for that domain on the sending IP will just sit around. We will
retry to send email in this queue after a few minutes or a few hours. After
a period of days and several attempts to send again, any email that hasn't
been sent is removed from the queue.

To answer the top part of that question... We do have a tool that records,
on a company-wide level, which addresses have bounced in the past. No, we
do not use this tool for suppression or list washing. We use this tool to
predict bounce rates on new lists. An interesting note about this bounce
prediction tool is that it is extremely unreliable on a per email address
basis. This means we're very bad at predicting whether a specific email
address will bounce in the future just because we've seen it bounce in the
past. However, when the results are aggregated at the list level, we can
predict a hard bounce rate within 1% +/-.

>Aside from putting that work load on the recipient

I'd like to think our anti-abuse efforts mean that a lot of recipients
don't have to do anything to avoid receiving unwanted mail from us. We have
multiple teams with lots of passionate individuals who put in 40+ hours
a week on preventing and stopping abuse. It truly is one of our top
priorities, but it's highly unlikely that we'll eliminate abuse entirely.
There will always be recipients who need to reach out to us and let us know
what they want. We do our best.

For what it's worth, the request that spurred this conversation asked if we
could quarantine certain addresses any time they were added to a list and
only lift the quarantine once the user received a DOI confirmation.
Honestly, it's a great idea that solves a real problem with
our current global opt-out requests. I'm not 100% sure it would play nicely
with all of our legal obligations, but it's worth investigating.
Implementation is actually more complicated than you might imagine, so I
wouldn't count on it getting done any time soon. It is a great idea though.

>you have good sales teams ;)

As far as I know, we still don't have a sales team. There's just a lot of
small businesses out in the world.

>... and if they DID want global suppression, I think it
>would be easier for the user/admin to simply block it at their end ;)

Here's a list of our IPs  which we
publish so people can whitelist or block them as they see fit. To quote
that page, "Our servers deliver more than 1 billion newsletters every day,
so we work very hard to keep abuse out of our system and maintain high
overall deliverability. Nobody's perfect, but we like to think we try the
hardest."

So anyway, I hope I

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Eric Tykwinski via mailop]

Yeah, I agree on the split domain, we’ve had enough trouble with customers 
getting fooled with off domains.  
IE F1SERV.COM  instead of fiserv.com , 
et al…  There’s enough there in the font specification that I know most coders 
still trying to find their own font of choice.

PS. I use Bespin coloring, and Dejavu font.
https://www.fontsquirrel.com/fonts/dejavu-sans-mono 

https://wiki.mozilla.org/Labs/Bespin/UserGuide 


Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Jun 4, 2020, at 6:36 PM, Brandon Long via mailop  wrote:
> 
> 
> 
> On Thu, Jun 4, 2020 at 8:28 AM Ralph Seichter via mailop  > wrote:
> * John Levine via mailop:
> 
> > Mailing lists have only been adding subject tags since the 1980s.
> 
> I do not wish to delve into whether these tags are useful or not, but
> rewriting subjects or bodies invalidate existing DKIM signatures.
> 
> I recommend using separate domains, or subdomains, for regular business
> and for mailing lists, combined with separate DMARC policies, e.g.
> 'quarantine' for example.org  and 'none' for 
> mlists.example.org .
> 
> Why? 
> 
> For one, I'm not sure what you're recommending, either:
> 1) Host mailing lists on a separate domain
> 2) Send mail to mailing lists on a separate domain 
> 
> If you're recommending #1, sure, there are benefits to that, though it's 
> clearly not strictly necessary.  Having a different DMARC policy
> for the mailing list domain isn't that useful since the mailing list sends 
> very few messages "from" the mailing list (slightly more in the case of 
> 5322.From header rewriting, of course).  It's also usually a fairly 
> controlled domain only used for the mailing list software, so making sure the 
> SPF and DKIM are correct is pretty trivial, so the looser DMARC setting 
> doesn't seem to make much sense.
> 
> If you're talking about #2, I probably wouldn't recommend that breakdown, but 
> I do know folks who have split domains for the "product" and the employees, 
> ie yahoo.com  vs yahoo-corp.com , 
> foo.net  vs foo.com , etc.  We played with 
> that a bit when we were first rolling out DMARC predecessor, adding a 
> googlers.com  domain.  Ultimately, we decided that 
> leaving a domain open that can be spoofed defeats the purpose of DMARC.  I 
> mean, it also points to the ultimate problem with DMARC, which is people fall 
> for phishing even from non-exact or even completely wrong domains, so all of 
> this is just about moving the needle and not SOLVING THE PROBLEM ONCE AND FOR 
> ALL, so everything is a continuum and everyone needs to understand and make 
> the right choices for them.
> 
> Brandon
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Ralph Seichter via mailop]

* Brandon Long:

>> I recommend using separate domains, or subdomains, for regular
>> business and for mailing lists [...]
>
> Why?

Because something is definitely wron if an email from ra...@mycorp.com
(an address only used for business) fails SPF or DKIM checks, and I'd
like to know about that.

Mail from ra...@ml.mycorp.com however, an address only used for mailing
lists but not for business, can fail these checks due to sub-optimal ML
software setups or other reasons, and it does not worry me much.

> For one, I'm not sure what you're recommending, either:
> 1) Host mailing lists on a separate domain
> 2) Send mail to mailing lists on a separate domain

Both, actually. I host mailing lists aswell, and continuing the example
above, they use the domain lists.mycorp.com.

> We played with that a bit when we were first rolling out DMARC
> predecessor, adding a googlers.com domain. Ultimately, we decided
> that leaving a domain open that can be spoofed defeats the purpose of
> DMARC.

I cannot speak for others, but a sender address like al...@google.com or
b...@microsoft.com does not normally signal "the author is more competent
or important than others" to me. This particular mailing list may be an
exception, but generally speaking, I don't usually care who somebody
works for, as long as his/her ML contributions are solid. That's why, in
the ML context, I don't see spoofing as much of a threat and am content
with using a (sub)domain with a "p=none" DMARC policy.

> everything is a continuum and everyone needs to understand and make
> the right choices for them.

DMARC and its underlying mechanisms indeed have shortcomings, and my
recommendation helps to circumvent these. There are mailing lists like
postfix-users which wisely don't break DKIM sigs, and there are others
that consider subject prefixes and body footers more important. For me,
using separate (sub)domains is a working solution, and a cheap one at
that. Right now I use a private domain, because I am speaking only for
myself, but if I need to subscribe to a ML where I represent my company,
a subdomain will do for me.

YMMV, of course, and any person who runs mail servers indeed needs to
understand what they are doing.

-Ralph

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

[mailop] Strange information upon SMTP connection to icloud email server

[Frank Bulk via mailop]

I was reviewing the details on an email deliverability error and I saw the
following recorded by our "check script" when connecting to an icloud.com MX
record:
===
Trying 17.57.154.7...

Connected to 17.57.154.7.

Escape character is '^]'.

2020 Jun  4 18:20:48 10.15.194.199 message repeated 82 times: [ BCMSDK -
unit 0 MMU subblock 12   reg EMC_ERROR_1 field
EMC_CSDB_2_UPPER_BUFFER_UNCORRECTED_ERROR(value = 0x800) has  MMU parity
error]
2020 Jun  4 18:20:49 10.15.194.199 BCMSDK - unit 0 MMU subblock 12   reg
EMC_ERROR_1 field EMC_CSDB_2_UPPER_BUFFER_UNCORRECTED_ERROR(value =
0x800) has MMU parity error


Timeout connecting to '17.57.154.7'
connecting to an icloud.com MX record
===

Frank


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

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

[Matt Palmer via mailop]

On Thu, Jun 04, 2020 at 03:08:47PM -0400, Matthew Grove via mailop wrote:
> Just to clarify, Mailchimp does remove addresses from specific lists when
> we receive a hard bounce. Atro is correct; we do not suppress hard bounced
> addresses globally across all of our users for a number of reasons. Each
> user's list is self contained in that respect.

And yet, I 554'd all of Mailchimp's address space for, oh, probably the
better part of a year, at least, yet when I pulled it out of the swamp
because of one e-mail I wanted to receive, all the same "newsletters" I'd
been receiving before, which I'd never signed up for in the first place,
started flooding in again.

- Matt


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

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

[Matt Palmer via mailop]

On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke via mailop wrote:
> I cant tell if this the thing about ESPs not removing bounces is a joke or
> not. All of the major ESPs have logic for adding bad addresses to
> suppression lists.

[Citation needed]

Your assertion does not match my data.

- Matt


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

Re: [mailop] Strange information upon SMTP connection to icloud email server

[Brandon Applegate via mailop]

On Thu, Jun 4, 2020 at 8:20 PM Frank Bulk via mailop  wrote:
>
> I was reviewing the details on an email deliverability error and I saw the
> following recorded by our "check script" when connecting to an icloud.com MX
> record:
> ===
> Trying 17.57.154.7...
>
> Connected to 17.57.154.7.
>
> Escape character is '^]'.
>
> 2020 Jun  4 18:20:48 10.15.194.199 message repeated 82 times: [ BCMSDK -
> unit 0 MMU subblock 12   reg EMC_ERROR_1 field
> EMC_CSDB_2_UPPER_BUFFER_UNCORRECTED_ERROR(value = 0x800) has  MMU parity
> error]
> 2020 Jun  4 18:20:49 10.15.194.199 BCMSDK - unit 0 MMU subblock 12   reg
> EMC_ERROR_1 field EMC_CSDB_2_UPPER_BUFFER_UNCORRECTED_ERROR(value =
> 0x800) has MMU parity error
>
>
> Timeout connecting to '17.57.154.7'
> connecting to an icloud.com MX record
> ===
>

Wow, looks like maybe a NIC error message (I’m guessing this based on
the “BCMSDK” - Broadcom SDK ?) “bled over” into the smtp connection ?
How does that even happen ?  Some sort of TCP offload on the host tied
in a knot ?

Dumb question - forgive me in advance - this wouldn't be from
something on your side (i.e. your monitoring box) ?  I guess if
10.15.194.199 isn't one of your IP's internally the answer would be
no...

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

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

[Luke via mailop]

SendGrid 

SparkPost


MailChimp 

MailGun


Salesforce


DotDigital



Please name an ESP and I'll add to the list.

To be honest, I'm not proud of myself for dignifying this nonsense with a
response. I think you should be ashamed of yourself for *pretending* you
don't know that ESPs suppress invalid email addresses. This is a mailing
list with people of all kinds of experience levels in this industry. When
lurkers see someone bold enough to post something here, they assume some
level of authority and respect. When someone says something like "ESPs
don't suppress invalid addressed" many people will just assume it is true.
"Who would say something like this on a mailing list if it wasn't true?"
You need to take a deep breath, chill, and reevaluate your approach to
defending the world from spam. This is not productive. In fact, it's almost
like you're gaslighting ESPs and the people who work for them. Pretty
remarkable stuff actually. I hope you come around.

Cheers,
Luke


On Thu, Jun 4, 2020 at 5:30 PM Matt Palmer via mailop 
wrote:

> On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke via mailop wrote:
> > I cant tell if this the thing about ESPs not removing bounces is a joke
> or
> > not. All of the major ESPs have logic for adding bad addresses to
> > suppression lists.
>
> [Citation needed]
>
> Your assertion does not match my data.
>
> - Matt
>
>
> ___
> 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] Force double opt in for marketing list companies per email address

[Matt Palmer via mailop]

On Thu, Jun 04, 2020 at 06:06:25PM -0700, Luke wrote:
> > On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke via mailop wrote:
> > > I cant tell if this the thing about ESPs not removing bounces is a joke
> > or
> > > not. All of the major ESPs have logic for adding bad addresses to
> > > suppression lists.
> >
> > [Citation needed]
> >
> > Your assertion does not match my data.

[snip URLs]

OK, I walked into that one.

> To be honest, I'm not proud of myself for dignifying this nonsense with a
> response. I think you should be ashamed of yourself for *pretending* you
> don't know that ESPs suppress invalid email addresses.

I'm not pretending anything.  I'm extrapolating from data.  You're... I
don't even know.

> You need to take a deep breath, chill, and reevaluate your approach to
> defending the world from spam. This is not productive. In fact, it's almost
> like you're gaslighting ESPs and the people who work for them.

There's definitely some gaslighting going on here, but it's not what you
seem to think it is.  When I see a never-ending stream of 554 responses in
my logs to delivery attempts from Mailchimp IP addresses, to an e-mail
address that was only provided to one organisation (and that organisation
was not, I might add, Mailchimp), and then get told "Mailchimp suppresses
invalid email addresses"... that's gaslighting right there.  You are
denying the existence of the evidence sitting right in front of me.

> Pretty remarkable stuff actually.  I hope you come around.

Right back atcha, champ.

- Matt


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

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

[Luke via mailop]

This is wonderful. Thanks for the reply.


On Thu, Jun 4, 2020, 6:55 PM Matt Palmer via mailop 
wrote:

> On Thu, Jun 04, 2020 at 06:06:25PM -0700, Luke wrote:
> > > On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke via mailop wrote:
> > > > I cant tell if this the thing about ESPs not removing bounces is a
> joke
> > > or
> > > > not. All of the major ESPs have logic for adding bad addresses to
> > > > suppression lists.
> > >
> > > [Citation needed]
> > >
> > > Your assertion does not match my data.
>
> [snip URLs]
>
> OK, I walked into that one.
>
> > To be honest, I'm not proud of myself for dignifying this nonsense with a
> > response. I think you should be ashamed of yourself for *pretending* you
> > don't know that ESPs suppress invalid email addresses.
>
> I'm not pretending anything.  I'm extrapolating from data.  You're... I
> don't even know.
>
> > You need to take a deep breath, chill, and reevaluate your approach to
> > defending the world from spam. This is not productive. In fact, it's
> almost
> > like you're gaslighting ESPs and the people who work for them.
>
> There's definitely some gaslighting going on here, but it's not what you
> seem to think it is.  When I see a never-ending stream of 554 responses in
> my logs to delivery attempts from Mailchimp IP addresses, to an e-mail
> address that was only provided to one organisation (and that organisation
> was not, I might add, Mailchimp), and then get told "Mailchimp suppresses
> invalid email addresses"... that's gaslighting right there.  You are
> denying the existence of the evidence sitting right in front of me.
>
> > Pretty remarkable stuff actually.  I hope you come around.
>
> Right back atcha, champ.
>
> - Matt
>
>
> ___
> 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 Outlook "Modern Authentication"?

[Daniele Nicolodi via mailop]

On 02/06/2020 02:41, Andrew C Aitchison via mailop wrote:
> 
> On Thu, 28 May 2020, Daniele Nicolodi asked:
>> The IT department of the organization that is pushing thins says that
>> modern authentication and disabling IMAP (over SSL) enhance security.
>> I don't see how this is the case. Does anyone have an opinion?
> 
> Phil Pennock replied:
> PP> As to IMAP/TLS -- I know of no security reason to mandate disabling 
> PP> IMAP as opposed to any other access protocol.  This sounds more like 
> PP> the traditional Outlook FUD-spreading re open protocols.
> 
> For the 95% or more of users who only use Microsoft clients and thus
> don't use IMAP, disabling IMAP means that dictionary attacks over
> ports 143 or 993 are impossible.

I don't see the gain as the same attacks are possible over a different
protocol. I don't think that eliminating IMAP (and keeping SMTP
submission as far as I know) reduces the attack surface. Am I missing
something?

Cheers,
Dan

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

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Benoît Panizzon via mailop]

> Using DMARC p=reject without DKIM is broken anyway. You cannot control
> how or where your recipients forward their email (and I promise you
> many of them forward it to Gmail from IP addresses that are not in
> your SPF record).

Yes this is why SRS is being used to re-write the envelope sender...

...which in turn probably breaks DMARC domain alignment I guess.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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

Re: [mailop] Google: 'Low reputation of the sending domain'

[Benoît Panizzon via mailop]

Hi Gang

After some more valuable feedback I got on that topic, it is now
pretty obvious how I destroyed the google reputation of that 'sending
domain'.

I learned that Google:

IPv4: Works with IP Reputation.
IPv6: Works with 'sender domain' Reputation.

Sender Domain is not just the 'domain' of the sender, but if there is
an issue with a sub-domain which has 'high traffic' this affects the
'base domain' with lower traffic too.

Well, I happen to run the development version of the SWINOG
spamtrap / honeypot / blacklist / feedback Loop infrastructure on
blacklist.woody.ch / gintonic.woody.ch.

Different subdomain / different IP-Address than the one blocked.

I noticed in the past, that feedback loop email, containing a
multipart/report MIME-Type and ARF structure were often blocked
as 'spam' by google (yes digitalocean abuse desk, you are hosted on
ASPX and still getting multiple feedback emails because of spamtrap /
honeypot hits per day). I asked the google abuse-desk repeatedly to not
block such emails, especially not if the destination was listed as
abuse-mailbox in the registries. Well I guess they ignored my requests
and those emails, being considered spam lead to my domain's reputation
to be pulled down so far all traffic is being blocked now.

Well, I guess I have to stop sending feedback emails for now and
migrate everything to a different domain.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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