Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Brielle Bruns]

On 4/27/2019 11:19 PM, Bill Cole wrote:
Basically DKIM on my EXIM server is configured in the default way 
which Debian’s config file sets it up once you provide it with the 
necessary keys for signing.  If it’s got something that they need to 
fix to make it behave better, I’m all for getting that together.


I guess that means that Exim on Debian has matched one of the most 
famous "features" long touted for Exchange...


You should be able to modify the header selection for signing in the 
Exim config and you should do so with thoughtfulness, rather than simply 
accepting a packager's defaults.






I just went through the config, now that I'm back in front of a laptop. 
Debian's setup is very basic, no fluff, and relies on the defaults that 
are set by the developers.


EXIM is generating that list based on RFC 4871 (Section 5.5 lists 
recommended).


EXIM Doc - see dkim_sign_headers
https://www.exim.or 
tg/exim-html-current/doc/html/spec_html/ch-dkim_and_spf.html


Its a default config that is in all EXIM setups unless explicitly 
overriden otherwise.


Sure, it looks like it may be overzealous in its inclusion, but that's a 
change in behavior that could be suggested to the EXIM developers to 
make it a bit more tolerant of what you are suggesting.


For a long time, I refused to insert DKIM headers on the grounds it 
created situations like this.  But, you can thank certain large 
providers who make some hurdles if you don't have DKIM signed messages.


DMARC elicits the same 'Fuck that' response from me.  I implement 
something with regards to it only because I need mail to go through.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Bill Cole]

On 27 Apr 2019, at 19:49, Grant Taylor via mailop wrote:


On 4/27/19 1:09 PM, Bill Cole wrote:
Yes, because the signature included the Sender and List-* headers, 
probably non-existent originally, which mailing lists typically 
(including this one) add to messages they relay.


Thus the Sender and List-* headers were oversigned.


Yes.

Signing the non-existence of the Sender and List-* headers on 
messages sent to mailing lists is a perfect recipe for broken 
signatures.


Are you saying that a sending server should have different behaviors 
based on the destination of an email?  Particularly if it's going to a 
mailing list or not?


I can't say "should" because that's a site-specific/sender-specific 
choice.


It's a thing that could be done with some effort, the right tools, and 
properly trained users.


It is also entirely feasible without substantially weakening DKIM  to 
just universally not oversign headers that mailing list managers 
typically and properly.


Whoever made the signing choices for Brielle's mail made wrong 
choices.


I question that.

Are you implying that mailing list managers (software and / or 
administrators) have no culpability in the fact that downstream 
recipients detected that the original sender's message has been 
modified (by the mailing list manager)?


It is not "culpable" for a mailing list manager to add List-* and Sender 
headers OR to be blind to DKIM signatures.  On the other hand, a signer 
that is not part of a mailing lists manager signing non-existent 
standard headers used by mailing list managers is actively hostile to 
mailing list managers.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Bill Cole]

On 27 Apr 2019, at 19:00, Brielle wrote:


I guess I’m a bit confused at what you mean.


Your signature:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; 
d=2mbit.com;

 s=default;
 h=To:In-Reply-To:References:Message-Id:Subject:Date:Mime-Version:
 Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=wP2Xtnc8LbQkAHu0TnXjzgMuqlCHpbu9L1jSnlo7wEw=; 
b=BHo0F/RAYzlGzCWeaiivU50uW0

 AfOyoF64/eS5Cs11NCbHVAIDpCg5eIj9if07Et+2o0UKV9rano9xRIWw4vyd2ZvVz1YVIXB10rwiX
 DQkQOahzEzirzKrmArSwdVmAL9MF9kzjdBaEd+eCegJVQfMDbdkg0wZ1YClopKymWhhg=;

See the list of headers after the 'h='? Those are the headers that are 
included (along with the body hash in the 'bh=' section) in the data 
which your DKIM signer has signed. DKIM supports the inclusion of 
headers which do not exist in the original message as a mechanism to 
make the addition of those headers invalidate the signature.


So your signature signs many null-value headers, some of which (Sender 
and the List-* collection) mailing lists typically add *because they are 
supposed to add them*.



 I’ll note I run my own mail server, DNS, etc.


Then you can fix this if you stop signing headers on messages that you 
send to mailing lists which mailing lists typically (and properly) add 
to messages. It seems pointless to sign many of the headers that you are 
signing, unless you want to cause signatures to break if anyone forwards 
your mail.


Basically DKIM on my EXIM server is configured in the default way 
which Debian’s config file sets it up once you provide it with the 
necessary keys for signing.  If it’s got something that they need to 
fix to make it behave better, I’m all for getting that together.


I guess that means that Exim on Debian has matched one of the most 
famous "features" long touted for Exchange...


You should be able to modify the header selection for signing in the 
Exim config and you should do so with thoughtfulness, rather than simply 
accepting a packager's defaults.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Grant Taylor via mailop]

On 4/27/19 1:09 PM, Bill Cole wrote:
Yes, because the signature included the Sender and List-* headers, 
probably non-existent originally, which mailing lists typically 
(including this one) add to messages they relay.


Thus the Sender and List-* headers were oversigned.

Signing the non-existence of the Sender and List-* headers on messages 
sent to mailing lists is a perfect recipe for broken signatures.


Are you saying that a sending server should have different behaviors 
based on the destination of an email?  Particularly if it's going to a 
mailing list or not?



Whoever made the signing choices for Brielle's mail made wrong choices.


I question that.

Are you implying that mailing list managers (software and / or 
administrators) have no culpability in the fact that downstream 
recipients detected that the original sender's message has been modified 
(by the mailing list manager)?


Rejecting mail simply for a broken DKIM signature when the relevant 
DMARC record includes p=none is bad practice. It particularly unwise 
when, as in this case, the signer has oversigned headers that do not 
exist in the message at all. It is certainly within anyone's rights to 
reject mail for any whimsical reason they like, but a mail system that 
rejects messages for this reason is unfit for general use. It's being 
used as a toy.


~chuckle~

That's not the first time I've heard Gmail referred to as a toy (or an 
experiment).


I look forward to the resulting world where people have direct 
experience with the ways mail provider quality varies and create actual 
competition on more than name recognition and webmail UI cuteness.


Agreed.

I'm not holding my breath.

Beyond that, any system that understands DMARC should never use DKIM 
failure as an absolute rejection criteria if p=none. That's an explicit 
statement by the domain owner that it is WRONG to treat a bad DKIM 
signatures in their name as basis for rejecting mail. Google is being 
intentionally user-hostile here, intentionally and knowingly degrading 
their service for their users.


I'm choosing to maintain hope that there is something else in addition 
to the DKIM failure that triggered Gmail to reject messages.  But I have 
no inside information to that.



I'd call it "stupid" except that I know they are not this stupid.


I do have some inside information to know that Google employees are 
human and do make mistakes.  Some of them bone headed that should never 
happen.


There are really 3 actions that mailing lists need to take if there is 
any possibility of them breaking a signature:


1. From headers with domains with p=reject or p=quarantine DMARC records 
must be munged by the mailing list, because any signature failure OR 
ABSENCE will cause rejection of mail.


2. Existing signatures should be removed or relabeled.

3. If the From is munged, the message should be re-signed by the mailing 
list system with whatever domain is used in the munged header.


I completely agree.

I do question why #3 shouldn't be done cart blanch.

Note that there are a lot of non-obvious ways a mailing list can break 
signatures by doing things that have long been considered acceptable or 
even best practices for mailing lists. Even actions which are 
theoretically allowable for mail in general such as header refolding or 
address format normalization can break signatures.


Agreed.

Which is why I think that the DKIM header's usefulness ends when it gets 
to the mailing list manager.  As such, I think that #2 and #3 above are 
critical.


It is not accidental that some of the drivers of the development of DKIM 
and DMARC and "leaders" in aggressive enforcement have been entities 
which run their own captive discussion list systems which work best for 
users who also have mailboxes under the same provider's umbrella. A 
conspiracy theorist might think that Google, Yahoo, and AOL (now one 
with Yahoo) wanted to kill off traditional provider-independent 
discussion mailing lists.


I feel like it's quite possible to configure mailing list managers to 
behave in such a way that is compatible with the aforementioned 
providers and many others.  Particularly if steps #1, #2, and #3 are done.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Brielle]

I guess I’m a bit confused at what you mean. 

 I’ll note I run my own mail server, DNS, etc.

Basically DKIM on my EXIM server is configured in the default way which 
Debian’s config file sets it up once you provide it with the necessary keys for 
signing.  If it’s got something that they need to fix to make it behave better, 
I’m all for getting that together.  

On the flip side, it’s amusing to know that I can still cause havoc even after 
all these years just by sending an email. :)

Sent from my iPhone

> On Apr 27, 2019, at 1:09 PM, Bill Cole 
>  wrote:
> 
> Yes, because the signature included the Sender and List-* headers, probably 
> non-existent originally, which mailing lists typically (including this one) 
> add to messages they relay.
> 
> Signing the non-existence of the Sender and List-* headers on messages sent 
> to mailing lists is a perfect recipe for broken signatures. Whoever made the 
> signing choices for Brielle's mail made wrong choices.


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

Re: [mailop] The utility of spam folders

[Steve Atkins]

> On Apr 27, 2019, at 8:41 PM, Michael Wise via mailop  
> wrote:
> 
>  
> A very wise individual (not me) once pointed out something non-obvious... it 
> takes longer to clear a good message than it typically does to find something 
> evil with a bad message. Good messages are much more expensive to process.

Messages that are neither particularly good, nor particularly bad, rather just 
mediocre greymail can be more expensive still to deliver accurately.

Even though those are the ones the recipient cares least about - including 
about whether they were delivered, or not, appropriately.

(And the ability to deliver, or not, that particular message correctly may rely 
critically on details about other messages from the same mail stream and 
recipients response to them in the previous month. Or in the next several 
hours.)

Cheers,
  Steve

> Non-obvious, but true.
>  
> Aloha,
> Michael.
> --
> Michael J Wise
> Microsoft Corporation| Spam Analysis
> "Your Spam Specimen Has Been Processed."
> Got the Junk Mail Reporting Tool ?
>  
> -Original Message-
> From: mailop  On Behalf Of Bill Cole
> Sent: Friday, April 26, 2019 11:17 PM
> To: Brandon Long via mailop 
> Subject: Re: [mailop] The utility of spam folders
>  
> On 23 Apr 2019, at 1:17, Brandon Long via mailop wrote:
>  
> > On Sat, Apr 20, 2019 at 12:47 PM Bill Cole < 
> > mailop-20160...@billmail.scconsult.com> wrote:
>  
> [...]
> >> 
> >> One fact that is very helpful to understand and yet broadly ignored
> >> when people look at the feasibility of processing-intensive filtering
> >> is the mandate of 
> >> https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6.
> >> 
> > 
> > Holding a connection open for a long time before admitting you
> > received the
> > message
> > has its own issues, of course.  We've also found that we often have
> > way
> > more resources
> > to receive messages than the senders do to send them, I doubt very
> > many
> > mail senders would
> > react well if we started taking minutes to receive every message.
>  
> Sure, but there's a lot of room below "minutes to receive every message"
> to interrogate complex and suspect messages carefully without troubling
> most senders.  The overwhelming majority of non-bulk legitimate email
> can be cleared very fast, no matter how intensively you examine it,
> because it simply isn't that complex.
>  
> If you are not taking minutes to filter every message asynchronously
> (after which you can only reasonably deliver what you think is spam into
> a spam folder) then doing as good a job synchronously and rejecting mail
> deemed to be spam wouldn't mean taking minutes for every message.
> However, if you have useful filtering tactics that literally take a
> minute for some messages, that shouldn't be considered lethal no matter
> how much it makes a few senders whine.
>  
> And I should note that I'm not trying to be prescriptive for behemoth
> freemail/freemail+ providers. I have a hard time avoiding the use of the
> generic 2nd person so this is not about YOU, Brandon Long, Google
> Incarnate... Spam foldering and other flavors of mail limbo may well be
> the only feasible choice at Google/MS scale but most mail operators are
> nowhere near that scale and should not fall into the trap of mimicking
> service patterns that are ultimately rooted in scaling problems.
>  
> [...]
> > And unfortunately, enterprises often rely on some of these self same
> > tools.  Telling them
> > they can't do something like send/receive attachments is a very quick
> > way
> > for them
> > to choose another provider.  And these are the paying users.
>  
> You might be surprised...
>  
> But that's a digression. I did not say attachments should be absolutely
> prohibited on any mail system, and I don't believe they can or should
> be. I said that most mail providers can and should avoid some of the
> most demanding filtering tasks by being willing to break some edge
> cases, offer workarounds, and use the teachable moments that breakage
> offers.
>  
> Note that Google & MS already have such workarounds in operation. Your
> smartest paying customers who care about governance are already using
> them in preference to tossing around files in email. I am just glad
> (because I still need to earn a living...) that Google & MS have not
> recognized that services which people eagerly pay for that have great
> economies of scale can be used as leverage to raise the quality of a
> service that everyone has mostly conceded to always kinda suck (but at
> least it's cheap...)
>  
> [...]
> >> The problem is the business model to which a freemail operation must
> >> conform. The freemail adaptations to cost constraints and scale have
> >> metastasized via user expectations and cargo-cult system design, but
> >> they aren't necessarily the best choices elsewhere.
> >> 
> > 
> > You speak of freemail as if GSuite and O365 aren't also the largest
> > paid
> > mail services in the world, with products that are ex

Re: [mailop] The utility of spam folders

[Jay Hennigan]

On 4/27/19 12:41 PM, Michael Wise via mailop wrote:
A very wise individual (not me) once pointed out something 
non-obvious... it takes longer to clear a good message than it typically 
does to find something evil with a bad message. Good messages are much 
more expensive to process. Non-obvious, but true.


Makes sense. Once you find something bad, you stop processing.
--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

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

Re: [mailop] The utility of spam folders

[Michael Wise via mailop]

A very wise individual (not me) once pointed out something non-obvious... it 
takes longer to clear a good message than it typically does to find something 
evil with a bad message. Good messages are much more expensive to process. 
Non-obvious, but true.

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



-Original Message-
From: mailop  On Behalf Of Bill Cole
Sent: Friday, April 26, 2019 11:17 PM
To: Brandon Long via mailop 
Subject: Re: [mailop] The utility of spam folders



On 23 Apr 2019, at 1:17, Brandon Long via mailop wrote:



> On Sat, Apr 20, 2019 at 12:47 PM Bill Cole <

> mailop-20160...@billmail.scconsult.com>
>  wrote:



[...]

>>

>> One fact that is very helpful to understand and yet broadly ignored

>> when people look at the feasibility of processing-intensive filtering

>> is the mandate of

>> https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6.

>>

>

> Holding a connection open for a long time before admitting you

> received the

> message

> has its own issues, of course.  We've also found that we often have

> way

> more resources

> to receive messages than the senders do to send them, I doubt very

> many

> mail senders would

> react well if we started taking minutes to receive every message.



Sure, but there's a lot of room below "minutes to receive every message"

to interrogate complex and suspect messages carefully without troubling

most senders.  The overwhelming majority of non-bulk legitimate email

can be cleared very fast, no matter how intensively you examine it,

because it simply isn't that complex.



If you are not taking minutes to filter every message asynchronously

(after which you can only reasonably deliver what you think is spam into

a spam folder) then doing as good a job synchronously and rejecting mail

deemed to be spam wouldn't mean taking minutes for every message.

However, if you have useful filtering tactics that literally take a

minute for some messages, that shouldn't be considered lethal no matter

how much it makes a few senders whine.



And I should note that I'm not trying to be prescriptive for behemoth

freemail/freemail+ providers. I have a hard time avoiding the use of the

generic 2nd person so this is not about YOU, Brandon Long, Google

Incarnate... Spam foldering and other flavors of mail limbo may well be

the only feasible choice at Google/MS scale but most mail operators are

nowhere near that scale and should not fall into the trap of mimicking

service patterns that are ultimately rooted in scaling problems.



[...]

> And unfortunately, enterprises often rely on some of these self same

> tools.  Telling them

> they can't do something like send/receive attachments is a very quick

> way

> for them

> to choose another provider.  And these are the paying users.



You might be surprised...



But that's a digression. I did not say attachments should be absolutely

prohibited on any mail system, and I don't believe they can or should

be. I said that most mail providers can and should avoid some of the

most demanding filtering tasks by being willing to break some edge

cases, offer workarounds, and use the teachable moments that breakage

offers.



Note that Google & MS already have such workarounds in operation. Your

smartest paying customers who care about governance are already using

them in preference to tossing around files in email. I am just glad

(because I still need to earn a living...) that Google & MS have not

recognized that services which people eagerly pay for that have great

economies of scale can be used as leverage to raise the quality of a

service that everyone has mostly conceded to always kinda suck (but at

least it's cheap...)



[...]

>> The problem is the business model to which a freemail operation must

>> conform. The freemail adaptations to cost constraints and scale have

>> metastasized via user expectations and cargo-cult system design, but

>> they aren't necessarily the best choices elsewhere.

>>

>

> You speak of freemail as if GSuite and O365 aren't also the largest

> paid

> mail services in the world, with products that are extremely similar

> to

> their consumer free services.



I am acutely aware of that, it is central to my argument. For many years

I have worked for businesses that could loosely be called competitors to

GSuite and O365. I know from doing it that limbo-free email can be done

well enough (minimal bad mail being delivered or good mail being

rejected) that paying users will come to prefer it over freemail-like

service. That service model lacks significant economies of scale (and

arguably has net diseconomies of scale,) but by the most objective

metrics of value it is a better service model than that of the

behemoths.





--

Re: [mailop] The utility of spam folders

[Luis E. Muñoz via mailop]

On 26 Apr 2019, at 23:16, Bill Cole wrote:

Spam foldering and other flavors of mail limbo may well be the only 
feasible choice at Google/MS scale but most mail operators are nowhere 
near that scale and should not fall into the trap of mimicking service 
patterns that are ultimately rooted in scaling problems.


This. Just this year I've participated in a few architecture meetings 
with prospective mail architects that were blindly trying to mimic what 
the big ones were doing, quite blindly. In addition to what's being 
discussed here, the MS model of tempfailing a second receiver when 
mailboxes are at different POPs was being touted as a best practice.


Best regards

-lem

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Bill Cole]

On 27 Apr 2019, at 13:02, Grant Taylor via mailop wrote:


On 4/27/19 3:54 AM, Simon Lyall wrote:
The below message was bounced by everyone (I assume) in the list 
whose address is hosted by gmail.


I would be surprised if it was just Gmail.


Date: Wed, 24 Apr 2019 08:44:58 -0600
From: Brielle Bruns 
Subject: Re: [mailop] The utility of spam folders


It looks like Brielle's message was DKIM signed, modified in transit 
(likely by the mailop mailing list),


Yes, because the signature included the Sender and List-* headers, 
probably non-existent originally, which mailing lists typically 
(including this one) add to messages they relay.


Signing the non-existence of the Sender and List-* headers on messages 
sent to mailing lists is a perfect recipe for broken signatures. Whoever 
made the signing choices for Brielle's mail made wrong choices.


and subsequently rejected (or otherwise penalized) by DKIM enabled 
recipients.


Rejecting mail simply for a broken DKIM signature when the relevant 
DMARC record includes p=none is bad practice. It particularly unwise 
when, as in this case, the signer has oversigned headers that do not 
exist in the message at all. It is certainly within anyone's rights to 
reject mail for any whimsical reason they like, but a mail system that 
rejects messages for this reason is unfit for general use. It's being 
used as a toy.



I expect that such penalizations are going to become more prevalent.


I look forward to the resulting world where people have direct 
experience with the ways mail provider quality varies and create actual 
competition on more than name recognition and webmail UI cuteness.



Error message similar to this:

     SMTP error from remote mail server after end of data:
     host aspmx.l.google.com [2a00:1450:400c:c00::1b]:
     550-5.7.1 This message does not have authentication 
information or fails to pass
     550-5.7.1 authentication checks. To best protect our users 
from spam, the

     550-5.7.1 message has been blocked. Please visit
     550-5.7.1  
https://support.google.com/mail/answer/81126#authentication for more

     550 5.7.1 information. i5si14352580wrp.442 - gsmtp


I'm used to such for SPF / DKIM / DMARC failure.

I'm guessing that it was DKIM signature failure because 2mbit's DMARC 
record has a policy of none, thus shouldn't have applied.


Beyond that, any system that understands DMARC should never use DKIM 
failure as an absolute rejection criteria if p=none. That's an explicit 
statement by the domain owner that it is WRONG to treat a bad DKIM 
signatures in their name as basis for rejecting mail. Google is being 
intentionally user-hostile here, intentionally and knowingly degrading 
their service for their users. I'd call it "stupid" except that I know 
they are not this stupid.


The subscriptions of around 160 list-members were suspended. I'll 
look at unsuspending them.


I'm sort of surprised that it was only Gmail.  Maybe others aren't 
being as restrictive and rejecting messages based on DKIM.


Of course not. DKIM is inherently fragile and is easily misused in ways 
that make it more fragile. In conjunction with traditional mailing 
lists, it is positively dysfunctional.


Or perhaps there's more to Gmail's secret sauce that combined a DKIM 
validation failure with other aspects and decided to reject based on 
the combined result.


IMHO this does bring up a conversation of if mailing lists that do 
modify the message should pass pre-existing DKIM signatures through.  
I personally believe that such previous DKIM-Signatures (et al.) 
SHOULD be removed OR renamed (prepend something like "X-Old-") to 
them.


I agree. That's not sufficient but it is often necessary.

There are really 3 actions that mailing lists need to take if there is 
any possibility of them breaking a signature:


1. From headers with domains with p=reject or p=quarantine DMARC records 
must be munged by the mailing list, because any signature failure OR 
ABSENCE will cause rejection of mail.


2. Existing signatures should be removed or relabeled.

3. If the From is munged, the message should be re-signed by the mailing 
list system with whatever domain is used in the munged header.


Note that there are a lot of non-obvious ways a mailing list can break 
signatures by doing things that have long been considered acceptable or 
even best practices for mailing lists. Even actions which are 
theoretically allowable for mail in general such as header refolding or 
address format normalization can break signatures.


I know that different mailing lists have taken different stances on 
DKIM & DMARC signed posts.  Some push back and may unsubscribe the 
secured sender.  The other end is to be extremely proactive and remove 
/ rename problematic headers and generate new counterparts as messages 
leave the mailing list.  (I fall into the latter camp.)


But, with DMARC having governmental mandates in multiple countries, I 
suspect that this is going to becom

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Grant Taylor via mailop]

On 4/27/19 11:16 AM, John Levine wrote:
I wouldn't.  Gmail has made it quite clear that on their v6 mail 
servers they will only accept mail that is SPF or DKIM authenticated. 
If you don't authenticate, send to their v4 mail servers.  I don't 
know anyone else who does that.


Hum.

I suspect that if mailop.org had an SPF record to match the list's 
envelope bounce address, this particular problem would go away.


I'm surprised that mailop doesn't have an SPF record at all.  I would 
have expected a fairly restrictive SPF record.


That would be a pretty broken implementation of DKIM.  The spec makes 
it absolutely clear that an invalid DKIM signature is the same as no 
signature at all.


Specs make a lot of things clear, including the intent of the spec. 
That doesn't stop people from consciously doing things contrary to the 
spec.  After all, each email server operator is free to implement their 
server as they see fit.


Be it SPF or DKIM, I think that mailop should contemplate doing 
something.  I'd personally like to see both.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 4/27/19 3:54 AM, Simon Lyall wrote:
>> The below message was bounced by everyone (I assume) in the list whose 
>> address is hosted by gmail.
>
>I would be surprised if it was just Gmail.

I wouldn't.  Gmail has made it quite clear that on their v6 mail
servers they will only accept mail that is SPF or DKIM authenticated.
If you don't authenticate, send to their v4 mail servers.  I don't
know anyone else who does that.

I suspect that if mailop.org had an SPF record to match the list's
envelope bounce address, this particular problem would go away.

>It looks like Brielle's message was DKIM signed, modified in transit 
>(likely by the mailop mailing list), and subsequently rejected (or 
>otherwise penalized) by DKIM enabled recipients.

That would be a pretty broken implementation of DKIM.  The spec makes
it absolutely clear that an invalid DKIM signature is the same as no
signature at all.

R's,
John

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Grant Taylor via mailop]

On 4/27/19 3:54 AM, Simon Lyall wrote:
The below message was bounced by everyone (I assume) in the list whose 
address is hosted by gmail.


I would be surprised if it was just Gmail.


Date: Wed, 24 Apr 2019 08:44:58 -0600
From: Brielle Bruns 
Subject: Re: [mailop] The utility of spam folders


It looks like Brielle's message was DKIM signed, modified in transit 
(likely by the mailop mailing list), and subsequently rejected (or 
otherwise penalized) by DKIM enabled recipients.


I expect that such penalizations are going to become more prevalent.


Error message similar to this:

     SMTP error from remote mail server after end of data:
     host aspmx.l.google.com [2a00:1450:400c:c00::1b]:
     550-5.7.1 This message does not have authentication information or 
fails to pass
     550-5.7.1 authentication checks. To best protect our users from 
spam, the

     550-5.7.1 message has been blocked. Please visit
     550-5.7.1  
https://support.google.com/mail/answer/81126#authentication for more

     550 5.7.1 information. i5si14352580wrp.442 - gsmtp


I'm used to such for SPF / DKIM / DMARC failure.

I'm guessing that it was DKIM signature failure because 2mbit's DMARC 
record has a policy of none, thus shouldn't have applied.


The subscriptions of around 160 list-members were suspended. I'll look 
at unsuspending them.


I'm sort of surprised that it was only Gmail.  Maybe others aren't being 
as restrictive and rejecting messages based on DKIM.  Or perhaps there's 
more to Gmail's secret sauce that combined a DKIM validation failure 
with other aspects and decided to reject based on the combined result.


IMHO this does bring up a conversation of if mailing lists that do 
modify the message should pass pre-existing DKIM signatures through.  I 
personally believe that such previous DKIM-Signatures (et al.) SHOULD be 
removed OR renamed (prepend something like "X-Old-") to them.


I know that different mailing lists have taken different stances on DKIM 
& DMARC signed posts.  Some push back and may unsubscribe the secured 
sender.  The other end is to be extremely proactive and remove / rename 
problematic headers and generate new counterparts as messages leave the 
mailing list.  (I fall into the latter camp.)


But, with DMARC having governmental mandates in multiple countries, I 
suspect that this is going to become more of a problem.  As such, I 
think it deserves being discussed.  Particularly where along the 
aforementioned line the mailop mailing list wants to be.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Error message from Hotmail

[Udeme Ukutt]

It's tapered off a bit since 4/24 but I still see it in my logs.

@ Michael: pls any feedback from your inquiries? Felt I'd reply here since
there's a couple of us that saw this :)

Thanks, Udeme

On Thu, Apr 25, 2019 at 2:12 PM Al Iverson  wrote:

> Seeing some funky stuff here, as well. Multiple reports of excessive (and
> new) 4xx deferrals over the past days.
>
> Cheers,
> Al Iverson
>
> On Thu, Apr 25, 2019 at 3:07 AM Jan Schapmans 
> wrote:
>
>> Hi,
>>
>>
>>
>> not seeing any progress (no blame :-)). Numbers are still high.
>>
>> Is it ok to retry the message immediately? now our default retry is taken
>> so we wait 30mins.
>>
>>
>>
>>
>>
>>
>>
>> Kind regards,
>>
>>
>>
>>
>>
>> *JAN SCHAPMANS*
>>
>> DIRECTOR DELIVERABILITY SERVICES
>>
>>
>>
>> *mobile* +32 498 932 965
>>
>> *email* jan.schapm...@selligent.com
>>
>>
>>
>> *SELLIGENT MARKETING CLOUD*
>>
>> *MAXIMIZE EVERY MOMENT*
>>
>> *https://www.selligent.com *
>>
>>
>>
>> The information contained in this communication is confidential and is
>> only for the use of the intended addressee. If you have received this
>> communication in error, please destroy it immediately, including all
>> attachments.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* mailop  *On Behalf Of *Michael Wise
>> via mailop
>> *Sent:* 23 April 2019 22:08
>> *To:* Christopher Vitulski 
>> *Cc:* Michael Wise via mailop 
>> *Subject:* Re: [mailop] Error message from Hotmail
>>
>>
>>
>>
>>
>> Making inquiries.
>>
>>
>>
>> Aloha,
>>
>> Michael.
>>
>> --
>>
>> *Michael J Wise*
>> Microsoft Corporation| Spam Analysis
>>
>> "Your Spam Specimen Has Been Processed."
>>
>> Got the Junk Mail Reporting Tool
>>  ?
>>
>>
>>
>> *From:* mailop  *On Behalf Of *Christopher
>> Vitulski via mailop
>> *Sent:* Tuesday, April 23, 2019 11:48 AM
>> *Cc:* mailop 
>> *Subject:* Re: [mailop] Error message from Hotmail
>>
>>
>>
>> Hello Mail op community,
>>
>>
>>
>> We are still seeing similar issues as mentioned above.  It has started to
>> go away, and then has picked back up again, most recently it started to
>> accumulate more bounces starting Monday April 22 and continues to grow
>> today.  It seems we see the bulk of these bounces from 3 am to 3 pm PST.
>>
>>
>>
>> I opened a ticket with MSFT that quickly turned into them telling me they
>> see no issue and they cannot help with the specific bounce I am seeing:
>>
>>
>>
>> "451 4.4.0 Message failed to be replicated: Insufficient system resource [
>> VI1EUR04HT159.eop-eur04.prod.protection.outlook.com
>> ]
>> [VI1EUR04FT063.eop-eur04.prod.protection.outlook.com
>> 
>> ]"
>>
>>
>>
>> MSFT reply:
>>
>>
>>
>> Unfortunately, we are not the right place for you to direct your Support
>> questions.
>>
>> Our goal in Outlook.com Deliverability Support is to make sure that every
>> wanted message sent to our customers arrive in their inbox. We work
>> directly with senders to resolve email delivery failures to Microsoft
>> owned domains. After reviewing the information you provided, I have
>> determined that your issue is related 

[mailop] [FEEDBACK REQUEST] Login-Referrals capability and abuse potential

[Michael Peddemors]

Came into the office on a Saturday to catch up on dull CEO 
responsibilities like licensing agreements etc..


And got totally distracted helping one of our Spam Auditors working on a 
different smaller bot net.. And trying to decide if one operation or two 
separate ones.


This one has a small static footprint.. (list below) But investigation 
revealed something interesting when looking at the Aruba ones


nmap reveals..

ssl-cert: Subject: 
commonName=mailserver.cloud.it/organizationName=mailserver.cloud.it/stateOrProvinceName=GuangDong/countryName=CN


(Always strange to see a Chinese address, for an italian cloud service)

imap-capabilities: STARTTLS OK LOGINDISABLEDA0001 more LOGIN-REFERRALS

Shamed to admit it, wasn't up on that capability until now, but this may 
explain the Brute Force attacks coming from those servers..


Seems these servers do a static login referral.. to other servers.. 
almost a proxy type IMAP (Uhoh! IMAP Phishing?)


What I could use some one else shedding light on, as I can't see how it 
could happen from a legitimate email service, is isn't this something 
that only the server can configure?  How could it be abused to be 
redirected to legitimate servers?  Is there an end user capability that 
say a legitimate provider could expose that allows a user to specify 
which server to connect to?


Or is this just a bad actor taking advantage of Aruba, and forging their 
cloud infrastructure, and doing this at the back end, for proxy based 
auth attacks?


(Oh, if these were legit IP(s) then cloud.it should be putting a PTR 
record on those outgoing requests.. and a couple of other things they 
should od)






Google:
104.199.47.22   x1  22.47.199.104.bc.googleusercontent.com
35.187.17.160   x1  160.17.187.35.bc.googleusercontent.com
35.203.122.249  x1  249.122.203.35.bc.googleusercontent.com


Amazon:
15.164.93.247   x1 ec2-15-164-93-247.ap-northeast-2.compute.amazonaws.com
3.122.244.152   x3 ec2-3-122-244-152.eu-central-1.compute.amazonaws.com


Digital Ocean:
134.209.231.28  x11 NXDOMAIN
134.209.240.245 x8  NXDOMAIN
134.209.248.73  x11 NXDOMAIN
134.209.255.170 x11 NXDOMAIN
157.230.126.140 x3  NXDOMAIN
159.65.10.120   x191NXDOMAIN
159.65.175.92   x27 NXDOMAIN
165.227.218.191 x76 NXDOMAIN
167.99.185.245  x12 NXDOMAIN
174.138.10.64   x5  NXDOMAIN
178.128.191.106 x2  NXDOMAIN
178.128.235.120 x21 NXDOMAIN
206.189.118.88  x5  NXDOMAIN


Aruba:
188.213.166.229 x7  host229-166-213-188.serverdedicati.aruba.it
195.231.8.112   x38 host112-8-231-195.serverdedicati.aruba.it
195.231.8.114   x49 host114-8-231-195.serverdedicati.aruba.it
195.231.8.156   x69 host156-8-231-195.serverdedicati.aruba.it
195.231.8.159   x43 host159-8-231-195.serverdedicati.aruba.it
195.231.8.161   x47 host161-8-231-195.serverdedicati.aruba.it
195.231.8.18x45 host18-8-231-195.serverdedicati.aruba.it
195.231.8.182   x59 host182-8-231-195.serverdedicati.aruba.it
195.231.8.198   x53 host198-8-231-195.serverdedicati.aruba.it
195.231.8.210   x52 host210-8-231-195.serverdedicati.aruba.it
195.231.8.216   x45 host216-8-231-195.serverdedicati.aruba.it
195.231.8.30x39 host30-8-231-195.serverdedicati.aruba.it
195.231.8.52x53 host52-8-231-195.serverdedicati.aruba.it
195.231.8.53x34 host53-8-231-195.serverdedicati.aruba.it
195.231.8.81x59 host81-8-231-195.serverdedicati.aruba.it


Unifiedlayer:
142.4.10.217x1  142-4-10-217.unifiedlayer.com
142.4.15.173x32 142-4-15-173.unifiedlayer.com
142.4.23.125x12 142-4-23-125.unifiedlayer.com
162.144.35.28   x26 162-144-35-28.unifiedlayer.com
162.144.50.132  x5  162-144-50-132.unifiedlayer.com
162.144.68.157  x18 162-144-68-157.unifiedlayer.com
162.144.84.118  x2  162-144-84-118.unifiedlayer.com




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

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"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] Looking for GoDaddy email/DNS contact

[frnkblk]

It's cleaned up now -- maybe it automatically happened after the aforementioned 
quarantine?

Thanks,

Frank 

-Original Message-
From: mailop  On Behalf Of Bill Cole
Sent: Friday, April 26, 2019 3:27 PM
To: mailop@mailop.org
Subject: Re: [mailop] Looking for GoDaddy email/DNS contact

On 25 Apr 2019, at 23:49, frnk...@iname.com wrote:

> We had a customer not renew their domain name (IRONINGENUITY.COM), but 
> upon
> expiration their MX records were left still pointing to us.  We're 
> looking
> for a way for that to get cleaned up (ideally null MX record, second 
> best is
> to reset to GoDaddy's default MX record for such domains), but since 
> the
> customer doesn't want to renew the domain, don't know really where to 
> turn.

I'm not seeing the problem...

$ host IRONINGENUITY.COM
Host IRONINGENUITY.COM not found: 3(NXDOMAIN)

$ host -t ns IRONINGENUITY.COM b.gtld-servers.net
Using domain server:
Name: b.gtld-servers.net
Address: 192.33.14.30#53
Aliases:

Host IRONINGENUITY.COM not found: 3(NXDOMAIN)



-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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


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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Simon Lyall]

I've gone though and manually re-enabled all (hopefully) of the gmail 
users. I saw a few gmail addresses not disabled so possible not all were 
affected.


Simon.

On Sat, 27 Apr 2019, Simon Lyall wrote:

FYI

The below message was bounced by everyone (I assume) in the list 
whose address is hosted by gmail.


Date: Wed, 24 Apr 2019 08:44:58 -0600
From: Brielle Bruns 
Subject: Re: [mailop] The utility of spam folders

Error message similar to this:

SMTP error from remote mail server after end of data:
host aspmx.l.google.com [2a00:1450:400c:c00::1b]:
550-5.7.1 This message does not have authentication information or fails 
to pass
550-5.7.1 authentication checks. To best protect our users from spam, 
the

550-5.7.1 message has been blocked. Please visit
550-5.7.1  https://support.google.com/mail/answer/81126#authentication 
for more

550 5.7.1 information. i5si14352580wrp.442 - gsmtp


The subscriptions of around 160 list-members were suspended. I'll look at 
unsuspending them.


Simon.
List Moderator
Just back from Holiday

--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar




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



--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar


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

[mailop] Admin: Gmail users of mailop suspended due to bounces.

[Simon Lyall]

FYI

The below message was bounced by everyone (I assume) in the list 
whose address is hosted by gmail.


Date: Wed, 24 Apr 2019 08:44:58 -0600
From: Brielle Bruns 
Subject: Re: [mailop] The utility of spam folders

Error message similar to this:

SMTP error from remote mail server after end of data:
host aspmx.l.google.com [2a00:1450:400c:c00::1b]:
550-5.7.1 This message does not have authentication information or fails to 
pass
550-5.7.1 authentication checks. To best protect our users from spam, the
550-5.7.1 message has been blocked. Please visit
550-5.7.1  https://support.google.com/mail/answer/81126#authentication for 
more
550 5.7.1 information. i5si14352580wrp.442 - gsmtp


The subscriptions of around 160 list-members were suspended. I'll look at 
unsuspending them.


Simon.
List Moderator
Just back from Holiday

--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar




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