Grant Taylor via Mailman-Users writes:
> IMHO, DMARC is going to eventually become the new norm.
It has been so since late 2015, according to the DMARC Consortium. At
that time they claimed that 80% of legitimate email was originated at
domains that participate in DMARC reporting protocols. I
Dimitri Maziuk writes:
> 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.
That may be true for you, but for most of us having most of our mail
have a valid DKIM signature, plus a DMARC
Grant Taylor via Mailman-Users writes:
> 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.
You can do that. But call it what it is: a deliberate decision NOT to
conform to a stan
Mark Sapiro writes:
> 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.
The IETF's position is that this decision is up to the forwarding
agent. If they change the Message-ID, that means they consider it
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 woul
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 c
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 t
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 refe
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 numbe
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 gene
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 sig
I didn't completely follow all of your message. I think we may have
been talking past each other.
On 10/17/2017 06:56 PM, Mark Sapiro wrote:
There's no such thing as a group's address unless the addresses are
listed along with the group name.
Um My interpretation of 6854 § 1 and § 4 mak
On 2017-10-17 19:09, Grant Taylor via Mailman-Users wrote:
If DKIM signature fails, then there is something wrong with the message,
and treat it suspiciously. Read: I increment the spam score. (If the
spam score is high enough I reject the message at SMTP time.)
If there is no DKIM signatu
20 matches
Mail list logo
