Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

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

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

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 -

Re: [dmarc-ietf] Duplicate DMARC records and tags?

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

Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains

ings 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 Internet for Dummies", Please consider the environ

[dmarc-ietf] Duplicate DMARC records and tags?

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

Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains

>> org.za: 10 mx2.coza.net.za. >> 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:

Re: [dmarc-ietf] Lenient SPF

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. > >Where ca

Re: [dmarc-ietf] Lenient SPF

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

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

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

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

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

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

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

Re: [dmarc-ietf] ARC RFC status to target

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

Re: [dmarc-ietf] Next version of the draft was delayed due to TSA

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

Re: [dmarc-ietf] Valimail and DMARC

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

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

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

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

>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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

>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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

>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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

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

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

>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

Re: [dmarc-ietf] "Missed it by *that* much". . .

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

[dmarc-ietf] Changing algorithms

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=

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

>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

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

>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

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

>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

Re: [dmarc-ietf] DKIM update, was Section [5.2.1] of the ARC draft

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

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

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

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

>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

Re: [dmarc-ietf] ARC draft issues/clarifications

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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

>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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

>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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

>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

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

>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

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

>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

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

In article

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

>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

Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption

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

Re: [dmarc-ietf] versioning in draft-levine-dkim-conditional-02

>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

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

>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

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

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

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

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

Re: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"

> 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

[dmarc-ietf] draft-levine-dkim-conditional-02

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt

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

Re: [dmarc-ietf] Confused about DMARC Reports (ruf/rua)

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 what

Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

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/

Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

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 as

Re: [dmarc-ietf] Weaker single author signature

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's a lot

Re: [dmarc-ietf] Weaker single author signature

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

Re: [dmarc-ietf] Weaker single author signature

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 lifetime

Re: [dmarc-ietf] double signing and what DMARC actually does

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

Re: [dmarc-ietf] A Modest Proposal of Two Variations

No. Most domains aren't subject to significant phishing attacks, so for them it's useful for incoming mail from Paypal et al, but not for outgoing mail. I take it that a *significant* phishing attack is one where the 5322.From domain is involved with money, and the hook is a URL at a free web

Re: [dmarc-ietf] A Modest Proposal of Two Variations

Isn't the ideal objective of DMARC to be so reliable that *everybody* uses it with p=reject. No. Most domains aren't subject to significant phishing attacks, so for them it's useful for incoming mail from Paypal et al, but not for outgoing mail. At that point, 5322.From addresses will all be

Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

In article 1552316227.113529.1431130088299.javamail.zim...@peachymango.org you write: I went over the emails of this week, did not find any new comment/update for the above document. Do you know when you'll be posting a new draft? There's a fair amount of stuff to fix. R's, John

Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

With List-Id becoming a more generic feedback channel, I suspect that its value for indicating the participation of a MLM will further degrade. This is news to me. Can you explain or give pointers? The only application of List-ID with which I am familiar is to sort (or filter depending on which

Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow Solution)

I recall some earlier discussion about encoding information in From local part, but if for no other reason, automatic addition of new email addresses to contacts by some MUAs makes that highly problematic. This trick also has patent problems. DNS query to

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

Are we going to say The big four email providers pushed their problems onto everyone else ? Yes, of course. But as we've seen, we have little ability to push back. R's, John ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

Even if we were all to concur that altering the From by adding the list is the right way forward here (an intriguing idea at the moment), ... Just for the record, I haven't been responding to arguments about rewriting the From: line because I don't any way they will lead to anything useful, and I

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? Sure, everything has some cost. Something I should have made clearer is the difference between the costs of changes one imposes on one's

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

yes, but the problem with cost imposed on third parties is that it is valued different by the one who imposes it on someone else and the one, on which is it imposed. Well, sure. If I can force you to solve my problem, as far as I'm concerned that's a free solution. I hope we agree we want to

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

That last sentence is basically what I said about both of my drafts, and that logic was shot down. Once you've decided you don't like the arbitrary changes, you know who to blame, but you still have to decide what you like and what you don't. Yeah, now that I look at your drafts again, I see

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

A database is still needed of which domains will have an outbound mail stream with two signatures. Sorry, no, that's completely wrong. Please reread the draft. I have not yet taken the time to fully understand the weak and strong signatures idea, but if I may be forgiven for commenting

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

This can be solved by having the owners of mailing lists publish a yet-to-be-defined DNS record in which they proclaim the presence of a mailing list within that domain. That's unlikely to work, because malicious people can publish anything that legitimate lists can. There's a fundamental rule

Re: [dmarc-ietf] Ideas for list handling

Comments on either or both are welcome. They both have the same problem: the list says: Here's what I did. Whadda ya think? Every recipient system has to come up with its own heuristics to decide what combinations of changes are or are not acceptable, which means that the exact same message

[dmarc-ietf] Updated mandatory tag/conditional signature draft

I updated my conditional signature draft, which is now (thanks to a suggestion from Ned Freed) the mandatory tag draft. https://tools.ietf.org/html/draft-levine-dkim-conditional-01 The idea is that you have a weak signature on To, From, Date, Message-ID but not subject or body, with a new tag

Re: [dmarc-ietf] DKIM libraries, was Third Party Sender DMARC Adaptations

In article CABa8R6ujfHtRMC-Z11XiOto6WTfciXsFEKCGftOgHp=i0a_...@mail.gmail.com you write: -=-=-=-=-=- -=-=-=-=-=- Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll get a bad format or bad version in the AuthRes header. Wonder how old the DKIM1 is and whether we should

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

In article 551cc3fe.10...@dcrocker.net you write: On 4/1/2015 8:22 PM, John Levine wrote: In the latter case, it's really an entirely new protocol, which should be identified by the next-lower protocol, rather than by using the version field as an in-bred demultiplexing field. I suppose

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

Handled by whom? If we're talking about telling MUAs Don't render the unsigned part of the content the same way as the signed content, then a bunch of additional complexities begin to appear: We went over all of this ages ago when DKIM was young. It should all be in the DKIM WG archives. -

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

In the latter case, it's really an entirely new protocol, which should be identified by the next-lower protocol, rather than by using the version field as an in-bred demultiplexing field. I suppose, but if the two procols are 99% the same, and the new one is upward compatible with the old one,

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. Rehashing old arguments will not change anyone's mind. False assertions are like these are utterly useless.

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? My impression is that most users put a very low value on commercial bulk mail. I'm not

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up is fairly low, but it is very high value. Personally, I would be happy never to

Re: [dmarc-ietf] Sending email on behalf of?

From: John Doe (j...@dmarc-abuser.com) via NPO i...@npo.org I would try some tests particularly at AOL before I did that. AOL mail tends to reject anything that looks like a munged AOL address. The least painful approach may be to tell people with AOL addresses, sorry, please get a different

Re: [dmarc-ietf] interoperability draft for review

In addition to other comments: Section 3.1.2.3 is just wrong. EAI specifically does not allow for downgrading of messages in transit from UTF-8 headers to ASCII headers. The only place the header downgrade is allowed is when a non-EAI MUA picks up mail via POP or IMAP, but that would be long

Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective?

Yahoo is NOT the only one I've had issues with; hotmail is the same - a couple weeks and I'm bounced again on either from the ARSClist. Based on my experiences with Yahoo in the past, I'm not even going to waste my time CONTACTING them, let alone trying to lobby them. The problem is that Yahoo

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

HELO results are unrelated to DMARC. Is that still true when the bounce address is empty? It's fairly common to have an NDR with an empty bounce address and From: MAILER-DAEMON@flaky.example Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user supposed to do? R's, John

Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it

Do people concur with this change, or something close to it? I'm OK with it, but to the meta-question, I realize the practical issues involved with yanking something out of the production queue, but in this case I wonder if that's not the right thing to do. There's no great hurry in getting the

Re: [dmarc-ietf] Comments on dmarc-base-09

Not mentioned anywhere: Which SPF modes are considered to be a pass for purposes of DMARC? Presumably +, presumably not -, but it should say something about ? and ~ if it doesn't already. Not only is that another late-stage technical issue to punt to the working group, but I also claim that's a

Re: [dmarc-ietf] missing MX, Jim Fenton's review of -04

I'm staring at this and not understanding how the two are all that different. They both seek to ensure that a DMARC evaluation can be done on the From: domain, and thus both seek to ensure that the From: that lands in the inbox can be trusted by end users to be valid. Now, wait a minute. DMARC

Re: [dmarc-ietf] Jim Fenton's review of -04

What about pointing it may be a security issue to let these messages through? Only if we also point out that it may be a security issue not to let them through. Seasons xmas, John ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Phishing attacks on the Display From

1. Hotmail/outlook.com puts a green shield in the web UX in front of trusted senders who authenticate. Is that what you mean? Only sort of. That's ad-hoc since each recipient system has their private list of green-bar-worthy senders. (I mean, if I wanted to get into it, how would I do

Re: [dmarc-ietf] Phishing attacks on the Display From

4. Anything else? Figure out how to display signed mail from famous brands in a distinctive way analogous to browser green bars, and tell people to look for that. Crooks can figure out ways to misspell Paypal faster than you can blacklist them, and half the time the crooks don't even

Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows)

So the edge system generates a bounce message (MDN). Knowing that RFC5321.MailFrom will . To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the RFC5322.From of the MDN. Why wouldn't you add a DKIM signature that matches the domain name in the message From: line? The envelope

Re: [dmarc-ietf] Indirect email flows

Could I request the list admins, to drop the subject tagging and the footer on this list? And if possible remove the removal of the HTML? Every IETF list I subscribe to, which is a lot of them, is set up the same way with subject tags, message footers, and flattened text. There is no more

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

What sort of remedy would you suggest here? Off the top of my head, here are some suggestions: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any

Re: [dmarc-ietf] yet more From rewriting,

In article CAKXPkzs_PM=BhkZW0WsjERXGyMV3aeD_eshORxy=sAcn=yp...@mail.gmail.com you write: -=-=-=-=-=- -=-=-=-=-=- I'm not Doug, but Google unquestionably did that when AOL and Yahoo started publishing p=reject Again, this is an assertion and where is the evidence for this? Tech people at

Re: [dmarc-ietf] Modeling MLM behavior

The discussion of interoperability between DMARC and MLMs has become opaque enough to warrant taking the time to document the learning. To make comparing and contrasting between MLMs possible, I think the WG needs a model -- Take a look at RFC 6377. It's not really a BCP, but it lays out

Re: [dmarc-ietf] email orphans - embedded devices

. Thanks to John Levine for quietly inserting this into the WG's wiki. I'll be trying to find.. volunteers... from various embedded communities to contribute to this page. Feel free to note your own experiences. I stuck in a few things about the problems I've noted with the limited number of embedded

Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage

I would certainly suggest a thing independently of DMARC (thus both technically accurate and real-world-sensible) and, indeed, can't even claim credit for it: this has come up before in both the DKIM/ADSP discussion and in the origin of the term authoring list. I am surprised to learn that you

Re: [dmarc-ietf] Draft DMARC working group charter

Hmmm... I suppose we should also cite adding the mechanism into the DMARC spec, if there is a standard developed in time? Considering what we're (not) doing in DBOUND, I wouldn't hold my breath. (Given the range of functionality suggestions already made for finding the OD, the question of how

Re: [dmarc-ietf] Draft DMARC working group charter

An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include .com or .co.uk. Both of those are fine with me. That's fine with me, too, but be prepared for arguments from domains like uk.com that sell subdomains underneath a different

Re: [dmarc-ietf] Draft DMARC working group charter

I don't see how this can be considered out of scope without a viable alternative. The identification of the Administrative Domain is a normative requirement in DMARC, and if this problem is not solved, the specification will be stuck. Having tried and failed to solve this problem several years

Re: [dmarc-ietf] DMARC Lists - Minimal Change Set

DMARC and traditional mailing lists don't play nice for two reasons: the subject is modified to add a prefix, which invalidates the DKIM signature, and the body is modified to add a footer, which again invalidates the DKIM signature. It's more than that. Lists do all sorts of other stuff, from

Re: [dmarc-ietf] yet more whitelists, was signature sample

Also, it's a dance to put more policy data into the DNS in any form. The DNS people, as we appear to like to call them, don't like use of DNS to store policy data even though it's extremely convenient for us to do so. At a minimum, if we try to do that with TXT records again, we can expect a huge

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt

Playing around with ideas here. This one removes the l=0 signature stuff and instead makes DKIM-Delegate into a more self-contained thing, which I believe was suggested (or at least inspired) by Stephen's comments. There is still the potential for abuse during the ephemeral relationship period

<    4   5   6   7   8   9   10   >