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
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
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
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
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
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
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
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
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,
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
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
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
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
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
14 matches
Mail list logo
