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

[Ralph Seichter via mailop]

* Al Iverson via mailop:

> Sorry, Ralph, you're really on the wrong track here.

I'm OK with agreeing to disagree, and the discussion in itself has merit
even if we have different opinions. I did not claim that my method is
suitable for each and every case, however I do know it works nicely for
the scenarios I have had to deal with so far.

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

[Al Iverson via mailop]

On Fri, Jun 5, 2020 at 6:14 PM Brandon Long  wrote:

>> This is silly. Stop pushing this.
>>
>> If every Googler started posting from monksofcool.net then there would
>> grow, over time, a population of people who understood that this was a
>> Googler domain and those people could potentially be a prime spear
>> phishing target.
>
> The biggest hole will be for spear phishing, in fact, where another Googler 
> is the
> target.

YEP. File under bad ideas. Sorry, Ralph, you're really on the wrong track here.

Al


-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com

___
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 Fri, Jun 5, 2020 at 2:25 PM Al Iverson via mailop 
wrote:

> On Fri, Jun 5, 2020 at 2:41 PM Ralph Seichter via mailop
>  wrote:
> >
> > * Brandon Long:
> >
> > > If we leave googlers.com open, then phishers are going to use it to
> > > send messages looking like [...] "secur...@googlers.com" and do what
> > > they do best.
> >
> > One solution to that is not to use "googlers.com", but to use a domain
> > name with no visible ties to a particular company. That's one reason I
> > use the likes of "monksofcool.net", where the only affiliation is with
> > the late and sorely missed Terry Pratchett.
> >
> > A humorous domain name like that gives phishers little incentive to
> > abuse it, and even if they do, who would believe a spoofed message to be
> > sent by some bank, institution or similar?
>
> This is silly. Stop pushing this.
>
> If every Googler started posting from monksofcool.net then there would
> grow, over time, a population of people who understood that this was a
> Googler domain and those people could potentially be a prime spear
> phishing target.
>

The biggest hole will be for spear phishing, in fact, where another Googler
is the
target.

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

* Al Iverson via mailop:

> This is silly. Stop pushing this.

You may think it "silly", but that won't stop me from using and
promoting this method. It is a cheap and easy way to avoid existing
problems regarding mailing list use.

> If every Googler started posting from monksofcool.net then there would
> grow, over time, a population of people who understood that this was a
> Googler domain and those people could potentially be a prime spear
> phishing target.

Interesting assumption, but I'd like to see you prove that theory.

> The goal is to close the holes, not just shift them 2 feet to the
> left.

Feel free to design a better solutions than DKIM/SPF/DMARC, then. Until
you do, see above.

-Ralph

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

Re: [mailop] [EXTERNAL] Re: Attention Michael Wise - need your assistance

[Michael Wise via mailop]

For OLC, aka "Hotmail" issues...

You know the answer to that, Al: No.

Now if something is broken with the process, like no follow-up with the 
automatic mitigation, or if it's an issue with Office365, I can see what I can 
do, but for, "Why can't my IP be unblocked for sending to Hotmail" ... NO.



I get spanked for it.

So no, for those sorts of issues, no, I am not an escalation point.

There is *NO* escalation point outside of the Support Funnel, which if one has 
an SRX# already, one is already in.

I can't handle escalations for a service that has half a billion customers, 
sorry.



Not happening.

Doesn't scale.

There is no secret back door person who can unblock stuff.

And if one attempts to appeal to Senior Leadership … we may just get a request 
to block the petitioner at the edge.

There is no, “Appealing Unto Caesar”.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?



-Original Message-
From: mailop  On Behalf Of Al Iverson via mailop
Sent: Friday, June 5, 2020 2:20 PM
To: mailop 
Subject: [EXTERNAL] Re: [mailop] Attention Michael Wise - need your assistance



Hey Michael,



Are you an escalation point for Microsoft issues?



Is Mailop?



On Fri, Jun 5, 2020 at 3:58 PM Rauf Guliyev via mailop 
mailto:mailop@mailop.org>> wrote:

>

> Hey Michael,

>

> I haven't gotten any response from you either (did my emails end up in the 
> Spam folder? ;-) and there is nothing with the cases I have submitted either 
> (SR1500907063 and SR1501411372). I'd appreciate a response.

>

> Thanks,

> Rauf

>

> On Fri, Jun 5, 2020 at 1:42 PM Marc Goldman via mailop 
> mailto:mailop@mailop.org>> wrote:

>>

>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchi

>> lli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%

>> 7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b

>> 4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342

>> ;sdata=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3Dreserved=

>> 0

>

> ___

> mailop mailing list

> mailop@mailop.org

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchil

> li.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C

> 01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7

> C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sda

> ta=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3Dreserved=0







--

Al Iverson // Wombatmail // Chicago

Song a day! 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wombatmail.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=2G0X5pEAhqgQwHFRlFIwbK0utpnIE89Lt2AV4I0%2Bdzs%3Dreserved=0

Deliverability! 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspamresource.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=Iu%2Fpy3uZzW%2F2xTBOsvbCjQtM7QI41Hk7cqLXbYJQ%2Bog%3Dreserved=0

And DNS Tools too! 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxnnd.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=QamPS5ZXRqFrfzXbwKdYwEhVNZtZ2Y%2FC%2BjzDxG1PNIc%3Dreserved=0



___

mailop mailing list

mailop@mailop.org

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3Dreserved=0
___
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?)

[Al Iverson via mailop]

On Fri, Jun 5, 2020 at 2:41 PM Ralph Seichter via mailop
 wrote:
>
> * Brandon Long:
>
> > If we leave googlers.com open, then phishers are going to use it to
> > send messages looking like [...] "secur...@googlers.com" and do what
> > they do best.
>
> One solution to that is not to use "googlers.com", but to use a domain
> name with no visible ties to a particular company. That's one reason I
> use the likes of "monksofcool.net", where the only affiliation is with
> the late and sorely missed Terry Pratchett.
>
> A humorous domain name like that gives phishers little incentive to
> abuse it, and even if they do, who would believe a spoofed message to be
> sent by some bank, institution or similar?

This is silly. Stop pushing this.

If every Googler started posting from monksofcool.net then there would
grow, over time, a population of people who understood that this was a
Googler domain and those people could potentially be a prime spear
phishing target.

The goal is to close the holes, not just shift them 2 feet to the left.

Regards,
Al Iverson

-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com

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

Re: [mailop] Attention Michael Wise - need your assistance

[Al Iverson via mailop]

Hey Michael,

Are you an escalation point for Microsoft issues?

Is Mailop?

On Fri, Jun 5, 2020 at 3:58 PM Rauf Guliyev via mailop
 wrote:
>
> Hey Michael,
>
> I haven't gotten any response from you either (did my emails end up in the 
> Spam folder? ;-) and there is nothing with the cases I have submitted either 
> (SR1500907063 and SR1501411372). I'd appreciate a response.
>
> Thanks,
> Rauf
>
> On Fri, Jun 5, 2020 at 1:42 PM Marc Goldman via mailop  
> wrote:
>>
>> 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
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com

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

Re: [mailop] Attention Michael Wise - need your assistance

[Rauf Guliyev via mailop]

Hey Michael,

I haven't gotten any response from you either (did my emails end up in the
Spam folder? ;-) and there is nothing with the cases I have submitted
either (SR1500907063 and SR1501411372). I'd appreciate a response.

Thanks,
Rauf

On Fri, Jun 5, 2020 at 1:42 PM Marc Goldman via mailop 
wrote:

> 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
>
___
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 
,
Tobias Herkula via mailop  wrote:
>It is possible to do depending on the sacrifices you are willing to take:
>
>5321.MailFrom Domain = imp.ch
>5322.From Domain = breitband.ch
>5322.Sender Domain = imp.ch
>
>If you run with that you can set DKIM Domain to imp.ch and still send with 
>breitband.ch in your From. And
>alignment should be fine.

Nope. DMARC looks at the From: header, not the Sender: or anything
else and that's what the SPF or a DKIM identity has to match. Perhaps
you're mis-remembering Sender ID.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

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

[Atro Tossavainen via mailop]

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

Don't get me wrong, Matt.

I do keep reporting the obviously bad stuff such as B2B spammers openly
using purchased lists to many ESPs. The one you mentioned is my personal
favourite too. I'm quite sure if you ask the average ESP abuse desk
person about their opinion on me they are damn sure going to have one.
Not saying what it's going to be like, but indifferent or "who's that?"
it won't be.

I am only saying that if bounce processing worked anywhere near as well
as anybody would have the audience believe, we would not have a business.
Spamtraps would not get any mail, or too little to matter. The business
case would quite simply not exist.

I'm not calling ESPs bad actors. I am thanking them for continuing to
give me something to work with. I believe I did already in my first
message in this thread. I am genuinely thankful for being able to sell
the information that they should not even be generating back to them.

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

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

[Ralph Seichter via mailop]

* Brandon Long:

> If we leave googlers.com open, then phishers are going to use it to
> send messages looking like [...] "secur...@googlers.com" and do what
> they do best.

One solution to that is not to use "googlers.com", but to use a domain
name with no visible ties to a particular company. That's one reason I
use the likes of "monksofcool.net", where the only affiliation is with
the late and sorely missed Terry Pratchett.

A humorous domain name like that gives phishers little incentive to
abuse it, and even if they do, who would believe a spoofed message to be
sent by some bank, institution or similar?

> People spoofing your personal domain aren't likely to be trying to
> reap millions of US dollars from your customers.

Maybe one day... :-) I have more of an SMB perspective on these issues,
rather than global corporation.

> Which maybe means only that we're in violent agreement, different
> domains are going to have different issues and make different
> decisions.

Yes, quite so. Understanding the mechanics, possibilities and risks is
what it is all about. I wanted to clarify what works reliably for my
personal requirements (and for my customers).

-Ralph

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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Brandon Long via mailop]

On Thu, Jun 4, 2020 at 9:30 PM Daniele Nicolodi via mailop <
mailop@mailop.org> wrote:

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

The attack surface is definitely reduced, but maybe you mean it doesn't
reduce the threat,
and that is also true.

Ie, having two ways to do something vs one is definitely reduced, just not
eliminated.

There's also a raft of things which target IMAP right now, and so
eliminating that buys time
before there is enough incentive to move the tools to the new surface.
OTOH, 0365 is definitely
popular enough that the tools will move. OTOOH, re-using the O365 web login
surface means they
were already protecting that and maybe they will have more resources to
work on that.

The longer list of things they included may also indicate their thinking,
that IMAP is just one
of a lot of protocols they aren't upgrading.  Who knows what percentage of
their users use each one
as well, it's possible it really doesn't make sense, that some of those
other ones actually have higher usage
than IMAP.

The weird thing to me is that I thought O365 and outlook.com already
supported OAUTHBEARER (or equivalent).
https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth




Brandon
___
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 4:16 PM Ralph Seichter via mailop 
wrote:

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

The problem isn't internal folks posting to mailing lists, the problem is
that anyone can use the
unprotected domain to spoof messages to anyone else.

If we leave googlers.com open, then phishers are going to use it to send
messages
looking like "accou...@googlers.com" or "secur...@googlers.com" and do what
they
do best.  "secur...@lists.google.com" is the same thing.

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

People spoofing your personal domain aren't likely to be trying to reap
millions of US dollars
from your customers.

Which maybe means only that we're in violent agreement, different domains
are going to
have different issues and make different decisions.

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

[Michael Rathbun via mailop]

On Fri, 5 Jun 2020 11:30:23 -0700, David Carriger via mailop
 wrote:

>I'm not saying this as an attempt to call anyone out, or start a fight, but
>my point is that those of us who are active in these industry mailing lists
>and conferences are the ones who care. We want to do better. We're up
>against forces internal and external.

Some of the most complex, convoluted and difficult-to-maintain code I have
seen in mail systems involves interpreting responses.  One of my favorites,
over time, has been the family of Yahoo "4xx deferred but don't bother trying
again, because you will never succeed" permanent temporary failures.

I have interpreted this as a "let's see if we can run the spammers out of disk
space due to queue bloat from retries that haven't timed out yet" device.  It
has been gratifying to see exactly this effect on some senders.

mdr
-- 
   If Jurassic Park had been about email, Jeff Goldblum would be known 
   for saying "Spammers, uh, find a way".

  -- David Carriger, after noting that some spammers
 they hosed off the deck had found a new home elsewhere.


___
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

[David Carriger via mailop]

Thanks for being a voice of reason, Matt.

ESPs don't always get things right, but the ESPs who are participating in
M3AAWG or joining forums like this one are trying to do the right thing.
Bounce handling is difficult because bounce messages are like an episode of
Whose Line Is It Anyway? -  the status codes are made up and the text
doesn't matter. Sure, there's RFCs, but once you've spent a few days going
through your logs to try to improve your bounce handling and see some mail
operators using 4XX bounces for what should really be a 5.1.1 invalid
recipient, you lose hope in the system.

If I knew what every ISP wanted me to do after a given bounce, I'd do my
best to respect that, within the boundaries of the service that I am also
obligated to provide my clients. This is what we're working with, though:

451 Invalid Recipient - https://community.mimecast.com/docs/DOC-1369#451
[Lzabfop9Nva0NP5E_GxwYg.uk119]
553 sorry, no mailbox here by that name. ulc: 65216002578, rcp: 0001.
(#5.7.1)
554 5.7.1 : Recipient address rejected: user
redac...@lycos.com does not exist
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [
SN1NAM01FT027.eop-nam01.prod.protection.outlook.com]
554 delivery error: dd Not a valid recipient -
atlas215.aol.mail.bf1.yahoo.com

We can all agree that a bad address should be a 550 5.1.1 error, yes?
Surely we can agree on that much, since it's in the RFCs?

https://www.greenend.org.uk/rjk/tech/smtpreplies.html
https://tools.ietf.org/html/rfc3463#section-3.2

Mimecast, Microsoft and Verizon Media Group are not small companies. The
only reason I even know the Microsoft bounce should be codified as a hard
bounce is thanks to the kind folks at SparkPost for posting publicly about
it:

https://www.sparkpost.com/blog/bounce-classification-code-change/

I mean, if I was trying to figure out what to do with that bounce on my
own, what would I do? Well, let's start with the RFC...

  X.4.1   No answer from host

 The outbound connection attempt was not answered, because
 either the remote system was busy, or was unable to take a
 call.  This is useful only as a persistent transient error.


Only useful as a persistent transient error? That's odd, because it was a
5xx error, not a 4xx error. Access denied? Access denied *to whom*? My IP
address? My MAIL FROM domain? The sender in the friendly from? If I can't
definitively tell my customer that the address is undeliverable and will
never receive messages, then I have a duty to attempt subsequent deliveries
until we hit our own internal threshold for converting soft bounces to hard
bounces. The business logic for that determination is going to differ from
ESP to ESP.

I'm not saying this as an attempt to call anyone out, or start a fight, but
my point is that those of us who are active in these industry mailing lists
and conferences are the ones who care. We want to do better. We're up
against forces internal and external. If we got it wrong, help us make it
right. Maybe a C-level told us we had to do something a certain way and
having an email from the ISP themselves saying "That's bad and wrong, don't
do that" would tip the scales. Maybe things have changed since that legacy
code was written 5 years ago and we need a nudge to refactor it. Maybe
someone recently introduced a bug with the last deploy that our testing
didn't catch. We're all up against the same challenges here, these are
things that occur at ISPs as well. How many threads have we seen for "Is
anyone else's GPT data missing/wrong" or "What the heck happened with valid
emails bouncing at Yahoo yesterday"? These things happen, they happen
despite our best intentions, and the sooner we learn to work together to
fix them and move on instead of worrying about where to assign blame, the
better the ecosystem will be for everyone.

Best regards,
David Carriger

On Fri, Jun 5, 2020 at 8:52 AM Matt V via mailop  wrote:

> 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 

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] SPF notification question

[Frank Bulk via mailop]

I have an automated system in place for our customers, partners, and friends 
domains to catch that and then I make them aware.  There’s currently about 108 
on my list that are broken. 

 

I’m not going to put a spotlight on everyone, but here’s a list of .edu domains:

ashland.edu

dmu.edu

sdstate.edu

usd.edu

If anyone has some good connections to those schools, please send a note of 
encouragement. 

 

Success rate is about 5 to 10%.  If I get a response from someone in the first 
few days after my first note then it’s usually 80% chance it will be resolved 
in two weeks. There’s some who think that the problem is our spam filtering 
server and lot of confusion on who/where to send my note – I usually encourage 
their IT consultant/department or their email or DNS resource.

 

Frank 

 

From: mailop  On Behalf Of Liam Fisher via mailop
Sent: Thursday, June 04, 2020 9:05 AM
To: mailop@mailop.org
Subject: [mailop] SPF notification question

 

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

[Matthew Grove via mailop]

Tim, I believe *X-MC-User* and *List-ID* should help you identify those
issues.

Matt, if you think we're not handling a hard bounce properly, I'd like to
get that worked out. Do please reach out off-list so we can troubleshoot
the issue.


Cool,
Matthew
delivery.mailchimp.com


On Fri, Jun 5, 2020 at 10:04 AM Luke via mailop  wrote:

> Atro,
>
> I did not forget that we know each other. I remember meeting you and Pekka
> for the first time in Dublin back in 2015.
>
> I appreciate the added perspective here. It sounded like you were
> suggesting that ESPs do not suppress invalid email addresses. But it sounds
> like you are aware that ESPs do suppress invalid email addresses, but you
> believe they should suppress them across their entire user base. That is a
> different discussion. Unfortunately, this is fraught with all sorts of
> issues. The primary one being the unreliable nature of SMTP responses. Just
> one example that is top of mind is Telstra/Bigpond. They will return "5xx
> No such user" when one of their users has a lapse in payment. The mailbox
> becomes valid again when the user pays their bill. Another example: when I
> was at SendGrid, we did some analysis on bad addresses. We took every
> address that returned some flavor of "no such user" in a 6 month period. We
> then looked at how many of those addresses came back and engaged with mail
> at a later date (the following 6 month period). It turned out that
> something like 1% of invalid addresses would come back to life and become
> engaged with email again. Also, we were careful to not take a single pixel
> load or a single URL firing as "proof" the mailbox was back to life. Now,
> 1% is a small number, but it was 10s of millions of addresses. It would
> simply not be appropriate to permanently suppress these addresses on behalf
> of 80,000-100,000 distinct senders and organizations using SendGrid to send
> their email.
>
> Its hard for me to hear things like "ESPs don't suppress addresses" when I
> worked at an ESP where we had discussions about whether it was ethical to
> charge people for trying to send to addresses that we were suppressing on
> their behalf. ESPs suppress bad addresses, just not the way you would like
> them to. That is a discussion worth having, we just need to be clear on the
> terms of the discussion.
>
> Luke
>
> On Fri, Jun 5, 2020 at 1:21 AM Atro Tossavainen via mailop <
> mailop@mailop.org> wrote:
>
>> On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke 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?
>>
>> Luke, you're sounding like you've forgotten we know each other IRL,
>> and the same goes for you and my biz partners Pekka and Catherine.
>>
>> We timeout new domains for a year or more, in accordance with
>>
>> https://www.m3aawg.org/documents/en/m3aawg-best-current-practices-for-building-and-operating-a-spamtrap-ver-120
>>
>> We started out doing this in such a way that the domains didn't have
>> a way of receiving any email at all (no A and no MX, resulting in the
>> sending mail server having to tell itself NXDOMAIN), but already for
>> a long time this is done so that they do have a mail server that is
>> responding
>>
>> 550 5.1.1 No such user
>>
>> to every attempt to deliver any email.
>>
>> I agree that that should result in very little to no ESP mail when such
>> a domain eventually comes out of timeout, which would result in our not
>> having a business at all. Not the case.
>>
>>
>> >
>> > 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.
>> > 

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

[Frank Bulk via mailop]

Fair question -- none of our infrastructure uses 10.15.194.x. In any offline 
thread someone else believes this is a Dell device (based on the "EMC").

Frank 

-Original Message-
From: mailop  On Behalf Of Brandon Applegate via 
mailop
Sent: Thursday, June 04, 2020 7:50 PM
To: mailop@mailop.org
Subject: Re: [mailop] Strange information upon SMTP connection to icloud email 
server

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


___
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?)

[Tobias Herkula via mailop]

It is possible to do depending on the sacrifices you are willing to take:

5321.MailFrom Domain = imp.ch
5322.From Domain = breitband.ch
5322.Sender Domain = imp.ch

If you run with that you can set DKIM Domain to imp.ch and still send with 
breitband.ch in your From. And alignment should be fine.

But you will get the "via" Tag in compatible MUAs...

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)



From: mailop  on behalf of Benoît Panizzon via 
mailop 
Sent: Thursday, June 4, 2020 12:06
To: mailop@mailop.org
Subject: [mailop] How to allow different domain in envelope and header from? 
(Is Gmails DMARC check broken?)

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

___
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

[Atro Tossavainen via mailop]

Luke, thanks for the reply,

> I appreciate the added perspective here. It sounded like you were
> suggesting that ESPs do not suppress invalid email addresses.

The evidence suggests this is the case.

> But it sounds like you are aware that ESPs do suppress invalid email
> addresses, but you believe they should suppress them across their
> entire user base.

It sounds like I am aware that they claim they are doing so, but that
the evidence in spamtraps contradicts the claim.

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.

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

("Just a few messages ago" being

https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2020-June/016675.html
)

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

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

[Luke via mailop]

Atro,

I did not forget that we know each other. I remember meeting you and Pekka
for the first time in Dublin back in 2015.

I appreciate the added perspective here. It sounded like you were
suggesting that ESPs do not suppress invalid email addresses. But it sounds
like you are aware that ESPs do suppress invalid email addresses, but you
believe they should suppress them across their entire user base. That is a
different discussion. Unfortunately, this is fraught with all sorts of
issues. The primary one being the unreliable nature of SMTP responses. Just
one example that is top of mind is Telstra/Bigpond. They will return "5xx
No such user" when one of their users has a lapse in payment. The mailbox
becomes valid again when the user pays their bill. Another example: when I
was at SendGrid, we did some analysis on bad addresses. We took every
address that returned some flavor of "no such user" in a 6 month period. We
then looked at how many of those addresses came back and engaged with mail
at a later date (the following 6 month period). It turned out that
something like 1% of invalid addresses would come back to life and become
engaged with email again. Also, we were careful to not take a single pixel
load or a single URL firing as "proof" the mailbox was back to life. Now,
1% is a small number, but it was 10s of millions of addresses. It would
simply not be appropriate to permanently suppress these addresses on behalf
of 80,000-100,000 distinct senders and organizations using SendGrid to send
their email.

Its hard for me to hear things like "ESPs don't suppress addresses" when I
worked at an ESP where we had discussions about whether it was ethical to
charge people for trying to send to addresses that we were suppressing on
their behalf. ESPs suppress bad addresses, just not the way you would like
them to. That is a discussion worth having, we just need to be clear on the
terms of the discussion.

Luke

On Fri, Jun 5, 2020 at 1:21 AM Atro Tossavainen via mailop <
mailop@mailop.org> wrote:

> On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke 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?
>
> Luke, you're sounding like you've forgotten we know each other IRL,
> and the same goes for you and my biz partners Pekka and Catherine.
>
> We timeout new domains for a year or more, in accordance with
>
> https://www.m3aawg.org/documents/en/m3aawg-best-current-practices-for-building-and-operating-a-spamtrap-ver-120
>
> We started out doing this in such a way that the domains didn't have
> a way of receiving any email at all (no A and no MX, resulting in the
> sending mail server having to tell itself NXDOMAIN), but already for
> a long time this is done so that they do have a mail server that is
> responding
>
> 550 5.1.1 No such user
>
> to every attempt to deliver any email.
>
> I agree that that should result in very little to no ESP mail when such
> a domain eventually comes out of timeout, which would result in our not
> having a business at all. Not the case.
>
>
> >
> > 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. 

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

[Tim Bray via mailop]

On 04/06/2020 20:08, Matthew Grove via mailop wrote:


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.



Can I compare /X-MC-User /to work out if one mailchimp customer (member 
?) has me on loads of lists?  Or if I subscribe from one, whether they 
put me back on another?


Tim
//


--
Tim Bray
Huddersfield, GB
t...@kooky.org

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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Graeme Fowler via mailop]

On 5 Jun 2020, at 05:26, Daniele Nicolodi via mailop  wrote:
> 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?

Very much so.

For malware families like Emotet and friends, one of the attack vectors is to 
hoover up emails from mailboxes then use those as implant methods by 'replying' 
to them with malware droppers attached. In UK HE we've also seen some similar 
methods utilised in attacks designed to con browsers into giving up the access 
token they're currently using, so actually making use of moden auth techniques!

Modern auth on IMAP and SMTP stops that pretty well dead, as does turning off 
authenticated SMTP (stopping the injection of content for outbound submission) 
and/or IMAP (for hoovering up the content in the first place).

It's a very long game though, this one.

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

[Atro Tossavainen via mailop]

On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke 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?

Luke, you're sounding like you've forgotten we know each other IRL,
and the same goes for you and my biz partners Pekka and Catherine.

We timeout new domains for a year or more, in accordance with
https://www.m3aawg.org/documents/en/m3aawg-best-current-practices-for-building-and-operating-a-spamtrap-ver-120

We started out doing this in such a way that the domains didn't have
a way of receiving any email at all (no A and no MX, resulting in the
sending mail server having to tell itself NXDOMAIN), but already for
a long time this is done so that they do have a mail server that is
responding

550 5.1.1 No such user

to every attempt to deliver any email.

I agree that that should result in very little to no ESP mail when such
a domain eventually comes out of timeout, which would result in our not
having a business at all. Not the case.


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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Andrew C Aitchison via mailop]

On Thu, 4 Jun 2020, Daniele Nicolodi via mailop wrote:


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?


Depends whether it is a dictionary attack or a zero-day exploit.

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

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