Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/18/2017 03:41 PM, Jordan Brown wrote:
> On 10/18/2017 11:35 AM, Mark Sapiro wrote:
>> DMARC is not the problem. It is perfectly reasonable for say, irs.gov
>> to publish DMARC p=reject as long as mail From: irs.gov is not an
>> employees personal post to an email list. Presumably the IRS would
>> have rules against that.
> 
> Would they?  Shouldn't IRS sysadmins who use Mailman in the course of
> their jobs send messages to this mailing list using their @irs.gov
> addresses?
> 
> Not all submissions to public mailing lists are personal use.


Agreed, but for DMARC to work seamlessly with pre-existing accepted
norms, DMARC policies of reject or quarantine should only be published
for domains that send "official" mail directly to end recipients.

If irs.gov published such a policy (currently it publishes p=none) and
IRS employees needed to post From: some irs.gov address, they could
easily post From: @subdomain.irs.gov and publish p=none for that subdomain.

However, all this is really moot because whatever any of us thinks,
DMARC is already being used in ways that disrupt pre-existing accepted
norms so for mailing lists to remain viable, they have to mitigate the
effects in some way.

-- 
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 03:42 PM, Dimitri Maziuk wrote:
Because the very first $relayhost may apply transport encoding. You have 
to compute the hash before that happens.


It's my understanding that DKIM is usually applied by the egress MSA / MTA.

I guess an MSA could apply DKIM itself.  It would need to publish it's 
public key / selector in DNS.  So that's probably a reason not to have 
every MUA apply DKIM itself.  It is probably much more economical to 
apply DKIM at the MSA / 1st MTA.


Ideally intermediary MTAs / receiving MTA would not need to apply 
content transfer encoding.


It's my understanding that MTAs prefer to avoid changing the message 
unless there is a requirement to do so.  I.e. downstream MTA won't 
accept the message as it currently is.


My "why can't you..." question was more why can't an MX do an operation 
that an MUA can do.  -  I was thinking you were saying that a receiving 
MTA couldn't validate before accepting a message.



That does not contradict what I said. Low specificity means low
probability of detection of "bad stuff". I.e. it doesn't mean much that
most of it passes.



Ohkay, so what exactly am I the end user is supposed to need it for?


I don't know that DKIM is really targeting end users.  I think DKIM is 
more targeting postmasters to configure on their MTAs.


I'm using a Thunderbird add-on that allows me to see / validate DKIM in 
my receiving MUA.  (My MSA applies DKIM for me.)


I, as a postmaster, want DKIM for a couple of reasons, 1) I want to be 
able to filter incoming messages based on DKIM (for better or worse) and 
2) outgoing DKIM signing for use in conjunction with DMARC.


You (/me waves hands around the room) may not care enough to bother with 
DKIM.  That's your prerogative.  Just like we are all free to run our 
mail servers that way that we want to.




--
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] cause of bounces

[Dimitri Maziuk]

On 10/18/2017 04:26 PM, Grant Taylor via Mailman-Users wrote:
> On 10/18/2017 02:10 PM, Dimitri Maziuk wrote:
> 
> Do I understand you correctly to mean to create the signature before
> applying transport encoding?
> 
>> Only, you can't do that on the MX, it has to be done on the client.
> 
> Why can't you do it at the MX?

Because the very first $relayhost may apply transport encoding. You have
to compute the hash before that happens.

>> DKIM is designed to produce false positives. Which means DKIM-based
>> tests will have low specificity
>> (https://en.wikipedia.org/wiki/Sensitivity_and_specificity).
> 
> My experience ~> opinion, save for mailing lists, differs.  In fact,
> most of the email that I receive passes DKIM.

That does not contradict what I said. Low specificity means low
probability of detection of "bad stuff". I.e. it doesn't mean much that
most of it passes.

> I don't think DKIM (or SPF or DMARC) have /anything/ to do with spam
> detection.  SPF is for envelope sender authorization.  DKIM is for
> message integrity.  DMARC is for policy and reporting.  None of that has
> anything to do with spam detection / filtering.

Ohkay, so what exactly am I the end user is supposed to need it for?

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 02:10 PM, Dimitri Maziuk wrote:
They are different ASCII representations of the same byte, yes. They are 
not the same text.


Hum.  I wonder if we have been talking about slightly different things.

I've been referring to "ü" being displayed the same in MUAs which is 
interpreting the different underlying text in the various content 
transfer encodings.


Sign the text, re-encode text and signature together, 
anyone who cares about it can decode it back to where the signature will 
match.


Do I understand you correctly to mean to create the signature before 
applying transport encoding?



Only, you can't do that on the MX, it has to be done on the client.


Why can't you do it at the MX?

Or do you mean that it's inefficient to do so at the MX?

DKIM is designed to produce false positives. Which means DKIM-based 
tests will have low specificity 
(https://en.wikipedia.org/wiki/Sensitivity_and_specificity).


My experience ~> opinion, save for mailing lists, differs.  In fact, 
most of the email that I receive passes DKIM.


Which makes 
them bad for detecting spam. But that's OK, DMARC in general is for 
*fraudulent* e-mail, not *unsolicited* e-mail.


I don't think DKIM (or SPF or DMARC) have /anything/ to do with spam 
detection.  SPF is for envelope sender authorization.  DKIM is for 
message integrity.  DMARC is for policy and reporting.  None of that has 
anything to do with spam detection / filtering.


In fact, I've found that spammers (worth their salt) tend to be early 
adopters of email technology.  Thus they are quite likely to send spam 
that passes SPF and DKIM and DMARC.


I'm sure once I'm plagued by *fraudulent* e-mail, I'll start caring 
about RFC 7489 and the rest of them.


I started caring about SPF / DKIM / DMARC for a couple of reasons:

1) I'm pedantic and want to have the best filtering / security that I 
possibly can on my personal domain.


2) I was seeing blow back from mailing lists about DKIM and / or DMARC. 
Thus I dug in more and learned more.


To each his / her own motivation (or lack there of.)

When those e-mail are from mailman 
I'll start caring about what mailman does with DMARC headers. But at 
this point I'd just strip them all off.


I suspect that when (if) you care will be after you implement filtering 
(Chicken / Egg?) that possibly rejects messages from mailing lists.  Or 
possibly if your messages with enhanced security cause others to have a 
problem.  (Again with the chicken & egg.)



(And since I'm tripping down the memory lane:
https://catless.ncl.ac.uk/Risks/23/21#subj9.1)


:-P



--
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] cause of bounces

[Dimitri Maziuk]

On 10/18/2017 02:32 PM, Grant Taylor via Mailman-Users wrote:

> I'm referring to the difference between:
> 
>  - ü  - ASCII (?)
>  - =C3=BC - quoted-printable
>  - w7w=   - base 64
>  -  - HTML
> 
> All four representations are for the *same* letter / character / glyph /
> byte(s).

They are different ASCII representations of the same byte, yes. They are
not the same text. Sign the text, re-encode text and signature together,
anyone who cares about it can decode it back to where the signature will
match. Only, you can't do that on the MX, it has to be done on the client.

> DKIM, by design will fail if anything that is signed changes.

DKIM is designed to produce false positives. Which means DKIM-based
tests will have low specificity
(https://en.wikipedia.org/wiki/Sensitivity_and_specificity). Which makes
them bad for detecting spam. But that's OK, DMARC in general is for
*fraudulent* e-mail, not *unsolicited* e-mail.

I'm sure once I'm plagued by *fraudulent* e-mail, I'll start caring
about RFC 7489 and the rest of them. When those e-mail are from mailman
I'll start caring about what mailman does with DMARC headers. But at
this point I'd just strip them all off.

(And since I'm tripping down the memory lane:
https://catless.ncl.ac.uk/Risks/23/21#subj9.1)

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 01:07 PM, Dimitri Maziuk wrote:
17 == 0x11. "17" != "0x11". Which was precisely the point: if your MTA, 
say, does unicodedata.normalize( 'NFKD' ... ), and turns u-umlaut into a 
regular "u", you may consider it benign. Many won't.


I would not consider that benign at all.

I'm referring to the difference between:

 - ü  - ASCII (?)
 - =C3=BC - quoted-printable
 - w7w=   - base 64
 -  - HTML

All four representations are for the *same* letter / character / glyph / 
byte(s).


I consider those to be (effectively) benign content encoding changes.  - 
 Note the content is the same, with the only difference being how it's 
encoded.



Most importantly, crypto signature will change, and DKIM check will fail.


DKIM, by design will fail if anything that is signed changes.  (See the 
ROPEMAKER attack for a better explanation about anything signed.)



Benign is in the eye of the beholder.


~eh~ ... Okay.


We're inserting this stuff into a
database where a search for "Wutrich" will find neither "Wütrich" nor 
"W\u0308trich" so I wouldn't consider it benign at all.


I do not consider "Wutrich" and "Wütrich" to be the same string.  The 
former may be considered a poor representation of the latter.


I'm not sure which Unicode code point 308 is, but I doubt that it is the 
same as <ü> 252, Hex 00fc, Octal 374.  (I would have to look it up to 
know for sure.)


I would hope that data would be normalized to the same encoding in the 
database.  I.e. "=C3=BC" (quoted-printable) would be normalized to "ü" 
and stored in the database as such.


I would further hope that any search of the database would be able to do 
something like a character class (type) search so that it could match on 
"W[üu]trich".  (Adjust as necessary.)




--
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] cause of bounces

[Dimitri Maziuk]

On 10/18/2017 01:30 PM, Grant Taylor via Mailman-Users wrote:

> The (decimal) number 17 can be encoded multiple ways:
> 
> 10001 = binary  base  2
>    25 = hex base  6
>    21 = octal   base  8
>    17 = decimal base 10
>    11 = hexadecimal base 16
> 
> All five encoded numbers represent the same value (decimal) 17.

17 == 0x11. "17" != "0x11". Which was precisely the point: if your MTA,
say, does unicodedata.normalize( 'NFKD' ... ), and turns u-umlaut into a
regular "u", you may consider it benign. Many won't. Most importantly,
crypto signature will change, and DKIM check will fail.

Benign is in the eye of the beholder. We're inserting this stuff into a
database where a search for "Wutrich" will find neither "Wütrich" nor
"W\u0308trich" so I wouldn't consider it benign at all.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 12:35 PM, Mark Sapiro wrote:

DMARC is not the problem. It is perfectly reasonable for say, irs.gov to
publish DMARC p=reject as long  as mail From: irs.gov is not an
employees personal post to an email list. Presumably the IRS would have
rules against that.

The problem is when general ESPs that provide addresses in their domain
for anyone to use for any personal purpose publish DMARC p=reject.


I question what the fine line distinction will be for what domains can / 
should use DMARC (or the next disrupting technology).  Further, I 
question why domains that don't qualify, should be excluded from using 
said technology.


I suspect that we should also agree to disagree on this.


ARC has the potential to help. When say a yahoo.com user posts to a list
on my server and the list sends the post to a hotmail.com user, ARC
allows me to certify that Yahoo's DKIM signature was valid when I
received the mail, then I broke the sig but resigned the mail with my
domain's sig and sent it on to Hotmail. Now there is a chain by which
Hotmail can verify my sig and the fact that I certify Yahoo's sig. The
crux however is Hotmail has to trust me. Now if I'm GoogleGroups,
Hotmail will probably trust me but if I'm mail.python.org there might be
a mechanism by which I can ask Hotmail and every other ISP to trust me,
but is that going to work in practice. I think that remains to be seen.


It sounds like you have the same concern / unknown that I do.  What do I 
need to do to get  to trust my ARC signature.  -  Is ARC 
overloading my published DKIM key without clearly stating that it's 
using it?  Or is there something else that I'm not aware of?  Or is it 
simply a white list, or trust list, type issue.


If it's the latter, I feel like ARC has a design flaw before it even 
gets out of the gate.  I hope that's not the case.




--
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] cause of bounces

[Mark Sapiro]

On 10/18/2017 11:14 AM, Grant Taylor via Mailman-Users wrote:
> 
> I think it will be interesting to see what happens as more and more
> domains adopt DMARC, including those that use p=reject.  Especially with
> some of governmental institutions purportedly being mandated to use
> DMARC.  -  IMHO, DMARC is going to eventually become the new norm.


DMARC is not the problem. It is perfectly reasonable for say, irs.gov to
publish DMARC p=reject as long  as mail From: irs.gov is not an
employees personal post to an email list. Presumably the IRS would have
rules against that.

The problem is when general ESPs that provide addresses in their domain
for anyone to use for any personal purpose publish DMARC p=reject.


> I also wonder what ARC is going to do to this paradigm.


ARC has the potential to help. When say a yahoo.com user posts to a list
on my server and the list sends the post to a hotmail.com user, ARC
allows me to certify that Yahoo's DKIM signature was valid when I
received the mail, then I broke the sig but resigned the mail with my
domain's sig and sent it on to Hotmail. Now there is a chain by which
Hotmail can verify my sig and the fact that I certify Yahoo's sig. The
crux however is Hotmail has to trust me. Now if I'm GoogleGroups,
Hotmail will probably trust me but if I'm mail.python.org there might be
a mechanism by which I can ask Hotmail and every other ISP to trust me,
but is that going to work in practice. I think that remains to be seen.

-- 
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 11:51 AM, Dimitri Maziuk wrote:
Like tnеtсоnsulting.nеt being a benign minor encoding change in a couple 
of characters?


No.  That is not a simple content encoding change.  Content (re)encoding 
changes the representation of the same encoded data.


<е> 1077, Hex 0435, Octal 2065   != 101,  Hex 65,  Octal 145
<с> 1089, Hex 0441, Octal 2101   !=  99,  Hex 63,  Octal 143
<о> 1086, Hex 043e, Octal 2076   != 111,  Hex 6f,  Octal 157

An MTA changing the encoding method of data to / from: base 64 / 
quoted-printable / 8-bit, is distinctly different than what you have 
done, which is changing actual encoded data.


The (decimal) number 17 can be encoded multiple ways:

10001 = binary  base  2
   25 = hex base  6
   21 = octal   base  8
   17 = decimal base 10
   11 = hexadecimal base 16

All five encoded numbers represent the same value (decimal) 17.

What you have done (in the spirit of a white hat) is actually a 
homograph attack.  Something quite different from simple encoding 
differences.


Quite similar to a computer seeing a the following three characters as 
quite distinctly different things, each with different computational 
meanings.


0
O
o

Just because the authors of the RFC have also chosen to stick the square 
peg in the round hole doesn't make the hole any less round, nor the peg 
any less square.


Fair.


Somewhere I've a 10-year old e-mail from Whit Diffie explaining how SSL
was a PR solution to a marketing problem. So this kind of 
problem-finding and problem-solving has made to SMTP RFCs now, colour me 
shocked.


I'd be curious to read said email, if it's convenient to dig up.



--
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 11:50 AM, Mark Sapiro wrote:
...

This is the crux of our disagreement. The outbound message is still the
original author's message, albeit slightly altered by subject prefixing,
content filtering and/or other transformations to conform with list
policies. I don't agree that it is a completely new message. I think it
is still the original message with only technical and formatting changes.


I feel we have reached an impasse and we must agree to disagree.


The difference is wrapping the message preserves the original message's
headers (particularly From:) and makes it the content of another message
which says essentially "here's the message the list received". That
outer message can be From: the list and still be standards compliant.


Agreed.


However, if you are just sending the body of the original message From:
the list, according to RFC 5322 et al, you are saying the list is the
author of that message body. This is not true and is why I say the
message is not compliant with RFC 5322 et al.


I believe we are each entitled to our own opinions.  ;-)


Granted, all things considered, this is what most of us choose to do.
I'm not saying this shouldn't be done. It is something we are forced to
do because certain freemail providers choose to publish DMARC p=reject
policies contrary to the original intent of DMARC, but all I'm saying is
we should not forget that when we do this, we are sending messages that
are not strictly standards compliant.


I think it will be interesting to see what happens as more and more 
domains adopt DMARC, including those that use p=reject.  Especially with 
some of governmental institutions purportedly being mandated to use 
DMARC.  -  IMHO, DMARC is going to eventually become the new norm.


I also wonder what ARC is going to do to this paradigm.



--
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] cause of bounces

[Dimitri Maziuk]

On 10/18/2017 11:37 AM, Grant Taylor via Mailman-Users wrote:

> I believe I remember (but can't point to) something in the DKIM spec
> that referenced the possibility that the DKIM signature could be broken
> by things as benign as an MTA doing a content transfer encoding
> conversion.  -  I have personally seen this.

Like tnеtсоnsulting.nеt being a benign minor encoding change in a couple
of characters?

Just because the authors of the RFC have also chosen to stick the square
peg in the round hole doesn't make the hole any less round, nor the peg
any less square.

Somewhere I've a 10-year old e-mail from Whit Diffie explaining how SSL
was a PR solution to a marketing problem. So this kind of
problem-finding and problem-solving has made to SMTP RFCs now, colour me
shocked.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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] cause of bounces

[Mark Sapiro]

On 10/18/2017 09:31 AM, Grant Taylor via Mailman-Users wrote:
> 
> Um  My interpretation of 6854 § 1 and § 4 makes me think that an
> empty group list is perfectly acceptable.  Further, the group list can
> be non-empty and contain the lists posting address.


True, but in either case it still does not represent the "author" of the
message.


> I would rather do something like the following so that users could reply
> to the message.  (It would also avoid potential MUA issues as indicated
> by RFC 6854.)
> 
> I would think that it would be acceptable to use a From "group address"
> that is the mailing list.  I.e.
> 
>    From: Mailman Users:mailman-users@python.org;
> 
> Possibly even something like the following:
> 
>    From:  Grant via Mailman Users:mailman-users@python.org;
> 
> Arguably, this is conceptually very similar to what has become the
> defacto method to deal with DMARC today by munging the From:
> 
>    From:  Grant via Mailman Users 
> 
> The difference is that RFC 6854 codifies that there are times to alter
> the from.  -  At least that's how I'm interpreting this.


That's where you are wrong. All RFC 6854 does is allow the "group"
syntax to be used as the content of the From: header. It does not change
the RFC 5322 at al requirement that the From: header represent the
author(s) of the message.


> Further, if you believe the fact that the outbound message is indeed a
> completely new message (as I do) then it's completely legit to set the
> from to what ever you want.  ():-)


This is the crux of our disagreement. The outbound message is still the
original author's message, albeit slightly altered by subject prefixing,
content filtering and/or other transformations to conform with list
policies. I don't agree that it is a completely new message. I think it
is still the original message with only technical and formatting changes.


>> That type of forwarding is exactly what is done by Mailman's DMARC Wrap
>> Message action and that is the reason that action exists. Because in
>> that case the list message is RFC 5322 compliant. However many MUAs,
>> particularly mobile apps, have difficulty rendering such a message in a
>> good way, so Wrap Message isn't always the best option.
> It sounds like you're talking about message/rfc822 message attachments.
> -  That is a viable option.
> 
> However I see no reason that you can't take the body copy from the
> incoming email and use it directly in the new outgoing email.  No need
> to message/rfc822 wrap (or other digest like raping) the outgoing message.


The difference is wrapping the message preserves the original message's
headers (particularly From:) and makes it the content of another message
which says essentially "here's the message the list received". That
outer message can be From: the list and still be standards compliant.

However, if you are just sending the body of the original message From:
the list, according to RFC 5322 et al, you are saying the list is the
author of that message body. This is not true and is why I say the
message is not compliant with RFC 5322 et al.

Granted, all things considered, this is what most of us choose to do.
I'm not saying this shouldn't be done. It is something we are forced to
do because certain freemail providers choose to publish DMARC p=reject
policies contrary to the original intent of DMARC, but all I'm saying is
we should not forget that when we do this, we are sending messages that
are not strictly standards compliant.

-- 
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] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/18/2017 09:18 AM, Dimitri Maziuk wrote:

Then you seem to misunderstand what crypto signatures actually do.


I believe I understand what the crypto signatures actually do.

We are each entitled to decide what to actually do based on the result 
of the crypto signature (in)validity.


If signature check fails, then the message is not what its author 
actually wrote. IRL it's mainly SorceForge and the like injecting its 
ads into signed parts, (and the real reason google is pushing https and 
dkim so hard is it's messing with their ad revenue,) but in principle if 
the check fails the message *content* is *invalid*. Whoever the author 
and whatever the content.


I believe I remember (but can't point to) something in the DKIM spec 
that referenced the possibility that the DKIM signature could be broken 
by things as benign as an MTA doing a content transfer encoding 
conversion.  -  I have personally seen this.


As such, you can't be 100% positive that the message content's meaning / 
copy has actually changed, just that something about the message has 
changed.  -  Thus it is advised to only treat valid signatures as a good 
thing and be cautious of treating invalid signatures as a bad thing.


I use DKIM validity as a signal that I then make decisions based on. - 
Hence why I have chosen to alter spam score on my mail server based on 
the DKIM result.




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