In article
you write:
>> It doesn't say that in 4.1.2, even though it's sort of implicit since
>> i= means something else. I'd say so explicitly in a fifth bullet
>> after where it says "three (3) differences."
>
>One of those differences says:
>
>* the presence of the “instance tag”. Additional
In article
you write:
>-=-=-=-=-=-
>
>I've added the following text as Section 4.1.4 (note fixed typos and
>removal of the i= section, which is removed from ARC explicitly):
It doesn't say that in 4.1.2, even though it's sort of implicit since
i= means something else. I'd say so explicitly in a
In article
you write:
>The appropriate place for this guidance is likely a second paragraph in 4.1
>(https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1),
>as this guidance will apply to the three following header fields.
>
>Would you mind suggesting a paragraph to add in thi
In article
you write:
>-=-=-=-=-=-
>
>I agree ARC should be EAI-ized.
>
>To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth
>are approved by the IESG and properly update 7601 and 6376, then no direct
>changes are needed to the ARC spec?
>
>So the only wording consider
In article
you write:
>5.1.2 says when a chain fails, to put cv=fail in the AS and only Seal the
>ARC Set being added.
>
>Per the original message and suggested text, I believe 5.1.2 should only
>provide the above guidance when it is not otherwise possible to sign the
>entire ARC Chain (i.e. when
In article <4878884.yiV4iTtLKX@kitterma-e6430> you write:
>> In authentication service identifiers in EAI-formatted messages, a U-label
>> and its equivalent A-label are considered to be the same.
>
>As an implementer (who's tried really hard to avoid spending cycles on EAI -
>sorry), does this tr
In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman
>wrote:
>
>> And if you don't want to make a new one, 5.7.26 (Multiple authentication
>> checks failed) seems at least not wrong. To get to this point DKIM,
>> DMARC,
>> and ARC have failed.
>
>Is this bette
In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote:
>>
>> I'd say that all signatures in a seal SHOULD have the same domain, to make
>> them easier to evaluate.
>>
>
>So the Usage Guide will (does?) say that. Earlier consensus was to keep
>that out of the
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
I understand what that means technically, but I don't understand the
semantics of an ARC set where the AMS and AS are signed by different
domains.
R's,
John
___
In article <5b55a0f8.1c69fb81.123a9.5...@mx.google.com> you write:
>-=-=-=-=-=-
>
>draft-ietf-dmarc-arc-protocol
>
>The production “arc-info” includes a semicolon after “instance”, which in turn
>has a semicolon at the
>end. However, a great number of Arc-Authentication-Results header fields I’ve
In article
you write:
>> 9.2 describes the problem, but it's expressed in terms of a DoS attack on
>> (primarily) validators. The DNS folk will be more concerned with the
>> overall load on the infrastructure caused by ARC, not specifically on
>> attack scenarios. So in consulting the DNS directo
In article
you write:
>Given that we've settled on Experimental status, I propose this gets tabled
>until that's published. The experiment will establish what benefit ARC can
>provide, which I think is the most important output of this work. The
>change being suggested here appears to be one of
OM
([fe80::80d8:30b7:8b9:76b8%6]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018
01:33:40 +
From: John Levine
To: "jo...@taugh.com"
Subject: foonly
Thread-Topic: foonly
Thread-Index: AQHUGYBbeUQDz4tOwk+dGC+Hc9JmZA==
Date: Thu, 12 Jul 2018 01:33:40 +
Message-ID:
Accept-Language:
In article <2940516.WEBi8fTYBz@kitterma-e6430> you write:
>Is the list of EAI affected components of the field complete? As an example,
>sometimes email addresses are used for SMTP Auth user IDs (or sometimes just
>the local part). I don't know a lot about EAI, but it seems to me that most
>an
In article
you write:
>> Anything that comes close to 'do whatever you want with this
>> information' demonstrates NON-standardization.
Not at all. The point of a standard is to say here is what you do if
you want to interoperate. Trying to figure out how to recover when
someone else doesn't f
In article <66d513ca-f33d-748b-e394-bceb6e1da...@spamtrap.tnetconsulting.net>
you write:
>-=-=-=-=-=-
>
>On 05/15/2018 08:15 AM, Kurt Andersen wrote:
>> Manipulating MIME structures in email messages to expose the encrypted
>> content: https://efail.de/
>
>DKIM will not help protect against #Efai
In article <91efb193-9a81-4626-92ca-bf116826f...@uniregistry.link> you write:
>Contractual changes.
Not really.
This is the relevant text from
>https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html
But the paragraph at the end of that section, Exhibit A,
In article you write:
>> I think _dmarc as a TXT record is fairly well known. Is there anything
>> that would specifically prohibit this?
>
>gTLDs are not permitted to place TXT records in their zones.
That's mostly right. There is detailed language in the registry contracts about
what's allowe
In article
you write:
>This includes a registration for "header.a" and John's changes to support
>EAI. However, Barry has some concerns with how "local-part" is not left in
>a good state by these changes. Those of you in the WG with clue about EAI,
>please help me sort this out, since I do not
In article
you write:
>Et voila. If you go to the "History" tab and request a diff from the
>individual -00 to the working group -00, you can see all of the changes
>made relative to RFC7601. Basically it loosens up the language about what
>categories of things can be recorded, makes the ABNF c
The WG chairs do it online, start here:
https://datatracker.ietf.org/accounts/login/?next=/secr/sreq/
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
In article <01qo3ttohmle000...@mauve.mrochek.com> you write:
>This would need to be coordinated with the EAI people/list, but as long
>as it isn't controversial I don't see a reason not to put it in.
It's not supposed to be controversial, the minimum changes to make
stuff work with EAI UTF-8 messa
If I may budge in here, any chance we could put in a few tweaks for
EAI mail?
I think the main changes would be that if the A-R or AAR header is in
an EAI message, domain names and local parts can be UTF-8 rather than
ASCII. I specifically do not want to change any of the keywords or
codes, since
In article <1514939995.3318165.1222346488.5b169...@webmail.messagingengine.com>
you write:
>Please read my examples again if the problem wasn't clear, because you
>don't get security by imagining the best cases where everyone behaves
>themselves, you get security by imagining that everybody is tr
In article
you write:
>header.s is NOT defined: https://www.iana.org/assignments/email-auth/email-
>auth.xhtml
Quite right, need to put it in the IANA considerations of something.
FWIW, I added header.s to my SMTP daemon this afternoon. It took
about 10 minuutes. I'm a pretty good programmer,
In article
you write:
>https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10)
>feels clunky and itself says it needs more work.
To put it mildly.
>Assuming we're proceeding as an Experiment, I propose we address rotation
>in a separate draft.
I understand the motivation, but
In article
you write:
>"Experimental" is perfectly fine. As I understand it, EAI did that first
>and went to the standards track after it had some field use.
That is true, but it's also true that the standards track version of
EAI is fairly different from the experimental version, mostly by
lea
In article <13429029.WxFjRkil8E@kitterma-e6430> you write:
>> Stall ARC for a few more months until we can get ed25519 into the
>> libraries, then adjust the document to make it MUST verify both.
>
>I doubt you'll see it in OpenARC until after OpenSSL has a release that
>supports ed25519. That ma
In article <1513857489.3531319.1212273208.18fe8...@webmail.messagingengine.com>
you write:
>I certainly concur with Brandon here - changing ARC algorithm looks like
>a very messy proposition, I expect you'd pretty much have to do a window
>where both the old and new algorithm were supported - with
In article <20171219183616.ga6...@marwnad.com> you write:
>Section 6.6.3, Policy Discovery.
>
>"If the remaining set contains multiple records or no records,
>policy discovery terminates and DMARC processing is not applied
>to this message."
Oh, look at that. Thanks.
>> For that matter, what if
>> Dunno if this ever came up before. What, if anything, does this mean?
>>
>> _dmarc.example.com IN TXT "v=DMARC1; p=none"
>> _dmarc.example.com IN TXT "v=DMARC1; p=reject"
>
>https://tools.ietf.org/html/rfc7489#section-6.1 say
>.. MUST concatenate these strings ...
Nope, that's talking about s
ur provisioning system so if they get things wrong, or you want to
help them set up records like SPF or DMARC that they haven't gotten
around do doing themselves, you can just do it.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Inter
Dunno if this ever came up before. What, if anything, does this mean?
_dmarc.example.com IN TXT "v=DMARC1; p=none"
_dmarc.example.com IN TXT "v=DMARC1; p=reject"
Looking through RFC 7489 I don't see anywhere that it says that more
than one record is forbidden.
For that matter, what if anything
;> school.za: 10 ochre.school.za.
>> school.za: 20 mopani.school.za.
>> tm.za: 20 alt1.aspmx.l.google.com.
>> tm.za: 20 alt2.aspmx.l.google.com.
>> tm.za: 30 aspmx2.googlemail.com.
>> tm.za: 30 aspmx3.googlemail.com.
>> tm.za: 30 aspmx4.googlemail.com.
>> tm.za: 30 aspmx5.googlemail.com.
>> tm.za: 10 aspmx.l.google.com.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
I am working on yet another ARC library and am wondering what to do
about SHA1 signatures and 512 bit keys. The DCRUP working group has
sent a DKIM update to the RFC editor which finally kills SHA1 hashes
and RSA keys shorter than 1024 bits. It's in the queue and will be
published when they get a
In article <5fca5469-8673-9555-8e47-e2251632f...@tnetconsulting.net> you write:
>-=-=-=-=-=-
>
>On 10/13/2017 10:54 AM, John Levine wrote:
>> SRS is one of those magic bullets that might have worked if everyone
>> in the world implemented it at the same time, and the
In article <6a14ffbc-d704-b168-c5f4-6b971d48d...@tnetconsulting.net> you write:
>On 10/08/2017 08:29 PM, John Levine wrote:
>> * There is a kludge called SRS that embeds the original bounce address
>> in the forwarder's bounce address, but it doesn't help.
>
&g
In article <59da9de9.4000...@openfortress.nl> you write:
>Forwarding is an action on the receiving end, and can only be solved
>reliably by the recipient. Notably, a mailbox user could specify
>addresses that are forwarded to their mailbox. Mailing list
>subscriptions may be seen as a special for
In article <59c8d406.7000...@openfortress.nl> you write:
>I am looking forward to your responses. Please keep me in Cc: if possible?
I hate to be totally negative, but this draft revives a lot of things
that we considered and rejected when we did DKIM.
Marking content in an MUA is a WKBI*. Ther
In article
you write:
>Do we think there's any utility to adding more message info to the AS, such
>as message-id?
Probably not. Mailing lists sometimes change the message ID, so it's not
a very useful indication of evil.
Having watched this thread, I don't see what the issue is. If a bad
guy
In article <1502083287.2191248.1065195288.7cdc7...@webmail.messagingengine.com>
you write:
>I thought long and hard about using a less inflammatory title, but I
>figure maybe going in hard is the right way here, because I'd rather
>fix this before it becomes a standard! (and thanks Dave for your
>
In article you write:
>ARC is an underlying authentication mechanism that calls for a new
>assessment mechanism, since the role of the authenticated entity is
>different than the entities currently being assessed by filtering
>engines -- intermediary rather than originator.
Well, yes, but for
In article ,
Murray S. Kucherawy wrote:
>I think at the time DKIM went to Proposed Standard, one could've made the
>same argument about it as well, especially on your last two points.
Sorta kinda. At that point there wasn't any question that people
would use it to tie messages to domain names,
In article <6a1c679b-d5e0-2e4d-fe5f-b3a4c9db4...@gmail.com> you write:
>Today it's about being able to edit documents on the smallest device.
Naah, it's routing around damage, except that now it's flight routing
rather than packet routing.
I live in the US but I usually fly out of Toronto which i
In article <1496485938.3555.19.ca...@wemonitoremail.com> you write:
>MailMan has supported DMARC domains for ages through a simple address re-
>writing mechanism. It works quite well. The version running this list
>(2.1.22) definitely supports it, it just needs to be enabled.
The IETF has a long
In article <8f87f9de-c87e-406e-ba49-6aea5dc17...@kitterman.com>,
>Nothing other than potentially ARC requires multiple AR header fields for
>different authentication types to be combined. These different
>verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be
>different p
In article
you write:
>Looking at random messages on this list, I've seen anywhere from two to
>five AR headers per message. Locally, with opendkim and opendmarc running,
>there are three locally generated AR headers that get passed to openarc. It
>looks like seeing multiple AR headers is going t
In article <363edd8b-2654-4d81-ad41-d355599d3...@att.com> you write:
>-=-=-=-=-=-
>Right now we require support for two types of keys: a weak one (sha1) and a
>strong one (sha256).
True, but it's important to note that we don't require anyone to sign
with weak keys. A key record in the DNS can co
>Maybe we can build timelines into the updates. By Jan 1, 2019, receivers
>SHOULD (MUST?) no longer support the
>following key sizes or algorithms. That way, if anyone complains that a
>particular DKIM-signature is not
>considered valid, we can always say it’s RFC non-compliant.
The IETF histori
>If you believe sha256/rsa1024 are forever, there is no actual need for
>draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at
>some time, and this time is hardly predictable. There is also possible
>there may be the need to roll back ECC and mark it as insecure at some
>point of ti
In article <30f3baa9-f13b-91b4-c931-a2fb68582...@diennea.com> you write:
>If we want to put a meaningful value in this new field, I think it would
>be more useful to make it the time since when the key was obsoleted,
>this would allow for mail dated before that moment (which was correctly
>signed o
>1. produce 2 different DKIM-Signatures with 2 different selectors:
>slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA
Of course.
>2. add an additional field to either selector1 DKIM DNS record (need to
>consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's
>allo
In article you write:
>This may be of interest to this group, as there isn't an active DKIM WG
>anymore.
At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM
with a new crypto algorithm and/or a more compact key representation
(put the key in the signature and put a hash of it
>My reading of this too-long message thread is that there is essentially
>no support for making ARC's header-related issues any different from
>DKIM's, so I encourage the chair to shut this thread down.
What he said. Can we please limit subsequent discussion of testing
about how to test ARC as
In article
you write:
>The issue is that its possible for two separate arc implementations, given
>the exact same message inputs, keys, timestamps, etc to be generating two
>different, but equally valid ARC seal hashes.
DKIM does the same thing. The order of fields in a DKIM-Signature
header is
In article
you write:
>I'm not sure how you could go about registering key lengths. What do you
>have in mind?
Come to DISPATCH and learn all about it.
The general point is that DKIM's key advice is kind of stale -- 512 bit keys are
too short, 1024 keys are OK now, but within the likely lifeti
As threatened, albeit kind of late, here's plan for how to rotate to a
new algorithm.
We note that every Arc-Seal and Arc-Message-Signature header has an a=
tag that identifies the hash and signing algorithms used. (In sec
5.1.1.1 it just says hash, which is wrong.) Every DKIM key record has
k=
In article
you write:
>The last time I broached the topic of adding EC to DKIM, I was told there's
>no way that could proceed because EC was heavily encumbered by IPR claims.
>Is that no longer the case?
RFC 7479 adds Ed25519 to SSH and has no IPR disclosures.
Dan Bernstein is the primary autho
>It's been awhile since I've seen this, so it may not be a problem anymore.
>There is no obviously correct
>thing that someone won't screw up.
>
>It's probably better to specify how to put multiple strings together. RFC
>7208 has words that can probably be
>reused without modification.
Might a
>We should recommend secure defaults and let users of DNS crudware harangue
>their vendors or find new ones that
>can support publishing secure keys. We’re also foreshadowing long key lengths
>next year.
Having been dealing with the crudware argument for a very long time* I
can tell you that the
>As I recall there are issues using keys bigger than 1024 bits because
>construction and/or correct interpretation of TXT records that contain keys
>of that size or bigger has been problematic due to DNS provisioning
>software that does the former wrong and DKIM verifiers that do the latter
>wrong.
In article
you write:
>I'd like to come up with something better than updating DKIM every time
>there's new advice on key sizes, etc. Doing one update that points to the
>best current advice, and then letting that other thing get updated
>whenever, would be better. Otherwise at some point we'll
In article
you write:
>Trying to figure out some signing order for pathological cases seems
>unnecessary.
>
>What's the point of passing my failure status on?
I agree. We don't have legacy code to work around, so we should
concentrate on getting things to work correctly.
R's,
John
___
>How would you suggest we drive a revision to RFC 6376 to address this issue?
As you saw, anything in the IETF that smells of crypto tends to go
into the weeds with the crypto fad du jour.
If you want to do this, I'd suggest an update with a very small focus:
1) Add a new signature algorithm, pr
In article
you write:
>> No responsible operator has used the RFC minimum DKIM key sizes for a long
>> time. They were trivial to bypass half a decade ago. No one has ever
>> complained about 1024 bits default minimum being too big. ...
>I agree with your points, but don't you think it would be
>1) Do we have a normative reference within the RFC framework for key
>lengths for different crypto systems, and can we simply invoke that
>reference rather than including a hard figure in this spec?
There's RFC 3766, but it's over a decade old and has rules for how to
figure out how long a key yo
In article
you write:
>I'm currently working on a test suite for ARC, and have run into a few
>areas in the draft that could use some clarification, mostly with regards
>to section 5.2.1, which seems like it needs a non-trivial update. I've run
>into the following issues:
>
>- Can messages with
>It's a request, but my intend was it MUST be supported when the "ruf"
>tag is honored. Only if there is no "ruf", or a report generator ignores
>the "ruf", than the "fi" may be ignored. (I know some report generators
>don't implement "ruf", for reasons of privacy).
Remember that MUST only means "
>I'm not sure there's another way. If the domain receiving the reports were
>to be burdened with imposing the limit, it has only a few choices:
>
>* size up to withstand whatever load the greater Internet will throw at it
>(expensive);
>* build queueing infrastructure to accept anything the greate
>However, under certain circumstances this property can potentially lead
>to an undesirably high volume of reports. Especially when a Domain
>Owner's name is spoofed and abused in a large-scale phishing or other
>impersonation attack.
I gather that this was inspired by some sort of phish or spoof
In article <713098835.18678872.1478547678821.javamail.zim...@peachymango.org>
you write:
>The EAI WG found it was fine to remove the obligation to have an email address
>part in the
>mandatory RFC5322.From header, leaving only the display part to assert the
>original author.
Only in the very
>So, please point to the formal specification that permits a From: field
>to have no email address.
RFC 6854 section 2.1 allows the From: addresses to be an address-list.
In RFC 5322 sec 3.4, an adresss-list can be an address, an address can
be a group, and the group-list of addresses in a group
>Belittling people who are arguing that a long-standing problem needs
>to be fixed is not appropriate.
We all agree that the problem needs to be fixed, but many of us
believe we have a duty to try to understand a problem before demanding
"solutions" which would cause at least as many problems as t
>I've seen comments that people who were on Yahoo can fortunately go to Gmail.
>What happens when Gmail publishes a
>p=reject like they said they were going to (even if the timeline is delayed),
>per
>https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/?
They have said multiple ti
In article
you write:
>FWIW, I use Google For Work (or whatever it's called this week) and it
>doesn't automatically add DMARC headers--
Is it too much to ask that anyone who wants to tell us how to deal
with DMARC should at least read RFC 7489 so he knows how DMARC works?
R's,
John
Helpful ti
>Most of the recent work has been in regard to coordinating and testing the
>four (4) known implementations of the ARC spec (Google, AOL, dkimpy,
>OpenARC). They are each in various stages of completion/readiness for
>production.
Any chance we could get a peek at dkimpy or OpenARC? We understand
>My worry is that if DMARC started as a private mechanism for high value
>targets and large msps to collaborate to lower the risk of phishing for
>their shared users, and I don't want ARC to be perceived as breaking that.
>
>I don't want MSPs to have to come up with private lists of high value
>tar
>Should DMARC add a policy setting for whether the domain owner feels that
>ARC should be used to bypass regular DMARC evaluation?
Please, no. One approach to what we can oversimplify as the mailing
list problem is to do it from the sending end, with the sender using
something like conditional do
In article you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>In light of all of the discussion about how the LHS of email addresses are
>normalized and encoded/hashed in order to be used to
>publish certificates and keys via DANE records like SMIMEA and OPENPGPKEY we
>have put together an approach that le
>I can put together an appendix with some examples. I was thinking that
>having a better explanation would provide more value so I guess I got your
>suggestion backwards :-)
I'd prefer that you post the current version of the draft so we can
see what the context is. Draft revisions are cheap, pos
>I had not noticed -- and still don't quite understand -- what it is
>about the new stuff that will cause a legacy engine to fail the
>signature validation.
It's in section 3.5 of RFC 6376, the part about the DKIM-Signature
header, where it says:
v= Version (plain-text; REQUIRED). This tag de
>1. I wasn't recommending making the new feature optional. Merely
>noting the considerable benefit that accrues if you can live with it
>being optional.
You might want to reread my draft, because this discussion has no
relationship I can see to anything it says.
The DKIM spec says a signature i
>> Quite correct. I would expect conditional signatures to be applied by
>> large mail systems, using their private list of domains that look like
>> mailing lists to decide who gets them.
>
>How much of a barrier to entry to new or small mailing list providers
>(or new domains being used there) d
>> The local signer here must know this message goes to dmarc@ietf.org
>> an add a signature including "!fs=ietg.org"
>
>An average email author cannot be relied on to cause this setting to be
>made.
Quite correct. I would expect conditional signatures to be applied by
large mail systems, using t
> A sender that expects a message to be forwarded might put both a
> conventional DKIM signature and a signature with a !fs tag that
> refers to the domain name of the expected forwarder.
>
> require conventional, full DKIM signatures. Why? It seems to me that any
>DMARC authentication meth
I refreshed this draft so it wouldn't expire. Not very different,
mostly changed the @fs= to !fs= per Murray's suggestion.
I still think this is the least broken way I've seen to let
mailing lists coexist with DMARC.
R's,
John
___
dmarc mailing list
d
>ReSenders haven't introduced any interoperability issues. DMARC has. How
>about:
Indeed. I agree with the advice to refrain from blaming the victim.
> o MTAs sending email on behalf of multiple domains may require
> Domain Owners to provide DKIM keys to use DKIM to avoid SPF
> a
>But I am still receiving reports from hotmail despite DKIM and SPF
>tests passing ? So I don't understand what hotmail's system's are
>moaning about ?!?
Aggregate reports aren't failure reports, they're aggregate reports.
They tell you about all incoming mail that purports to be from you
and wha
>We've been looking at weak dkim from the angle of reducing what's covered
>by the signature... but unfortunately, that takes out the major parts of
>the message that we care about.
>
>I'm wondering if there is a different alternative.
When we were doing DKIM, we went around and around and around
>It is not wrong, I think you have no practical experience with EAI.
You might want to review these, as well as RFC 6783.
http://www.circleid.com/posts/email_in_the_worlds_languages_part_i/
http://www.circleid.com/posts/email_in_the_worlds_languages_part_ii/
http://www.circleid.com/posts/email_in
>> (3) I would really like to see some provision for reporting to mailbox
>> users when their mail is being discarded due to publication of
>> p=reject by their mailbox providers, especially in cases where a
>> Mediator is willing to put its reputation on the line by signing
>> the
>Please submit "stuff" that needs to be fixed
The worst problem is still section 3.1.2.3 which needs to be deleted,
since most of what it says is wrong, and what little isn't wrong is
irrelevant.
RFC 6854 is not about EAI, since an ASCII MUA can create mail with an
empty group From: as easily a
> > With double signing, you have the ability to distinguish between plain
> > old spammers, and spammers who are screwing around with forwarded
> > mail. I think that's a useful difference, since it is my impression
> > that the set of malicious mutating forwarders is pretty small because
> > it'
>On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or*
>simply suppress the DMARC check and apply all of our other antispam filtering,
>and update the MLM’s reputation accordingly.
Well, gee, you can do that now. We hope you do, since that will also
enable list mail from people
>> The double signing hack limits the opportunity for trouble to mail
>> systems that have a recent real message in hand. While I can
>> certainly imagine spammy scenarios, it's hard to imagine ones that
>> wouldn't be fairly easy to detect and shut down. ...
>True, the damage is limited to the l
>The challenge here is that the second signer may not have anything to do with
>the message. Since, except for From, only invisible parts of the message are
>signed, the signature could be applied to almost any email. Using the
>reputation of the second signer's domain is not substantially dif
>I would think you'd have to. There's a replay risk that's unique to this type
>of
>signature, so I think treating them the same would be a naive approach.
Remember that DMARC doesn't tell you that a message is good. The most
it can say is "not so awful that you should automatically reject it."
>> What would the Authentication-Results header look like? Presumably 3
>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC?
>> Show one result or two? Or maybe something like dmarc=conditionalpass? ...
>Is there any use in making a distinction to your acceptance/routing of
>> Remember the key axiom of mail reputation: you cannot say good things
>> about yourself, only neutral or bad things. ...
>This is an interesting observation when compared to DKIM and SPF, where you
>only actually know something about the message when they report a "pass".
>But that's authentica
>Under at least one of the proposals, it can be determined that "yes, A
>signed the mods, and if the mods are removed to re-generate the original
>message, B signed the original message". If we have that, then I think
>the question becomes: if this is to be a DMARC-like scheme, how do we tie
>A's
801 - 900 of 1003 matches
Mail list logo
