Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <885f93f0-36ec-d74f-7c5f-52b42f2d6...@jordan.maileater.net> you 
write:
>Hmm.  It would take MUA changes to be fully effective, but a possibility
>that comes to mind is to have mailing lists leave the original message
>absolutely unmodified, but wrap it in a message that comes "from" the
>mailing list.  That way everything about the message is verifiably true.

Please see other messages in this thread.  Wrapping messages is an old
idea, effectively making each message into a one-message digest,
something Mailman can already do.

The problem is that MUAs vary from so-so to awful when displaying them.

 
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

On 7/27/18 7:28 PM, Jordan Brown wrote:
> On 7/27/2018 4:18 PM, Richard Damon wrote:
>> Yes, there are existing formats that at least mostly represent this
>> in the message itself, but not for display. Especially that currently
>> the wrapping message would say it is from the list, but you really
>> want some way for it to say that in the MUA's message list, it should
>> indicate who the author of the embedded message was, not the 'author'
>> of the wrapping message. This probably means that we need a new
>> message content type to indicate it. 
>
> A message content type is one possibility, but other headers might
> also be reasonable.
>
>> Also, the MUA (or maybe their MTA) should know enough to pierce through
>> that wrapping message and give an indication that the wrapped message
>> passes or fails the appropriate tests. The current formatting doesn't
>> imply that that should happen.
>
> Shrug.  I wouldn't consider it to be silly for an MUA to apply those
> tests to any message/rfc822 part, whether or not it came from a
> mailing list.
>
> If I do a forward-as-attachment to forward a message to you, it would
> be good if you could independently verify that the forwarded message
> is from who it says it is from.
>
> Anyhow, it's clearly possible, probably with minimal standards for
> message metadata.  The problem (after getting agreement on the
> metadata) is getting an adequate number of MUAs to behave well with
> the wrapped messages.
>
Mark, maybe, but the option to reject, no, as the message might be an
older message that is being forwarded from an archive, and perhaps keys
or other settings have changed. Also, part of DMARC (SPF) can't be
tested for, as we don't have the original source the message was sent
from, so we can only make a DKIM test.

-- 
Richard Damon

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jordan Brown]

On 7/27/2018 4:18 PM, Richard Damon wrote:
> Yes, there are existing formats that at least mostly represent this in
> the message itself, but not for display. Especially that currently the
> wrapping message would say it is from the list, but you really want
> some way for it to say that in the MUA's message list, it should
> indicate who the author of the embedded message was, not the 'author'
> of the wrapping message. This probably means that we need a new
> message content type to indicate it. 

A message content type is one possibility, but other headers might also
be reasonable.

> Also, the MUA (or maybe their MTA) should know enough to pierce through
> that wrapping message and give an indication that the wrapped message
> passes or fails the appropriate tests. The current formatting doesn't
> imply that that should happen.

Shrug.  I wouldn't consider it to be silly for an MUA to apply those
tests to any message/rfc822 part, whether or not it came from a mailing
list.

If I do a forward-as-attachment to forward a message to you, it would be
good if you could independently verify that the forwarded message is
from who it says it is from.

Anyhow, it's clearly possible, probably with minimal standards for
message metadata.  The problem (after getting agreement on the metadata)
is getting an adequate number of MUAs to behave well with the wrapped
messages.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

On 7/27/18 6:41 PM, Jordan Brown wrote:
> On 7/25/2018 5:24 PM, Richard Damon wrote:
>> Yes, one set of solutions would involve defining standards of how to
>> compose composite messages, with standards on how to display them. A
>> major part of the current issue is that for anything more than a
>> single part plain text you can't be sure how it will be handled.
>
> I can't say that I'm a true expert, or that I've really investigated,
> but I believe you can wrap an entire message (with multiple parts)
> into a single part of the wrapper message.  I don't think you need any
> new message-structure standards.  You might need standards for headers
> that would say that that's what you've done, and you certainly would
> need MUA support.
>
> (And to others who have replied:  yes, all understood.  Like I said,
> adoption would be hard.)
>
Yes, there are existing formats that at least mostly represent this in
the message itself, but not for display. Especially that currently the
wrapping message would say it is from the list, but you really want some
way for it to say that in the MUA's message list, it should indicate who
the author of the embedded message was, not the 'author' of the wrapping
message. This probably means that we need a new message content type to
indicate it.

Also, the MUA (or maybe their MTA) should know enough to pierce through
that wrapping message and give an indication that the wrapped message
passes or fails the appropriate tests. The current formatting doesn't
imply that that should happen.

-- 
Richard Damon

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jordan Brown]

On 7/25/2018 5:24 PM, Richard Damon wrote:
> Yes, one set of solutions would involve defining standards of how to
> compose composite messages, with standards on how to display them. A
> major part of the current issue is that for anything more than a
> single part plain text you can't be sure how it will be handled.

I can't say that I'm a true expert, or that I've really investigated,
but I believe you can wrap an entire message (with multiple parts) into
a single part of the wrapper message.  I don't think you need any new
message-structure standards.  You might need standards for headers that
would say that that's what you've done, and you certainly would need MUA
support.

(And to others who have replied:  yes, all understood.  Like I said,
adoption would be hard.)

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/25/2018 04:03 AM, Stephen J. Turnbull wrote:
Let's be careful to distinguish between "DMARC" and the "p=reject" and 
"p=quarantine" policies.


Fair point.

(1) DMARC's reporting features *can* and *should* be used on all domains 
that send email, with very few exceptions.


Agreed.

(2) "p=reject" should never be used on domains that contain any 
non-transactional mailboxes (ie, mailboxes used as the From which might 
be reinjected into the mail system with changes).


I personally disagree.

I'll concede "SHOULD" in the typical sense that RFCs use it.  Thus my 
opinion is contrary to the recommendation.


This recommendation was actually in some early unofficial drafts or author 
discussions of RFC 7489, but doesn't appear to be in the Internet-Draft 
prepublication series, and it's definitely not in the published RFC. 
(I believe that keeping such verbiage out of the RFC is why the RFC is 
informational rather than normative.)


Odd.

Hey, did you really want to write that?  There's about a millennium of 
mail-RFC-writing and/or large site admin experience on the DMARC-WG.


Yes, I did.

I'm sure that people had the best of intentions.  I'm not trying to 
impugn anybody.  Mistakes happen.  Undesirable results happen.  A recent 
example that comes to mind is the renegotiation issue with a MitM on TLS 
1.2.


So, there's fundamental misunderstanding here somewhere.  DMARC depends 
on DKIM and SPF.  Neither can ensure that the *purported author domain* 
of an email can be authenticated when passed through a mailing list.


It's my understanding that one of the functions of DKIM was to allow 
messages to be forwarded, (with the body) unmodified, and still 
providing a high degree of certainty that (the signed portion of) the 
message was the same as it was submitted into SMTP.  (Assuming that the 
submission server did the DKIM signing and that it's the same domain as 
the purported sending email address.


I feel the need to pause for a moment and reflect on that assumption. 
As I type this, I realize that it's relatively easy to break that 
assumption without breaking DKIM.  …  Thus, DKIM itself can't "…ensure 
that the *purported author domain* of an email can be authenticated…"


I'm leaving that here in case it helps others who might have been 
confused by that fact like I was.


*The whole purpose of DMARC From alignment is to authenticate the author 
domain in the context of her message!*


Okay.

This is simply impossible, unless the signed portions of the message 
arrive at the destination *unchanged*, or the list is an authorized mail 
source of the author domain for SPF.


Agreed.

Much legitimate email *does* change them, however, and few lists 
cater exclusively to subscribers of the same administrative domain. 
(Of course getting list host IPs authorized as mail sources for all 
potential SPF-using posters would be a nightmare!)


You propose that mailing list should munge From (and in fact you've 
proposed that it should do so independent of DMARC, IIRC).


At a minimum, yes.  You could also state that I'm proposing regenerating 
a completely new and independent message, quite a bit more than munging 
a message.



AFAICS, this has three nasty effects (at least).

(1) It ensures that validation of From alignment of the actual author 
will *fail*, because the From header *must* be signed in DMARC.  (SPF is 
pretty useless in the context of mailing lists.)


Only if the From: header has the original sender's email address.  [1] 
If the From: header reflects the mailing list, there is no DMARC 
conflict with the original sender's domain.


[1]  I think it may be possible to move the email address into the human 
friendly portion of the address and replace the actual email address 
with that of the mailing list.  I.e.:


 From: Grant Taylor 

Becomes:

 From:  "Grant Taylor " 



It is my understanding that DMARC implementations are supposed to ignore 
the human friendly portion of the email address.  However I do not feel 
comfortable trusting that.  As such, I would likely alter the text that 
looks like an address in the human friendly portion to be something like 
this:


 From:  "Grant Taylor - gtaylor (at) tnetconsulting (dot) net" 



(2) It breaks all the quoting mechanisms in every existing MUA, which 
now instead of, e.g.,


 > Grant Taylor writes:

will insert

 > Grant Taylor  via Mailman-Users writes:


I don't know if I'd call that "broken" per say.  But I don't object to 
the point.



Some styles would look a little better, some worse.  All, gag me.


To each his / her own opinion.

This is imposing work on a lot of MUA authors, and it will be ongoing 
as mailing lists keep changing their munging styles.


I don't see how this imposes additional work on MUA authors.

Or are you suggesting that MUA authors alter what the MUA does in a 
perpetual game of whack-a-formatting-mole?



(3) Users may start to accept

 From: "Grant Taylor  via
  

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <885f93f0-36ec-d74f-7c5f-52b42f2d6...@jordan.maileater.net> you 
write:
>Hmm.  It would take MUA changes to be fully effective, but a possibility
>that comes to mind is to have mailing lists leave the original message
>absolutely unmodified, but wrap it in a message that comes "from" the
>mailing list.  That way everything about the message is verifiably true.

Yeah, we've tried that.  It would in effect make each message a
one-message digest.  Let me just say that it would take a LOT of
changes to a lot of MUAs to make that work acceptably.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

On 7/25/18 1:48 PM, Jordan Brown wrote:
> Hmm.  It would take MUA changes to be fully effective, but a possibility
> that comes to mind is to have mailing lists leave the original message
> absolutely unmodified, but wrap it in a message that comes "from" the
> mailing list.  That way everything about the message is verifiably true.
>
> A list-aware MUA could more or less transparently unwrap such a
> message.  It would probably display some indication that the message
> came through the ML - the name of the list, unsubscribe mechanism,
> archive pointers, ML header or footer text, et cetera, and maybe
> activate alternative "reply" options[*]  - but would largely present the
> message as "from" the original author, *via* the mailing list.
>
> Perhaps the wrapper message would look like today's munged ML messages -
> From: Real Person  / Reply-To: Real Person
>  - but a list-aware MUA would largely hide that.
>
> Of course there are a million details and getting adoption would be hard.
Yes, one set of solutions would involve defining standards of how to
compose composite messages, with standards on how to display them. A
major part of the current issue is that for anything more than a single
part plain text you can't be sure how it will be handled.

Yes, you can't be absolutely positive that every MUA will work right,
you at least have the defense that you did your best to be clear within
the standard, and perhaps the standard could even be worked that
existing non-conforming implementations are so bad that it is clear that
the user needs a new MUA.

-- 
Richard Damon

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jordan Brown]

Hmm.  It would take MUA changes to be fully effective, but a possibility
that comes to mind is to have mailing lists leave the original message
absolutely unmodified, but wrap it in a message that comes "from" the
mailing list.  That way everything about the message is verifiably true.

A list-aware MUA could more or less transparently unwrap such a
message.  It would probably display some indication that the message
came through the ML - the name of the list, unsubscribe mechanism,
archive pointers, ML header or footer text, et cetera, and maybe
activate alternative "reply" options[*]  - but would largely present the
message as "from" the original author, *via* the mailing list.

Perhaps the wrapper message would look like today's munged ML messages -
From: Real Person  / Reply-To: Real Person
 - but a list-aware MUA would largely hide that.

Of course there are a million details and getting adoption would be hard.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Joseph Brennan]

On Tue, Jul 24, 2018 at 8:20 PM Grant Taylor via Mailman-Users <
mailman-users@python.org> wrote:

>
> > Right, thereby causing a great deal of entirely legitimate mail that
> > DMARC cannot describe to go missing, along with a certain amount of spam.
>
> "legitimate mail that DMARC cannot describe"  That sounds distinctly
> like a problem with the DMARC specification, /not/ with use there of.


Well it is. The problem is that DMARC's notion of "alignment" contradicts
RFC 822, 2822, 5322, namely '''The "From:" field specifies the author(s) of
the message, that is, the mailbox(es) of the person(s) or system(s)
responsible for the writing of the message.''' and contradicts RFC 821,
2821, 5321 that describes the MAIL FROM address as the address used "to
report errors". Mailing lists fully comply with the standard by keeping the
writer's address in the Header From and by putting the address to report
errors in the MAIL FROM. Nothing in email standards stated or even implied
that the two addresses need to be the same.

Of course a system can reject any email message for any reason or no
reason, so all I can do is point out that lack of "alignment" is a silly
reason for rejecting list mail. For transactional mail from sources like
financial institutions, where the sender can state that the two addresses
should "align", then it makes a lot more sense.

Joseph Brennan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Stephen J. Turnbull]

Grant Taylor via Mailman-Users writes:
 > On 07/24/2018 03:16 PM, John Levine wrote:
 > > Turning it on for aol.com, yahoo.com, and other domains with user 
 > > mailboxes,
 > 
 > So, are you stating that DMARC should NOT be used on domains that 
 > (predominantly) contain end user mailboxes?

Let's be careful to distinguish between "DMARC" and the "p=reject" and
"p=quarantine" policies.

(1) DMARC's reporting features *can* and *should* be used on all
domains that send email, with very few exceptions.

(2) "p=reject" should never be used on domains that contain any
non-transactional mailboxes (ie, mailboxes used as the From which
might be reinjected into the mail system with changes).  This
recommendation was actually in some early unofficial drafts or
author discussions of RFC 7489, but doesn't appear to be in the
Internet-Draft prepublication series, and it's definitely not in
the published RFC.  (I believe that keeping such verbiage out of
the RFC is why the RFC is informational rather than normative.)

 > "legitimate mail that DMARC cannot describe"  That sounds distinctly 
 > like a problem with the DMARC specification, /not/ with use there of.

Hey, did you really want to write that?  There's about a millennium of
mail-RFC-writing and/or large site admin experience on the DMARC-WG.

So, there's fundamental misunderstanding here somewhere.  DMARC
depends on DKIM and SPF.  Neither can ensure that the *purported
author domain* of an email can be authenticated when passed through a
mailing list.  *The whole purpose of DMARC From alignment is to
authenticate the author domain in the context of her message!*  This is
simply impossible, unless the signed portions of the message arrive at
the destination *unchanged*, or the list is an authorized mail source
of the author domain for SPF.  Much legitimate email *does* change them,
however, and few lists cater exclusively to subscribers of the same
administrative domain.  (Of course getting list host IPs authorized as
mail sources for all potential SPF-using posters would be a nightmare!)

You propose that mailing list should munge From (and in fact you've
proposed that it should do so independent of DMARC, IIRC).  AFAICS,
this has three nasty effects (at least).

(1) It ensures that validation of From alignment of the actual author
will *fail*, because the From header *must* be signed in DMARC.
(SPF is pretty useless in the context of mailing lists.)

(2) It breaks all the quoting mechanisms in every existing MUA, which
now instead of, e.g.,

> Grant Taylor writes:

will insert

> Grant Taylor  via Mailman-Users writes:

Some styles would look a little better, some worse.  All, gag me.
This is imposing work on a lot of MUA authors, and it will be
ongoing as mailing lists keep changing their munging styles.

(3) Users may start to accept

From: "Grant Taylor  via
  All-Passwords-Yours-Now-Ours ML" 

(or whatever their MUA displays) as indicating authentic email
from you, because a lot of authentic mail indeed looks like that
in your scheme.  (This is a controversial point: a lot of security
pundits believe that most users will click on anything anyway.)

 > I feel like DMARC requires a paradigm shift in how email is forwarded 
 > and handled by mailing lists.

Three points for your consideration here:

(1) There's a fundamental problem, though: the *only* paradigm shift
compatible with DMARC's goal of authenticating the author's domain
is to *pass the message through with all signed portions
unchanged.*  (SPF doesn't have this problem: SPF can't authenticate
author domains of mailing list posts *at all*, unless the list is
hosted by the author's domain or its host's IP is listed as a valid
mail source by the author's domain!)

(2) DMARC is a *private protocol*.  RFC 7489 is *Informational*, it
has *no normative implications* for the rest of us.  We would be
perfectly conformant to all normative RFCs if we decided that mail
from sites that have a p=reject policy is undeliverable and
dangerous, and rejected it.  We're not going to do that, nor even
offer it as an option, but I'll leave that here for consideration.

(3) ARC, if the mailing list is accepted as trustworthy by recipients,
requires *no* change to mailing list behavior (aside from
participation in the ARC protocol, of course).  If not trusted,
we're back in the world of (1) and (2).

 > I suspect "imposed on innocent bystanders" and "not their problem" can 
 > also be used to describe requiring reverse DNS, SPF, and DKIM.

No, it can't, not in the same way.

(1) All of the above can be implemented in the MTA without any change
in end user or Mediator behavior.  These upgrades were frequently
transparent to admins of virtual domains (except that their mail
started working to sites it used to fail at).  Not so, DMARC.
Most mailing

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 08:47 PM, Grant Taylor via Mailman-Users wrote:
> I am talking about modifying the From: header such that the message no
> longer had any conflict with the original published DMARC records.


Consider this:

If I create a novel called _The Hexadecimal Kid and His Faithful Dog
ASCII_ [1] and submit the manuscript to a publisher and the publisher
type sets it, prints thousands of bound copies with a title page with
added information about the publisher and maybe adds a subtitle and some
info on a dust jacket, and delivers those printed books to book sellers,
has the publisher now become the author of the book or am I still the
author?

RFC 5322 is clear

   The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.

I.e. the mailbox(es) in the From: header are those of the author. It
doesn't matter if the author is in a comment or display name, if the
mailbox is that of the list, you are claiming the list is the author of
the post.

I'm not saying it is not expedient or even possibly necessary to Munge
the From: in this way. I'm only saying it is a violation of RFC 5322
unless you believe the publisher is author of my book.

[1] Bonus points for anyone who gets the reference.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:41 PM, John Levine wrote:
Quite right.  Beyond the standards theology, there is the practical 
problem that where the message list in your inbox used to tell you who 
wrote the list messages, now it all seems to come from the list alias.


That's where the human friendly portion of the From: header comes into play.

I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

This can show up in the index of a mailbox.

Or the two lines that I'm suggesting prefixing the body with.

 Grant Taylor  wrote the following:

Granted, that doesn't show up in the index of a mailbox.

Both methods tell you who wrote the message content.

Do you have any doubt about who wrote the first four lines of this 
message?  Does the fact that the From: header has my name (via 
Mailman-Users) cause you to believe that I wrote "Quite right.  … list 
alias."?


Or does the fact that there is quoting "> " change that?

In my world, some people's contributions are a lot more interesting 
than others,


Agreed.


and losing the info about who wrote what makes all lists less useful.


I'm not suggesting losing information about who wrote what.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 08:11 PM, Richard Damon wrote:

Do you understand how DMARC works?


Yes, I do believe that I do understand how DMARC works.

I have yet to have someone show me something (else) about DMARC that I'm 
not aware of.


Yahoo.com has an entry in their DNS that says they want DMARC protection, 
and if you can’t verify that the message came from them unmodified to 
reject it.


Yep.

I'm doing exactly that.

Unless the mailing list claims authorship of the message by changing the 
From: of the message (and thus making it hard to tell who really said the 
words), the list relaying the message with the slightest modification 
of the Subject or Body will cause it to fail DMARC, as DMARC says that 
the From: header is the king for verification.


I am talking about modifying the From: header such that the message no 
longer had any conflict with the original published DMARC records.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

Thus removing any conflict with any DMARC records published by 
tnetconsulting.net


Since the message is now from the Mailman-Users mailing list, it's 
perfectly possible to insert a line at the start of the message like the 
following:


 Grant Taylor  wrote the following:

Only if you think that mailman-users is the author of your message here, 
and that your mailing list is the proper author of every message that 
goes through your mailing list.


I believe that the Mailman-Users mailing list is the entity responsible 
for sending the message to each and every subscriber.  I believe the 
content that the Mailman-Users mailing list is sending is strongly based 
on content provided by someone that sent a message to said mailing list.


I know that the mailing list did not generate the content.  I also know 
that it is sending content heavily based on content from someone else.


Base SPF isn’t an issue. All messages leaving my mailing list pass 
SPF because I publish a SPF record, and the message have an envelope 
From of my mailing list.


What is (was) your (original) motivation for munging the envelope to be 
from the mailing list?  Are (were) you (originally) doing it because you 
want to take advantage of V.E.R.P.?  Or are (were) you (originally) 
doing it to avoid SPF issues?


I know a number of people that only started munging the envelope from 
address because of SPF issues.


You may also run into issues with SPF alignment with DMARC if you don't 
also modify the From: header.


(I can't tell what domain you are referring to.  I don't see SPF / TXT 
records for damon-family.org and I don't know if you are referring to 
some other domain.)


Again, I can verify the DMARC of the incoming message, but unless I want 
to claim authorship by changing the From, I can not send it and have it 
pass DMARC.


Which, IMHO, is what DMARC is supposed to be able to enforce.

Only if you consider the mailing list the Author of every message relayed 
by it.


I do consider the MLM as being the author / creator / submitter of the 
SMTP message.


I view the person that sent the message as being the author / creator / 
submitter of the body content in said SMTP message.


The MLM DOES change the Envelope from, it really wants to so it gets the 
bounces back so it can process it. That means the outgoing message can 
pass SPF as SPF is written. What it doesn’t pass is the modification 
to SPF that DMARC specifies that says that the only domain to validate 
in the inside From: Header, the Envelope doesn’t count.


Yep, VERP.

So you REALY want to see your view of the mailing list as EVERY message 
is ‘From’ Mailman-users, with no indication of who wrote really 
wrote the message? Thus you lose the ability to easily block


Not quite.

I would much rather have the human friendly portion of the address 
remain what was originally sent.


I.e.

 From: Grant Taylor 

Becomes:

 From: Grant Taylor via Mailman-Users 

I would also be interested in something like the following.

 From: Grant Taylor gtaylor at tnetconsulting dot net via 
Mailman-Users 


I believe that retains the attribution that I believe you (and many 
others) want to retain.


Seeing as how the new outgoing message is completely new, it's perfectly 
possible to add something like the following as the first two lines of 
the message:


 Grant Taylor  wrote the following:

So you don’t think mailing list should do any modifications to the 
message, or they need to claim authorship.


"DMARC says that if you get a message from me, it MUST have come 
straight from me"


The key being "it MUST have come straight from me".

Thus messages that pass through a mailing list (or forwarded in any way) 
fail the "come straight from me" portion.



So you see this thread as the mailing list arguing with itself?


I see this thread as a friendly / academic discussion from many 
different mailing list subscribers who send messages to and receive 
messages from said mailing list.

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <88902b3b-7cb3-7991-15c4-4dbc10762...@msapiro.net> you write:
>In that sense, many of us think that the person who wrote the post is
>still the author even if the list made a few simple changes that didn't
>alter the basic text of the original message while the list is a Sender:
>
>That's why we believe that Munge From is non-compliant. ...

Quite right.  Beyond the standards theology, there is the practical
problem that where the message list in your inbox used to tell you who
wrote the list messages, now it all seems to come from the list alias.
In my world, some people's contributions are a lot more interesting
than others, and losing the info about who wrote what makes all lists
less useful.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 07:11 PM, Richard Damon wrote:
> 
> 
>> On Jul 24, 2018, at 9:43 PM, Grant Taylor via Mailman-Users 
>>  wrote:
>>
>> If you view the message to am MLM as as separate end-to-end delivery process 
>> from the message from an MLM to the subscriber, DMARC can and does work with 
>> MLMs.
> 
> Only if you consider the mailing list the Author of every message relayed by 
> it.


To elaborate a bit. RFC 5322 says

   The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.

In that sense, many of us think that the person who wrote the post is
still the author even if the list made a few simple changes that didn't
alter the basic text of the original message while the list is a Sender:

That's why we believe that Munge From is non-compliant. You may think
that the list is in fact "the person(s) or system(s) responsible for the
writing of the message", but many people don't agree.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

> On Jul 24, 2018, at 9:43 PM, Grant Taylor via Mailman-Users 
>  wrote:
> 
>> On 07/24/2018 06:59 PM, Richard Damon wrote:
>> You CAN’T strip DMARC.
> 
> I can most certainly strip any DKIM related headers from messages that are 
> coming into my server on their way to my mailing list.
> 
> I'm not talking about altering other people's view of DNS.  (That's a 
> completely different topic.)

Do you understand how DMARC works? Yahoo.com has an entry in their DNS that 
says they want DMARC protection, and if you can’t verify that the message came 
from them unmodified to reject it. 
> 
>> If a domain has activated DMARC for itself (via its DNS record) then it is 
>> telling all other domains in the world that any mail that says it is from 
>> this domain MUST pass the DMARC test.  This means that either it must be 
>> validly signed BY THEM or come from a server THEY have indicated is them. A 
>> setting of reject (which is what AOL and YAHOO use) indicates that other 
>> people are not to accept messages that appear to be from them that fail 
>> these tests.
> 
> Agreed.
> 
> I'm saying that the email server hosting the mailing list should strip DKIM 
> (related) headers from messages before they go into the mailing list software.

Which doesn’t help with DMARC.

> 
> I'm also saying that said email server should apply all the enforcement 
> checks that you aptly described.
> 
> 
>> See above, a re-mailer that changes a message fails DMARC.
> 
> I believe the SMTP path between the originating sender and the mailing list 
> is distinct and completely different from the separate SMTP path between the 
> mailing list and subscribers servers.
> 
> I'm free to make any and all changes to the message as it passes through the 
> mailing list as long as I do the following:
> 
> 1)  Remove any and all security headers from messages going into the mailing 
> list.
> 2)  I (re)add appropriate security headers to messages exiting from the 
> mailing list.  Note:  These headers should reflect the mailing list and NOT 
> the original sender.

Unless the mailing list claims authorship of the message by changing the From: 
of the message (and thus making it hard to tell who really said the words), the 
list relaying the message with the slightest modification of the Subject or 
Body will cause it to fail DMARC, as DMARC says that the From: header is the 
king for verification.

> 
>> See above
> 
> Hypothetical scenario:
> 
> Message from subscri...@aol.com comes into my email server hosting a Mailman 
> mailing list.
> 
> 1)  Apply all applicable filters (reverse DNS, SPF, DKIM, DMARC, Spam, Virus, 
> etc) as early in the SMTP process as possible.  Reject (as appropriate) 
> anything that fails respective tests.
> 2)  Strip all applicable security headers between the MTA and the MLM.
> 3)  Mailing list manager does it's thing, including munging the From: as it 
> generates new messages that go out through the local MTA.
> 4)  Local MTA adds appropriate new security headers to the messages.
> 
> Note:  #4 absolutely MUST use data that reflects the local domain / sending 
> server.
> 
> I still see nothing that prevents the MLM of doing anything and everything 
> that it wants to do to the messages that pass through it.
> 
> Note:  There is ZERO association between the inbound message and the many 
> outbound messages, save for body content being based on the original incoming 
> message.

Only if you think that mailman-users is the author of your message here, and 
that your mailing list is the proper author of every message that goes through 
your mailing list.
> 
>> So you don’t see the problem with AOL and YAHOO changing there settings so 
>> that 99% of the discussion mailing list (guesings at percentage) are unable 
>> to deliver mail from subscribers who are AOL or YAHOO users, and if they 
>> try, they get back delivery errors that make the list software think that 
>> those users have bad email addresses and get unsubscribed for delivery 
>> errors.
> 
> I think your percentage is high.  I just don't know how high.  But that 
> nuance doesn't really matter.
> 
> I see what was being done before (and some still do now) as a problem. A 
> problem that pre-existed AOL and Yahoo or their use of DMARC.  They just 
> happened to be early adopters that did a cannon ball into the otherwise 
> relatively calm pool.
> 
> I believe that similar problems happened when people started using -all in 
> their SPF records too.  Granted, VERP, which had been adopted by many mailing 
> lists, altered that somewhat.
> 
> I view the equations as being the same, just with significantly different 
> values in the variables.

Base SPF isn’t an issue. All messages leaving my mailing list pass SPF because 
I publish a SPF record, and the message have an envelope From of my mailing 
list.
> 
>> Those other systems now have a very tough choice, don’t honor the DMARC 
>> setting, and thus allow forgeries from banks and such to go through, o

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:59 PM, Richard Damon wrote:

You CAN’T strip DMARC.


I can most certainly strip any DKIM related headers from messages that 
are coming into my server on their way to my mailing list.


I'm not talking about altering other people's view of DNS.  (That's a 
completely different topic.)


If a domain has activated DMARC for itself (via its DNS record) then it 
is telling all other domains in the world that any mail that says it is 
from this domain MUST pass the DMARC test.  This means that either it 
must be validly signed BY THEM or come from a server THEY have indicated 
is them. A setting of reject (which is what AOL and YAHOO use) indicates 
that other people are not to accept messages that appear to be from them 
that fail these tests.


Agreed.

I'm saying that the email server hosting the mailing list should strip 
DKIM (related) headers from messages before they go into the mailing 
list software.


I'm also saying that said email server should apply all the enforcement 
checks that you aptly described.




See above, a re-mailer that changes a message fails DMARC.


I believe the SMTP path between the originating sender and the mailing 
list is distinct and completely different from the separate SMTP path 
between the mailing list and subscribers servers.


I'm free to make any and all changes to the message as it passes through 
the mailing list as long as I do the following:


1)  Remove any and all security headers from messages going into the 
mailing list.
2)  I (re)add appropriate security headers to messages exiting from the 
mailing list.  Note:  These headers should reflect the mailing list and 
NOT the original sender.



See above


Hypothetical scenario:

Message from subscri...@aol.com comes into my email server hosting a 
Mailman mailing list.


1)  Apply all applicable filters (reverse DNS, SPF, DKIM, DMARC, Spam, 
Virus, etc) as early in the SMTP process as possible.  Reject (as 
appropriate) anything that fails respective tests.

2)  Strip all applicable security headers between the MTA and the MLM.
3)  Mailing list manager does it's thing, including munging the From: as 
it generates new messages that go out through the local MTA.

4)  Local MTA adds appropriate new security headers to the messages.

Note:  #4 absolutely MUST use data that reflects the local domain / 
sending server.


I still see nothing that prevents the MLM of doing anything and 
everything that it wants to do to the messages that pass through it.


Note:  There is ZERO association between the inbound message and the 
many outbound messages, save for body content being based on the 
original incoming message.


So you don’t see the problem with AOL and YAHOO changing there settings 
so that 99% of the discussion mailing list (guesings at percentage) are 
unable to deliver mail from subscribers who are AOL or YAHOO users, and 
if they try, they get back delivery errors that make the list software 
think that those users have bad email addresses and get unsubscribed 
for delivery errors.


I think your percentage is high.  I just don't know how high.  But that 
nuance doesn't really matter.


I see what was being done before (and some still do now) as a problem. 
A problem that pre-existed AOL and Yahoo or their use of DMARC.  They 
just happened to be early adopters that did a cannon ball into the 
otherwise relatively calm pool.


I believe that similar problems happened when people started using -all 
in their SPF records too.  Granted, VERP, which had been adopted by many 
mailing lists, altered that somewhat.


I view the equations as being the same, just with significantly 
different values in the variables.


Those other systems now have a very tough choice, don’t honor the DMARC 
setting, and thus allow forgeries from banks and such to go through, 
or honor it to the detriment of their customers trying to use mailing 
lists.


I believe that mailing lists (or their hosting MTAs) SHOULD do DMARC 
(and DKIM and SPF) filtering in as strict a manner as the purported 
sending domain desires.


Thus blocking the undesirable messages that you refer to.

When they first did this and the problems started, one solution that 
was being proposed was to just kick all AOL and YAHOO users off all 
mailing lists.


I do not believe that the problem started then.  It may very well be 
that it became well enough known as enough people were effected that 
people that didn't know about it before suddenly learned about it.


I believe the problem was known about before AOL and Yahoo implemented 
DMARC.


I feel like kicking AOL and Yahoo users off of mailing lists is an 
unnecessary Draconian knee jerk reaction.  Something that should be 
avoided at all costs.



The problem with DMARC is that it DOES attempt to protect end-to-end.


I obviously disagree.  Particularly on what the receiving "end" is.

If you view the message to am MLM as as separate end-to-end delivery 
process from the message from an MLM 

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 06:51 PM, Mark Sapiro wrote:
The stolen address books were used to send phishing emails purportedly 
from the owner of the address book the the addresses in the book.


I.e., a message From: a_known_fri...@yahoo.com saying things look at 
this great thing I found and a URL to evilsite.com.


Trivial to harvest addresses, but not trivial to know a known associate 
to send the mail From:.


I hadn't thought about the association of the metadata.  Thank you for 
clarifying.


I do question how much more spam was sent by stealing address books from 
large providers compared to viruses / malware doing the same with 
address books on infected machines.


In this context, the innocents are subscribers to mailing lists who 
find themselves unsubscribed by bounce processing because their ISPs 
reject list posts From: other_us...@yahoo.com and the operators of those 
mailing lists.


Indeed, unfortunately "friendly fire".  :-/

Of course, you seem to feel that these lists were wrong from the beginning 
for not claiming authorship of the posts by replacing the From: header,


Yes, that's in line with my current view.


but at the time, this wasn't even an option for most lists.


Lack of an option does not preclude the need for it.

Similarly, ignorance of an option does not preclude the need for it.

Admittedly, I've long struggled with how I thought discussion mailing 
lists should behave.  Originally I hadn't given any thought to munging 
the From: like is suggested for DMARC.  That being said, I did want to 
direct replies back to the discussion list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

>> On Jul 24, 2018, at 3:20 PM, Grant Taylor via Mailman-Users 
>>  wrote:
>> 
>> On 07/22/2018 04:25 PM, Richard Damon wrote:
>> What actions do you think mailing lists are doing improperly?
> 
> I personally believe that mailing lists are their own end entity, just like 
> our individual mailboxes.  (Particularly discussion mailing lists.)  I also 
> believe that SPF, DKIM, and DMARC are meant to protect between said 
> endpoints; message submitter and terminal mailbox.
> 
> Thus I think that DKIM and DMARC should be stripped from messages prior to 
> entering the mailing list.  The mailing list does it's thing.  Then DKIM and 
> DMARC are applied anew to the messages as they leave the server hosting the 
> mailing list.

You CAN’T strip DMARC. If a domain has activated DMARC for itself (via its DNS 
record) then it is telling all other domains in the world that any mail that 
says it is from this domain MUST pass the DMARC test. This means that either it 
must be validly signed BY THEM or come from a server THEY have indicated is 
them. A setting of reject (which is what AOL and YAHOO use) indicates that 
other people are not to accept messages that appear to be from them that fail 
these tests.
> 
>> Note, the subject modification is a long standing feature of mailing list, 
>> which is one thing that breaks DMARC, though I might be willing to give that 
>> up.
> 
> Mailing lists, as I view them, are free to mung messages to their hearts 
> content in the paradigm that I use.

See above, a re-mailer that changes a message fails DMARC.
> 
>> The modification of the message body to add a header or footer is also 
>> common, and in some places effectively required by law.
> 
> Agreed.
> 
> Such is perfectly compatible with my paradigm.

See above
> 
>> If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t have 
>> been quite as bad. But they ABUSED DMARC by their settings.
> 
> I still don't grok what you are considering "abuse" in this context?
> 
> Rather than speculating, please clarify what the abusive activity was.
> 
>> By the design of DMARC, AOL and Yahoo should have informed their users that 
>> they were changing the Terms of Service of their email systems, and now all 
>> their users are effectively prohibited to use any form of re-mailing 
>> systems, including most forms of (external) mailing lists. Instead they just 
>> told the world, we aren’t going to follow the normal rules, you deal with it.
> 
> I have a different interpretation.
> 
> My understanding is that AOL and Yahoo leveraged DMARC to expressly identify 
> messages that originated from AOL and Yahoo.  Or said another way, they 
> leveraged DMARC to make it easy for receiving servers to identify messages 
> that are not being sent from AOL or Yahoo servers /during/ that current SMTP 
> transaction.
> 
> I feel the need to insert a nod towards the fact that postmasters are free to 
> run their infrastructure the way that they see fit.
> 
> I also do not feel like the terms of service between AOL or Yahoo and their 
> end users changed.
> 
> AOL and Yahoo simply published information to make it easier for the world to 
> identify if messages in the scope of an SMTP session are coming from AOL or 
> Yahoo servers.  They also published their desire for receiving servers to 
> reject messages that don't pass said published information.
> 
> Did they do so knowing that there would likely be a problem with traditional 
> .forward(ing) and mailing lists?  Quite likely.  Was an internal business 
> decision made that publishing such information and dealing with the 
> ramifications of .forward(ing) and mailing lists more important than allowing 
> bad actors to continue pretending to be AOL or Yahoo?  Extremely likely.
> 
> IMHO AOL and Yahoo made a business decision.  Would you make the same 
> business decision?  Maybe, maybe not.
> 
> Note:  Both AOL's and Yahoo's business decision works perfectly fine in my 
> paradigm.
> 

So you don’t see the problem with AOL and YAHOO changing there settings so that 
99% of the discussion mailing list (guesings at percentage) are unable to 
deliver mail from subscribers who are AOL or YAHOO users, and if they try, they 
get back delivery errors that make the list software think that those users 
have bad email addresses and get unsubscribed for delivery errors. Those other 
systems now have a very tough choice, don’t honor the DMARC setting, and thus 
allow forgeries from banks and such to go through, or honor it to the detriment 
of their customers trying to use mailing lists. When they first did this and 
the problems started, one solution that was being proposed was to just kick all 
AOL and YAHOO users off all mailing lists. 

>> Yes, there is a fundamental issue with email that it is easy to spoof. 
>> Fixing it is going to be a significant issue, and possible a complete 
>> recreation of the system.
> 
> I don't see a specific need to recreate the system.
> 
>> The issue i

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/24/2018 05:20 PM, Grant Taylor via Mailman-Users wrote:
> On 07/24/2018 03:16 PM, John Levine wrote:
>> Turning it on for aol.com, yahoo.com, and other domains with user
>> mailboxes,
> 
> So, are you stating that DMARC should NOT be used on domains that
> (predominantly) contain end user mailboxes?


Many of us believe that DMARC was developed for domains such as
financial institutions and others in order to combat phishing attacks.
The developers of the DMARC standard never intended it to be used by
domains that provide email addresses for personal use.


>> to outsource the pain of the spam they were getting
> 
> I'm not completely following you.  Are you referring to filtering of
> inbound email that AOL / Yahoo / etc. were having to do?  If so, I don't
> see how publishing DMARC effects that.  (I assume that they did not need
> to publish records to enhance filtering email from themselves.)  Or are
> you referring to "the pain" as being the push back / flack from the rest
> of the email industry for spoofed messages purporting to be from AOL /
> Yahoo / etc?


The stolen address books were used to send phishing emails purportedly
from the owner of the address book the the addresses in the book.

I.e., a message From: a_known_fri...@yahoo.com saying things look at
this great thing I found and a URL to evilsite.com.


> IMHO it has been trivial to harvest email addresses for a LONG time.  As
> such, I think that address books are simply a convenient list and not
> strictly related.  Please correct me if I'm wrong.


Trivial to harvest addresses, but not trivial to know a known associate
to send the mail From:.


> Please elaborate on what "the cost" is and entails.  Are you referring
> to anything more than the fallout of not being able to (easily) forward
> email in a DMARC compliant manner?
> 
> I suspect "imposed on innocent bystanders" and "not their problem" can
> also be used to describe requiring reverse DNS, SPF, and DKIM.


In this context, the innocents are subscribers to mailing lists who find
themselves unsubscribed by bounce processing because their ISPs reject
list posts From: other_us...@yahoo.com and the operators of those
mailing lists.

Of course, you seem to feel that these lists were wrong from the
beginning for not claiming authorship of the posts by replacing the
From: header, but at the time, this wasn't even an option for most lists.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/24/2018 03:16 PM, John Levine wrote:
Turning it on for aol.com, yahoo.com, and other domains with user 
mailboxes,


So, are you stating that DMARC should NOT be used on domains that 
(predominantly) contain end user mailboxes?



to outsource the pain of the spam they were getting


I'm not completely following you.  Are you referring to filtering of 
inbound email that AOL / Yahoo / etc. were having to do?  If so, I don't 
see how publishing DMARC effects that.  (I assume that they did not need 
to publish records to enhance filtering email from themselves.)  Or are 
you referring to "the pain" as being the push back / flack from the rest 
of the email industry for spoofed messages purporting to be from AOL / 
Yahoo / etc?



due to letting user address books be stolen.


I don't know about AOL's security posture, but I do have a little idea 
about how bad Yahoo's was.  -  I still don't know that I would say that 
they allowed it, as in welcomed it.


IMHO it has been trivial to harvest email addresses for a LONG time.  As 
such, I think that address books are simply a convenient list and not 
strictly related.  Please correct me if I'm wrong.


Right, thereby causing a great deal of entirely legitimate mail that 
DMARC cannot describe to go missing, along with a certain amount of spam.


"legitimate mail that DMARC cannot describe"  That sounds distinctly 
like a problem with the DMARC specification, /not/ with use there of.


Aside:  The (relatively?) recent conversion from analog TV to digital TV 
broadcasting in the US comes to mind.


I feel like DMARC requires a paradigm shift in how email is forwarded 
and handled by mailing lists.  (I'm sure there are some other uses that 
I'm forgetting.)  Much like the aforementioned conversion from analog TV 
to digital TV.


Or similarly the requirement for reverse DNS for mail servers.  Personal 
opinions aside, it seems as if the email industry has decided that 
requiring reverse DNS is a mostly good thing.  Or that the good 
(slightly) outweighs the bad.



We've been cleaning up their mess ever since.


I question if the mess is /really/ AOL's or Yahoo's doing, or if instead 
the problem was really related to (what I'm going to describe as) a 
questionable way of operating that we now must change to play well with 
DMARC.


Yes, they explicitly decided that the costs they imposed on innocent 
bystanders were Not Their Problem.


Please elaborate on what "the cost" is and entails.  Are you referring 
to anything more than the fallout of not being able to (easily) forward 
email in a DMARC compliant manner?


I suspect "imposed on innocent bystanders" and "not their problem" can 
also be used to describe requiring reverse DNS, SPF, and DKIM.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <78baab65-f7d3-ce56-bc36-a16a15118...@spamtrap.tnetconsulting.net> 
you write:
>> If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t 
>> have been quite as bad. But they ABUSED DMARC by their settings.
>
>I still don't grok what you are considering "abuse" in this context?
>
>Rather than speculating, please clarify what the abusive activity was.

Turning it on for aol.com, yahoo.com, and other domains with user
mailboxes, to outsource the pain of the spam they were getting due
to letting user address books be stolen.

>My understanding is that AOL and Yahoo leveraged DMARC to expressly 
>identify messages that originated from AOL and Yahoo.  Or said another 
>way, they leveraged DMARC to make it easy for receiving servers to 
>identify messages that are not being sent from AOL or Yahoo servers 
>/during/ that current SMTP transaction.

Right, thereby causing a great deal of entirely legitimate mail that
DMARC cannot describe to go missing, along with a certain amount of
spam.  We've been cleaning up their mess ever since.

R's,
John

PS:

>Did they do so knowing that there would likely be a problem with 
>traditional .forward(ing) and mailing lists?  Quite likely.  Was an 
>internal business decision made that publishing such information and 
>dealing with the ramifications of .forward(ing) and mailing lists more 
>important than allowing bad actors to continue pretending to be AOL or 
>Yahoo?  Extremely likely.

Yes, they explicitly decided that the costs they imposed on
innocent bystanders were Not Their Problem.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 04:25 PM, Richard Damon wrote:

What actions do you think mailing lists are doing improperly?


I personally believe that mailing lists are their own end entity, just 
like our individual mailboxes.  (Particularly discussion mailing lists.) 
 I also believe that SPF, DKIM, and DMARC are meant to protect between 
said endpoints; message submitter and terminal mailbox.


Thus I think that DKIM and DMARC should be stripped from messages prior 
to entering the mailing list.  The mailing list does it's thing.  Then 
DKIM and DMARC are applied anew to the messages as they leave the server 
hosting the mailing list.


Note, the subject modification is a long standing feature of mailing 
list, which is one thing that breaks DMARC, though I might be willing 
to give that up.


Mailing lists, as I view them, are free to mung messages to their hearts 
content in the paradigm that I use.


The modification of the message body to add a header or footer is also 
common, and in some places effectively required by law.


Agreed.

Such is perfectly compatible with my paradigm.

If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t 
have been quite as bad. But they ABUSED DMARC by their settings.


I still don't grok what you are considering "abuse" in this context?

Rather than speculating, please clarify what the abusive activity was.

By the design of DMARC, AOL and Yahoo should have informed their users 
that they were changing the Terms of Service of their email systems, 
and now all their users are effectively prohibited to use any form 
of re-mailing systems, including most forms of (external) mailing 
lists. Instead they just told the world, we aren’t going to follow 
the normal rules, you deal with it.


I have a different interpretation.

My understanding is that AOL and Yahoo leveraged DMARC to expressly 
identify messages that originated from AOL and Yahoo.  Or said another 
way, they leveraged DMARC to make it easy for receiving servers to 
identify messages that are not being sent from AOL or Yahoo servers 
/during/ that current SMTP transaction.


I feel the need to insert a nod towards the fact that postmasters are 
free to run their infrastructure the way that they see fit.


I also do not feel like the terms of service between AOL or Yahoo and 
their end users changed.


AOL and Yahoo simply published information to make it easier for the 
world to identify if messages in the scope of an SMTP session are coming 
from AOL or Yahoo servers.  They also published their desire for 
receiving servers to reject messages that don't pass said published 
information.


Did they do so knowing that there would likely be a problem with 
traditional .forward(ing) and mailing lists?  Quite likely.  Was an 
internal business decision made that publishing such information and 
dealing with the ramifications of .forward(ing) and mailing lists more 
important than allowing bad actors to continue pretending to be AOL or 
Yahoo?  Extremely likely.


IMHO AOL and Yahoo made a business decision.  Would you make the same 
business decision?  Maybe, maybe not.


Note:  Both AOL's and Yahoo's business decision works perfectly fine in 
my paradigm.


Yes, there is a fundamental issue with email that it is easy to 
spoof. Fixing it is going to be a significant issue, and possible a 
complete recreation of the system.


I don't see a specific need to recreate the system.

The issue is that to create such a new system is a major job. Such a 
redesign would need to look at ALL current uses and either decide that 
such uses were no longer valid or to accommodate them.


I am interested to see what others would propose that offers the same 
good points of our existing system (SMTP) without any (or at least 
fewer) bad points.


DMARC somewhat intentionally did not consider mailing list, because they 
didn’t have a good solution to handle them, and their intended usage, 
the protection of ‘valuable’ mail somewhat excluded the use of such 
services.


I think you and I have a fundamentally different view of what is being 
protected and not.


In my view, SPF, DKIM, and DMARC do a perfectly fine job of protecting 
messages between the sender and the mail recipient that they specify.


In your view (as I understand it), SPF, DKIM, and DMARC do a 
questionable job protecting messages between the sender and the ultimate 
mail recipient through an unknown number of intermediaries that may 
forward and / or expand to one or more other, different, recipients than 
the sender stated.


IMHO, much like STARTTLS protects a segment of the over all 
communications path between the sender and the ultimate recipient(s), 
SPF, DKIM, and DMARC only protect one portion.  And I happen to think 
that they do it well.


It basically required that any service that wanted to use DMARC needed to 
separate valuable protected mail from less valuable mail with different 
domains. AOL and YAHOO just decided to ignore that in their use

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Richard Damon]

> On Jul 22, 2018, at 5:11 PM, Grant Taylor via Mailman-Users 
>  wrote:
> 
>> On 07/22/2018 02:03 PM, John Levine wrote:
>> No, it was specified in full knowledge that it would break pretty much every 
>> mailing list on the planet if used on domains with human users, instead of 
>> its intended target of notices from robot domains like paypal.com.
> 
> I choose to believe the mailing lists were behaving improperly.
> 
> To me, DMARC (including SPF and DKIM) is a method to determine if a message 
> is coming from the original source (or authorized delegate). Where email is a 
> combination of the message data and SMTP transaction delivering said message.

What actions do you think mailing lists are doing improperly?

Note, the subject modification is a long standing feature of mailing list, 
which is one thing that breaks DMARC, though I might be willing to give that up.

The modification of the message body to add a header or footer is also common, 
and in some places effectively required by law.

>> That's why we have ARC, once AOL and Yahoo abused it to solve the problem 
>> they created when they let crooks steal their users' address books.
> 
> I assume you are referring to "DMARC" when you say "…abused /it/ to solve…".
> 
> I feel like AOL's and Yahoo's actions are just additional gas on the fire 
> that has been burning for a long time.  The problem of bad actors spoofing 
> message senders exists independently of AOL and Yahoo.  Did their (in)actions 
> make the problem worse, probably.  Did they cause the problem?  No.  Did they 
> exceed critical mass?  I don't think so.  Rather I think it was past the 
> critical mass long before AOL and Yahoo fueled the fire.
> 
> -- 
> Grant. . . .

If AOL and Yahoo just used the quarantine option for DMARC, it wouldn’t have 
been quite as bad. But they ABUSED DMARC by their settings. By the design of 
DMARC, AOL and Yahoo should have informed their users that they were changing 
the Terms of Service of their email systems, and now all their users are 
effectively prohibited to use any form of re-mailing systems, including most 
forms of (external) mailing lists. Instead they just told the world, we aren’t 
going to follow the normal rules, you deal with it.

Yes, there is a fundamental issue with email that it is easy to spoof. Fixing 
it is going to be a significant issue, and possible a complete recreation of 
the system. The issue is that to create such a new system is a major job. Such 
a redesign would need to look at ALL current uses and either decide that such 
uses were no longer valid or to accommodate them. DMARC somewhat intentionally 
did not consider mailing list, because they didn’t have a good solution to 
handle them, and their intended usage, the protection of ‘valuable’ mail 
somewhat excluded the use of such services. It basically required that any 
service that wanted to use DMARC needed to separate valuable protected mail 
from less valuable mail with different domains. AOL and YAHOO just decided to 
ignore that in their use of it.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07/22/2018 02:03 PM, John Levine wrote:
>> No, it was specified in full knowledge that it would break pretty much 
>> every mailing list on the planet if used on domains with human users, 
>> instead of its intended target of notices from robot domains like 
>> paypal.com.
>
>I choose to believe the mailing lists were behaving improperly.

Oh, OK, sorry to disturb you.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/22/2018 02:03 PM, John Levine wrote:
No, it was specified in full knowledge that it would break pretty much 
every mailing list on the planet if used on domains with human users, 
instead of its intended target of notices from robot domains like 
paypal.com.


I choose to believe the mailing lists were behaving improperly.

To me, DMARC (including SPF and DKIM) is a method to determine if a 
message is coming from the original source (or authorized delegate). 
Where email is a combination of the message data and SMTP transaction 
delivering said message.


That's why we have ARC, once AOL and Yahoo abused it to solve the problem 
they created when they let crooks steal their users' address books.


I assume you are referring to "DMARC" when you say "…abused /it/ to solve…".

I feel like AOL's and Yahoo's actions are just additional gas on the 
fire that has been burning for a long time.  The problem of bad actors 
spoofing message senders exists independently of AOL and Yahoo.  Did 
their (in)actions make the problem worse, probably.  Did they cause the 
problem?  No.  Did they exceed critical mass?  I don't think so.  Rather 
I think it was past the critical mass long before AOL and Yahoo fueled 
the fire.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <0590fe51-3f96-754d-d155-af0eb9ca4...@spamtrap.tnetconsulting.net> 
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07/19/2018 04:59 PM, Phil Stracchino wrote:
>> Actually, mailing lists and other redistribution are among the places 
>> DMARC notably breaks.
>
>Does DMARC actually break or otherwise behave in a manner contrary to 
>it's specification?

No, it was specified in full knowledge that it would break pretty much
every mailing list on the planet if used on domains with human users,
instead of its intended target of notices from robot domains like
paypal.com.

That's why we have ARC, once AOL and Yahoo abused it to solve the
problem they created when they let crooks steal their users' address
books.

R's,
John

PS: This isn't conspiracy theorizing, I know the people involved.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 04:59 PM, Phil Stracchino wrote:
Actually, mailing lists and other redistribution are among the places 
DMARC notably breaks.


Does DMARC actually break or otherwise behave in a manner contrary to 
it's specification?


I personally believe that DMARC (and SPF and DKIM) are doing exactly 
what they are supposed to do.


The problem is that they are doing what they are supposed to do when 
people want them to not do that.


I don't even consider this to be a false positive.  -  If someone trains 
a dog to bark constantly (alert) when they see someone approach with a 
gun, I believe that the dog is doing exactly what they are trained to do 
when an armed police officer walks up.  The dog is doing exactly what 
they were trained to do.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article  you write:
>On 07/19/18 17:11, John Levine wrote:
>> In article 
>>  you write:
>>> Yes.  Just about everything can be spoofed to some degree.  It really 
>>> depends on what information the owner of the purported sending domain 
>>> publishes and what filtering / consumption of said information the 
>>> receiving server exercises.
>> 
>> Well, you know, this is what DMARC is intended to address.  While
>> DMARC checks on mail that has passed through mailing lists has all
>> sorts of well known problems, doing DMARC checks on mail that arrives
>> at a list server would be pretty benign.  It's pretty rare for the
>> path from a user to the mailman server to do things that would cause
>> DMARC fails.
>
>Actually, mailing lists and other redistribution are among the places
>DMARC notably breaks.  The real answer, which was created for this
>purpose, is ARC (Authenticated Received Chain).  That is designed from
>the start to pass through mailing lists unbroken.
>
>(Or so I'm told.)

You missed a key point.  I was suggesting DMARC-ish checks on mail *to* a
maiing list, where they should work fine.  Mail *from* a mailing list is
indeed screwed up by DMARC which is why I've been working on ARC libraries.

R's,
John

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/20/2018 08:12 AM, Grant Taylor via Mailman-Users wrote:
> 
> Have you tried using the alternate milters?  Postfix implemented
> Sendmail's milter protocol.  So I think they are directly compatible
> with each other.


Neither  nor
 are
milters in the sense of Sendmail's milter protocol.

tummailmanmember is a Postfix policy server and check_subscriber is a
script that is invoked via a Postfix table lookup.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/20/2018 12:40 AM, Jayson Smith wrote:
Could either of these milter solutions linked previously be adapted for 
use as a Sendmail milter? I'd love to find something which would query 
Mailman about the status of a particular sender address at the RCPT 
stage of the SMTP transaction so spoofed mail can be rejected right 
away, however, this might not be possible for one reason or another. Any 
thoughts would be appreciated.


Have you tried using the alternate milters?  Postfix implemented 
Sendmail's milter protocol.  So I think they are directly compatible 
with each other.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Stephen J. Turnbull]

Mark Sapiro writes:

 > The problem is downstream has to trust me. If I'm gmail.com, I'll
 > probably be trusted. If I'm msapiro.net, probably not. Python.org, who
 > knows.

The problem is the same butt-lazy admins that caused you to implement
DKIM-stripping.[1]  Google and (AFAIK) Yahoo! and Microsoft will trust
you by default.

In fact, I snafued a couple weeks back, exposed my Mailman server to
the joe-jobbing via web subscription backscatter, and was immediately
interdicted by Microsoft.  Fixed the problem, went to Microsoft, and
immediately mail started flowing again and has ever since.

So I think ARC is in practice going to be trusted by default, at least
until the first big spammer exploit taking advantage of that trust.

Footnotes: 
[1]  In many cases, Authentication-Results should be stripped by the
domain-edge MTA, and RFC 7601 discusses when that really must be done,
and the pros and cons of doing it in general.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jayson Smith]

Hi,

Both of these approaches seem to be specific to Postfix if I'm not 
mistaken. There's a similar milter for Sendmail called Mailman-Milter 
which I was using for a while. However, it worked based on Mailman's 
action E.G. it would use a Python script to determine what Mailman would 
do with a particular sender's mail for a particular list. If the answer 
was reject or discard, the incoming message got rejected at the SMTP 
data stage. This meant the list owner had to set up Mailman to reject or 
discard mail from non-subscribers. Unfortunately when I upgraded to 
Debian 9 from CentOS 6, Mailman-Milter broke somehow, and I don't 
understand the code well enough to figure out why. It also hasn't been 
updated in quite some time, and has virtually no documentation.


Could either of these milter solutions linked previously be adapted for 
use as a Sendmail milter? I'd love to find something which would query 
Mailman about the status of a particular sender address at the RCPT 
stage of the SMTP transaction so spoofed mail can be rejected right 
away, however, this might not be possible for one reason or another. Any 
thoughts would be appreciated.


Thanks,

Jayson

On 7/19/2018 2:55 PM, Jim Popovitch via Mailman-Users wrote:

On July 19, 2018 6:53:52 PM UTC, Jim Popovitch  wrote:

On July 19, 2018 5:28:24 PM UTC, Mark Sapiro  wrote:

On 07/19/2018 08:02 AM, Grant Taylor via Mailman-Users wrote:

I have often wondered about enhancing Mailman, or augmenting it with

a

milter, to be able to test the SMTP envelope from, to, and body

content

against list parameters and be able to reject messages during the

SMTP

delivery transaction.


You might be interested in
.

Here's an alternate take on the same thing that I wrote a couple years
back.

With link this time!

https://code.launchpad.net/~jimpop/mailman/check_subscriber

-Jim P.


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/jaybird%40bluegrasspals.com




--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 05:27 PM, Mark Sapiro wrote:
The problem is downstream has to trust me. If I'm gmail.com, I'll probably 
be trusted. If I'm msapiro.net, probably not. Python.org, who knows.


Yep.

I've not yet seen any indication that there will be any good way to 
establish this trust relationship, save for traditional 
Business-to-Business methods.  At least I'm not aware of anything more 
automatic.


Thus I question how useful ARC will be for small operators.  :-/



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 06:22 PM, Mark Sapiro wrote:
If Mailman is asked to remove or replace DKIM headers, the 
headers affected are DomainKey-Signature, DKIM-Signature and 
Authentication-Results.


Good to know.

Thank you for clarifying Mark.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 03:55 PM, Matt Morgan wrote:
> BTW I'm kind of flummoxed that in Mark's mail he sees the
> j...@johngreenwaltlee.com address, because that's exactly what I deleted and
> replaced with the obfuscated "xxxjohnxxx.com." In what I wrote, that real
> email address *did not appear*. !@#$% gmail.


It appeared to me that those addresses in both the From: and Reply-To:
headers were artifacts of some MUA. I didn't want to say anything about
that because I didn't want to draw attention to something you were
probably trying to not expose.

I suspect the following scenario is responsible:

You compose an email using an HTML (rich-text) editor. The editor
represents 'u...@example.com' as 'mailto:u...@example.com";>u...@example.com' in the raw html it
is composing. I.e., it is a hyperlink.

You obfuscate the address to 'ot...@other.example.com'. This changes the
html to 'mailto:u...@example.com";>ot...@other.example.com'
so you see 'ot...@other.example.com' in your composition window, but it
is still a mailto link to 'u...@example.com'

You send the message and your MUA creates a plain text alternative in
which the html hyperlink is rendered as 'ot...@other.example.com
'.

The list's content filtering selects the plain text alternative for
delivery to the list.

I tell my users to ALWAYS compose list mail using a plain text editor.
That way you see what will actually go to the list. In this case, Gmail
thwarted your intent. I have users on my lists that use Yahoo and drag
and drop links into their posts and the links don't appear in the plain
text at all.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 03:31 PM, Grant Taylor via Mailman-Users wrote:
> 
> I'm lumping various in as well, which I'm not aware of Mailman being
> able to remove.
> 
> Authentication-Results:
> 
> I think there are others that fall into the same category, but I don't
> recall them at the moment.


If Mailman is asked to remove or replace DKIM headers, the headers
affected are DomainKey-Signature, DKIM-Signature and Authentication-Results.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Phil Stracchino]

On 07/19/18 19:27, Mark Sapiro wrote:
> On 07/19/2018 03:59 PM, Phil Stracchino wrote:
>>
>> Actually, mailing lists and other redistribution are among the places
>> DMARC notably breaks.  The real answer, which was created for this
>> purpose, is ARC (Authenticated Received Chain).  That is designed from
>> the start to pass through mailing lists unbroken.
> 
> 
> Yes, ARC is designed for this and we are working on implementing ARC for
> Mailman 3 but not 2.1.

I am, by the way, eagerly waiting for Gentoo to unmask Mailman 3 ...   :)



-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 03:59 PM, Phil Stracchino wrote:
> 
> Actually, mailing lists and other redistribution are among the places
> DMARC notably breaks.  The real answer, which was created for this
> purpose, is ARC (Authenticated Received Chain).  That is designed from
> the start to pass through mailing lists unbroken.


Yes, ARC is designed for this and we are working on implementing ARC for
Mailman 3 but not 2.1.

ARC is a way that that I as an intermediary can say that I certify that
the message I received passed DMARC, but I transformed it in a way that
will cause DMARC to fail, but if my signature validates, downstream
should accept that DMARC passed.

The problem is downstream has to trust me. If I'm gmail.com, I'll
probably be trusted. If I'm msapiro.net, probably not. Python.org, who
knows.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Phil Stracchino]

On 07/19/18 17:11, John Levine wrote:
> In article  
> you write:
>> Yes.  Just about everything can be spoofed to some degree.  It really 
>> depends on what information the owner of the purported sending domain 
>> publishes and what filtering / consumption of said information the 
>> receiving server exercises.
> 
> Well, you know, this is what DMARC is intended to address.  While
> DMARC checks on mail that has passed through mailing lists has all
> sorts of well known problems, doing DMARC checks on mail that arrives
> at a list server would be pretty benign.  It's pretty rare for the
> path from a user to the mailman server to do things that would cause
> DMARC fails.


Actually, mailing lists and other redistribution are among the places
DMARC notably breaks.  The real answer, which was created for this
purpose, is ARC (Authenticated Received Chain).  That is designed from
the start to pass through mailing lists unbroken.


(Or so I'm told.)


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Matt Morgan]

BTW I'm kind of flummoxed that in Mark's mail he sees the
j...@johngreenwaltlee.com address, because that's exactly what I deleted and
replaced with the obfuscated "xxxjohnxxx.com." In what I wrote, that real
email address *did not appear*. !@#$% gmail.

On Thu, Jul 19, 2018 at 6:51 PM, Matt Morgan 
wrote:

> Thanks, everyone, for the thoughtful comments on my tiny little spam
> problem! I've returned from my day job and will look at Mark's diagnosis
> suggestions.
>
> Best,
> Matt
>
> On Thu, Jul 19, 2018 at 6:43 PM, John Levine  wrote:
>
>> In article <1ca714d0-da89-aa23-d247-4faa2133b...@msapiro.net> you write:
>> >DMARC checks won't help prevent posts that spoof a member address unless
>> >every list member's domain publishes a DMARC policy of quarantine or
>> >reject, and even then it only checks the From: domain and not the domain
>> >of other addresses Mailman might use to determine list membership.
>> >
>> >Further, a post with spoofed local part sent by someone in the same
>> >domain might pass DMARC if sent via the domain's servers.
>>
>> That's all true, and if you want bullet proof spoof resistance, you'd
>> have to register PGP or S/MIME keys for the subscriber and require
>> that she sign all her mail.
>>
>> On the other hand, a lot of domains do DKIM signing or publish SPF,
>> and the vast majority of fake From: headers I see are from botnets,
>> not malicious users down the hall from the victim.  So if someone is
>> experiencing a lot of botnet spoofage, a setting to say that a user's
>> mail will be authenticated by SPF or DKIM from domain X would get you
>> about 90% of the effect of S/MIME signing everything with 10% of the
>> grief.
>>
>> R's,
>> John
>> --
>> Mailman-Users mailing list Mailman-Users@python.org
>> https://mail.python.org/mailman/listinfo/mailman-users
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Security Policy: http://wiki.list.org/x/QIA9
>> Searchable Archives: http://www.mail-archive.com/ma
>> ilman-users%40python.org/
>> Unsubscribe: https://mail.python.org/mailman/options/mailman-users/minxme
>> rtzmomo%40gmail.com
>>
>
>
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Matt Morgan]

Thanks, everyone, for the thoughtful comments on my tiny little spam
problem! I've returned from my day job and will look at Mark's diagnosis
suggestions.

Best,
Matt

On Thu, Jul 19, 2018 at 6:43 PM, John Levine  wrote:

> In article <1ca714d0-da89-aa23-d247-4faa2133b...@msapiro.net> you write:
> >DMARC checks won't help prevent posts that spoof a member address unless
> >every list member's domain publishes a DMARC policy of quarantine or
> >reject, and even then it only checks the From: domain and not the domain
> >of other addresses Mailman might use to determine list membership.
> >
> >Further, a post with spoofed local part sent by someone in the same
> >domain might pass DMARC if sent via the domain's servers.
>
> That's all true, and if you want bullet proof spoof resistance, you'd
> have to register PGP or S/MIME keys for the subscriber and require
> that she sign all her mail.
>
> On the other hand, a lot of domains do DKIM signing or publish SPF,
> and the vast majority of fake From: headers I see are from botnets,
> not malicious users down the hall from the victim.  So if someone is
> experiencing a lot of botnet spoofage, a setting to say that a user's
> mail will be authenticated by SPF or DKIM from domain X would get you
> about 90% of the effect of S/MIME signing everything with 10% of the
> grief.
>
> R's,
> John
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/
> mailman-users%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-users/
> minxmertzmomo%40gmail.com
>
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article <1ca714d0-da89-aa23-d247-4faa2133b...@msapiro.net> you write:
>DMARC checks won't help prevent posts that spoof a member address unless
>every list member's domain publishes a DMARC policy of quarantine or
>reject, and even then it only checks the From: domain and not the domain
>of other addresses Mailman might use to determine list membership.
>
>Further, a post with spoofed local part sent by someone in the same
>domain might pass DMARC if sent via the domain's servers.

That's all true, and if you want bullet proof spoof resistance, you'd
have to register PGP or S/MIME keys for the subscriber and require
that she sign all her mail.

On the other hand, a lot of domains do DKIM signing or publish SPF,
and the vast majority of fake From: headers I see are from botnets,
not malicious users down the hall from the victim.  So if someone is
experiencing a lot of botnet spoofage, a setting to say that a user's
mail will be authenticated by SPF or DKIM from domain X would get you
about 90% of the effect of S/MIME signing everything with 10% of the
grief.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 04:16 PM, Mark Sapiro wrote:
Mailman can be configured to remove DKIM related headers from 
incoming mail before sending.


ACK

I'm lumping various in as well, which I'm not aware of Mailman being 
able to remove.


Authentication-Results:

I think there are others that fall into the same category, but I don't 
recall them at the moment.


When first implemented, this was done unconditionally. There 
were strenuous objections, see the thread at 
, 
and removal was made conditional on REMOVE_DKIM_HEADERS which defaults 
to No.


ACK

The bottom line is that the DKIM standard (RFC 6376) says that invalid 
signatures SHOULD NOT be treated differently fro no signature, and people 
feel the invalid signature may have forensic value.


I agree that headers should not be modified between the sender and the 
recipient.  The catch is, I believe the mailing list is the recipient 
and a subsequent (re)sender of a very similar but different message.  As 
such, I think that DKIM (and related) headers in a message going to a 
mailing list are unrelated to DKIM (and related) headers in a message 
coming from a mailing list.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 02:37 PM, Grant Taylor via Mailman-Users wrote:
> 
> I'd argue that it's best to:
> 
> 1)  Do all the typical DMARC, DKIM, SPF, etc. filtering on email inbound
> to the mail server.
> 2)  Strip DKIM (related) headers from messages going into Mailman.


Mailman can be configured to remove DKIM related headers from incoming
mail before sending. When first implemented, this was done
unconditionally. There were strenuous objections, see the thread at
,
and removal was made conditional on REMOVE_DKIM_HEADERS which defaults
to No.

The bottom line is that the DKIM standard (RFC 6376) says that invalid
signatures SHOULD NOT be treated differently fro no signature, and
people feel the invalid signature may have forensic value.


> 3)  ...Mailman w/ DMARC friendly settings...
> 4)  Apply new DKIM signatures as messages leave the mail server.


-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Robert Heller]

At Thu, 19 Jul 2018 14:17:55 -0600 Grant Taylor  
wrote:

> 
> 
> Content-Language: en-US
> 
> On 07/19/2018 11:44 AM, Robert Heller wrote:
> > All of which can be spoofed.
> 
> Yes.  Just about everything can be spoofed to some degree.  It really 
> depends on what information the owner of the purported sending domain 
> publishes and what filtering / consumption of said information the 
> receiving server exercises.
> 
> I personally feel like Mailman, and many other similar things, should 
> sit behind an external / edge SMTP server that does some of the heavy 
> lifting and provides detection of and possibly protection against many 
> spoofs.

Yes, of course.  

> 
> > Mailman does not make any checks of the "Received:" headers (where the 
> > bogosity of the other headers can be determined or can flag messages as 
> > containing possibly spoofed headers).
> 
> I agree that there is some data in the Received: headers that may 
> indicate a problem.  But such information is difficult to consistently / 
> reliably / accurately extract or parse /without/ false positives.  It 
> can also be difficult to correlate information across headers and 
> determine what should and should not be allowed.  Let's not forget that 
> it's equally easy to spoof Received: headers as it is to spoof other 
> headers.  }:-)

I have found that just "holding" messages from an non-reversed DNS "server" 
(eg "Received: ... from ... unknown (nnn.nnn.nnn.nnn)"), results in only a 
small number of false positives.   Better a *few* false positives, than tons 
of spam.  Firewalling IP blocks, either with an actual firewall (iptables) or 
via access control, helps a great deal.

> 
> 
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
  
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 02:11 PM, John Levine wrote:
> In article  
> you write:
>> Yes.  Just about everything can be spoofed to some degree.  It really 
>> depends on what information the owner of the purported sending domain 
>> publishes and what filtering / consumption of said information the 
>> receiving server exercises.
> 
> Well, you know, this is what DMARC is intended to address.


Actually, DMARC is intended to address spoofing of domains and needs to
be configured by the domain owner publishing a DMARC policy.

DMARC checks won't help prevent posts that spoof a member address unless
every list member's domain publishes a DMARC policy of quarantine or
reject, and even then it only checks the From: domain and not the domain
of other addresses Mailman might use to determine list membership.

Further, a post with spoofed local part sent by someone in the same
domain might pass DMARC if sent via the domain's servers.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 03:11 PM, John Levine wrote:
Well, you know, this is what DMARC is intended to address.  While DMARC 
checks on mail that has passed through mailing lists has all sorts of 
well known problems, doing DMARC checks on mail that arrives at a list 
server would be pretty benign.  It's pretty rare for the path from a 
user to the mailman server to do things that would cause DMARC fails.


Yep, that's what I was referring to.

If you want to reinvent DMARC, you could add an option to say that all 
submissions from me must have a DKIM signature or validated SPF from 
domain X, where X would usually default to the domain in your e-mail 
address.


I have no desire to reinvent DMARC (or DKIM, SPF, etc.).

I'd argue that it's best to:

1)  Do all the typical DMARC, DKIM, SPF, etc. filtering on email inbound 
to the mail server.

2)  Strip DKIM (related) headers from messages going into Mailman.
3)  ...Mailman w/ DMARC friendly settings...
4)  Apply new DKIM signatures as messages leave the mail server.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[John Levine]

In article  
you write:
>Yes.  Just about everything can be spoofed to some degree.  It really 
>depends on what information the owner of the purported sending domain 
>publishes and what filtering / consumption of said information the 
>receiving server exercises.

Well, you know, this is what DMARC is intended to address.  While
DMARC checks on mail that has passed through mailing lists has all
sorts of well known problems, doing DMARC checks on mail that arrives
at a list server would be pretty benign.  It's pretty rare for the
path from a user to the mailman server to do things that would cause
DMARC fails.

If you want to reinvent DMARC, you could add an option to say that all
submissions from me must have a DKIM signature or validated SPF from
domain X, where X would usually default to the domain in your e-mail
address.

R's,
John
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 11:44 AM, Robert Heller wrote:

All of which can be spoofed.


Yes.  Just about everything can be spoofed to some degree.  It really 
depends on what information the owner of the purported sending domain 
publishes and what filtering / consumption of said information the 
receiving server exercises.


I personally feel like Mailman, and many other similar things, should 
sit behind an external / edge SMTP server that does some of the heavy 
lifting and provides detection of and possibly protection against many 
spoofs.


Mailman does not make any checks of the "Received:" headers (where the 
bogosity of the other headers can be determined or can flag messages as 
containing possibly spoofed headers).


I agree that there is some data in the Received: headers that may 
indicate a problem.  But such information is difficult to consistently / 
reliably / accurately extract or parse /without/ false positives.  It 
can also be difficult to correlate information across headers and 
determine what should and should not be allowed.  Let's not forget that 
it's equally easy to spoof Received: headers as it is to spoof other 
headers.  }:-)




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jim Popovitch via Mailman-Users]

On July 19, 2018 6:53:52 PM UTC, Jim Popovitch  wrote:
>On July 19, 2018 5:28:24 PM UTC, Mark Sapiro  wrote:
>>On 07/19/2018 08:02 AM, Grant Taylor via Mailman-Users wrote:
>>> 
>>> I have often wondered about enhancing Mailman, or augmenting it with
>>a
>>> milter, to be able to test the SMTP envelope from, to, and body
>>content
>>> against list parameters and be able to reject messages during the
>>SMTP
>>> delivery transaction.
>>
>>
>>You might be interested in
>>.
>
>Here's an alternate take on the same thing that I wrote a couple years
>back.

With link this time!

https://code.launchpad.net/~jimpop/mailman/check_subscriber

-Jim P.


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Jim Popovitch via Mailman-Users]

On July 19, 2018 5:28:24 PM UTC, Mark Sapiro  wrote:
>On 07/19/2018 08:02 AM, Grant Taylor via Mailman-Users wrote:
>> 
>> I have often wondered about enhancing Mailman, or augmenting it with
>a
>> milter, to be able to test the SMTP envelope from, to, and body
>content
>> against list parameters and be able to reject messages during the
>SMTP
>> delivery transaction.
>
>
>You might be interested in
>.

Here's an alternate take on the same thing that I wrote a couple years back.




--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Robert Heller]

At Thu, 19 Jul 2018 10:25:01 -0700 Mark Sapiro  wrote:

> 
> On 07/19/2018 05:16 AM, Robert Heller wrote:
> > At Wed, 18 Jul 2018 19:33:20 -0700 Mark Sapiro  wrote:
> > 
> >>
> >> On 07/18/2018 07:10 PM, Robert Heller wrote:
> >>>
> >>> Mailman only checks the From: header...
> >>
> >>
> >> Not true. See my other reply in this thread.
> > 
> > I mean it does not check things like the Received: headers *by default*. If
> > the email part of the From: header is a list member address, Mailman will
> > consider that the mail is from that member and pass the message on to the
> > list, *even if the From: header is spoofed*. I expect that this is what
> > happening with the OP. It is a common spammer hack: somehow get a list of
> > member addresses (or really hack a member's E-Mail accoung or PC and go from
> > there).
> > 
> > Yes, Mail mail can be configured to check other headers, but this requires 
> > some configuration settings.
> 
> 
> My point is that standard, default Mailman checks not only the From:
> header for list member addresses, it also checks the envelope sender and
> the Reply-To: and Sender: headers.

All of which can be spoofed.  Mailman does not make any checks of the 
"Received:" headers (where the bogosity of the other headers can be determined 
or can flag messages as containing possibly spoofed headers).

> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
  
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 08:02 AM, Grant Taylor via Mailman-Users wrote:
> 
> I have often wondered about enhancing Mailman, or augmenting it with a
> milter, to be able to test the SMTP envelope from, to, and body content
> against list parameters and be able to reject messages during the SMTP
> delivery transaction.


You might be interested in
.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/19/2018 05:16 AM, Robert Heller wrote:
> At Wed, 18 Jul 2018 19:33:20 -0700 Mark Sapiro  wrote:
> 
>>
>> On 07/18/2018 07:10 PM, Robert Heller wrote:
>>>
>>> Mailman only checks the From: header...
>>
>>
>> Not true. See my other reply in this thread.
> 
> I mean it does not check things like the Received: headers *by default*. If
> the email part of the From: header is a list member address, Mailman will
> consider that the mail is from that member and pass the message on to the
> list, *even if the From: header is spoofed*. I expect that this is what
> happening with the OP. It is a common spammer hack: somehow get a list of
> member addresses (or really hack a member's E-Mail accoung or PC and go from
> there).
> 
> Yes, Mail mail can be configured to check other headers, but this requires 
> some configuration settings.


My point is that standard, default Mailman checks not only the From:
header for list member addresses, it also checks the envelope sender and
the Reply-To: and Sender: headers.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Grant Taylor via Mailman-Users]

On 07/19/2018 06:16 AM, Robert Heller wrote:
I mean it does not check things like the Received: headers*by default*. If 
the email part of the From: header is a list member address, Mailman 
will consider that the mail is from that member and pass the message on 
to the list,*even if the From: header is spoofed*. I expect that this 
is what happening with the OP. It is a common spammer hack: somehow get 
a list of member addresses (or really hack a member's E-Mail accoung or 
PC and go from there).


Yes, Mail mail can be configured to check other headers, but this requires 
some configuration settings.


I have often wondered about enhancing Mailman, or augmenting it with a 
milter, to be able to test the SMTP envelope from, to, and body content 
against list parameters and be able to reject messages during the SMTP 
delivery transaction.


IMHO it's a bit more difficult to spoof SMTP envelope details and bypass 
SMTP level detections.  This does assume that the sending domain does 
publish the required info and that receiving mail servers actually 
filter based on that.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Robert Heller]

At Wed, 18 Jul 2018 19:33:20 -0700 Mark Sapiro  wrote:

> 
> On 07/18/2018 07:10 PM, Robert Heller wrote:
> > 
> > Mailman only checks the From: header...
> 
> 
> Not true. See my other reply in this thread.

I mean it does not check things like the Received: headers *by default*. If
the email part of the From: header is a list member address, Mailman will
consider that the mail is from that member and pass the message on to the
list, *even if the From: header is spoofed*. I expect that this is what
happening with the OP. It is a common spammer hack: somehow get a list of
member addresses (or really hack a member's E-Mail accoung or PC and go from
there).

Yes, Mail mail can be configured to check other headers, but this requires 
some configuration settings.

> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/18/2018 07:10 PM, Robert Heller wrote:
> 
> Mailman only checks the From: header...


Not true. See my other reply in this thread.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Mark Sapiro]

On 07/18/2018 06:28 PM, Matt Morgan wrote:
> On one of my lists I'm seeing some spam from non-subscribers getting
> through. It appears that the trick is to put a subscriber's address in the
> "real name" of the sender. E.g., this got through, without being held for
> moderation, on a list with generic_nonmember_action = discard (emails of
> the innocent obfuscated):
> 
> *From:* "x...@johnxxx.com " 


I'm not sure what the actual incoming From: looked like. I'm sure the
asterisks in *From:* are some MUA's bolding artifact, but that
notwithstanding, if the header was

From: "x...@johnxxx.com " 

Mailman will parse that as

real name: 'x...@johnxxx.com '
address: 'enrollm...@ekonek.com'

and the only address checked for list membership will be
enrollm...@ekonek.com

In any case, if you haven't changed the setting of SENDER_HEADERS in
mm_cfg.py, Mailman will consider a post to be from a list member if any
of the From: header, the envelope sender, the Reply-To: header or the
Sender: header contains the member address as an address, not as a real
name.

It is trivial to spoof a member address in one of those places.

As far as what happened in this case, I can't say without seeing the
original message as received by Mailman before various headers were
munged and the post sent to the list.

If you want to diagnose this, you can temporarily add a local file to
the alias for the list posting address to capture the incoming mail, at
least if mailman's delivery is via aliases.

I.e., if you currently have an alias like

listname:   "|/path/to/mail/mailman post virt"

add a file as in

listname:   "|/path/to/mail/mailman post listname"
  /path/to/file

Then the MTA will save the message to 'file' as well as delivering it to
mailman.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Robert Heller]

At Wed, 18 Jul 2018 21:28:47 -0400 Matt Morgan  wrote:

> 
> On one of my lists I'm seeing some spam from non-subscribers getting
> through. It appears that the trick is to put a subscriber's address in the
> "real name" of the sender. E.g., this got through, without being held for
> moderation, on a list with generic_nonmember_action = discard (emails of
> the innocent obfuscated):
> 
> *From:* "x...@johnxxx.com " 
> *Date:* July 18, 2018 at 5:27:24 PM CDT
> *To:* >
> *Subject:* *[OSG-l] No. PL-01-17923 AIC Objects Specialty Group Discussion*
> *Reply-To:* My List's Name  >
> 
> 
> Account Summary:
> ---
> Invoice No: No. PL-01-17923
> Billing Date: Jul 19, 2018
> Due Date: Jul 22, 2018
> Amount Due: 1,047.48
> Download DOC:


Mailman only checks the From: header and it is trivial to put any random thing 
there, even if it is false information.

OTH, the contents of the Recieved: headers contain real server names and IP 
addresses.

Very often, the mail is sent directly to a SMTP server from a random PC or 
Laptop, often from a IP address without a reverse DNS.  I have a filter rule:

Received: from.*(unknown \[\d+\.\d+\.\d+\.\d+\])

Which catches this sorts of messages.  I place them on hold, since *some* 
people use E-Mail clients that directly connect to SMTP servers from ISP IP 
addresses without reverse DNS.

> 
> etc. (I'm avoiding sharing the links that follow). x...@johnxxx.com IS a
> subscriber on the list. However enrollm...@ekonek.com is not. Yet this
> message went straight through, as if it had been sent by a subscriber.
> 
> I've looked at the archives of mailman-users and it looks like--from a very
> old discussion--that
> 
> a) this cheap trick should not be sufficient to allow the message through
> b) the content of the message as delivered to the list may not reflect the
> exact contents/metadata of the message as it was sent.
> 
> Still, I don't really know what else could be going on here, or how to
> investigate. Suggestions?
> 
> Thanks!
> Matt
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: 
> https://mail.python.org/mailman/options/mailman-users/heller%40deepsoft.com
> 
>   
>  

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
 
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] non-subscribers getting through--email address in "Real Name"

[Matt Morgan]

On one of my lists I'm seeing some spam from non-subscribers getting
through. It appears that the trick is to put a subscriber's address in the
"real name" of the sender. E.g., this got through, without being held for
moderation, on a list with generic_nonmember_action = discard (emails of
the innocent obfuscated):

*From:* "x...@johnxxx.com " 
*Date:* July 18, 2018 at 5:27:24 PM CDT
*To:* >
*Subject:* *[OSG-l] No. PL-01-17923 AIC Objects Specialty Group Discussion*
*Reply-To:* My List's Name >


Account Summary:
---
Invoice No: No. PL-01-17923
Billing Date: Jul 19, 2018
Due Date: Jul 22, 2018
Amount Due: 1,047.48
Download DOC:

etc. (I'm avoiding sharing the links that follow). x...@johnxxx.com IS a
subscriber on the list. However enrollm...@ekonek.com is not. Yet this
message went straight through, as if it had been sent by a subscriber.

I've looked at the archives of mailman-users and it looks like--from a very
old discussion--that

a) this cheap trick should not be sufficient to allow the message through
b) the content of the message as delivered to the list may not reflect the
exact contents/metadata of the message as it was sent.

Still, I don't really know what else could be going on here, or how to
investigate. Suggestions?

Thanks!
Matt
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org