Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis
On 09/10/2013 01:39 PM, Murray S. Kucherawy wrote: Hi Patrik, On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström p...@frobbit.se mailto:p...@frobbit.se wrote: What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries. I'm not sure that's a valid conclusion. Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX. The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data. Well, if the TXT/SPF query precedes the MX query (so the case '-1 second' of the '+/-1 second' described by Patrik) it might indicate an SPF record which includes an mx mechanism. In that case the queries are related. /rolf
Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
On 3/3/12 7:07 PM, ned+i...@mauve.mrochek.com wrote: This draft also defines the MT-Priority header field. �It is quite unusual for a SMTP extension specification to define a mail header field. ... This is my major concern about this protocol as well, as I note in the PROTO writeup (which, unfortunately, can't be seen publicly because of a limitation in the datatracker; perhaps I should post it here). I'm interested in hearing whether others share this concern, and what the community consensus is about it. I have no problem logging stuff from the SMTP session into a message header, we've been doing that since forever. But I have a lot of problem turning a header back into SMTP for a subsequent relay, for two reasons. One is just that it's ugly. There were good reasons to separate the envelope from the body back in the 1970s, and I think those reasons are just as good now. Over in the EAI group, there was a valiant effort to tunnel EAI messages through non-EAI SMTP servers via downgrades, and we eventually gave up. Now, if you want to send an EAI message, there has to be an EAI path all the way from the sender to the recipient. This isn't exactly analogous, but it's instructive. The other reason is that I think it's too ill-specified to interoperate. The theory seems to be that the relay server notices an MT-Priority: header, and (vigorous waving of hands) somehow decides if the message has sufficient virtue to promote the header back into the SMTP session. The hand-waving is not persuasive; the suggestion of S/MIME, which obviously won't work, is not encouraging. Both good points. While I personally am indifferent to header modification being an issue - I believe we've long since crossed that bridge - I will also note that simply changing this proposal to always insert the MT-Priority: field at submission time and leave it unchanged throughout message transit would leave most of the functionality intact and eliminate the header modification issue entirely. But the upleveling of header to envelope would remain. John is quite correct in his assertion that these are mostly uncharted waters: The only remotely comparable case I can think of is the mapping of some X.400 fields to the NOTARY extension, but in that case the mapping was from X.400 envelope material to SMTP envelope material. Additionally, the mapping was precisly specified with no wiggle room for site policy. +1 And there's another issue, I think. As there is 'upleveling of header to envelope', the draft also describes the reverse process. In par. 4.4 an SMTP client that talks to a non-confirming SMTP server MUST add it's own MT-Priority header with a priority determined by the process described in par. 4.2. This means an MTA can receive a mail with priority determined by envelope information and sends the message using header information. Those of us who wrote SMTP client software are in a better position to comment on this than I am. But having dealt with different MTA's it strikes me as fairly unusual for an SMTP client to add headerlines to the message-in-transit at such a late stage during transmission of the message to the SMTP server. /rolf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi, Murray, having read the draft I support its publication as experimental RFC. One suggestion: under 'Security Considerations' add a reference to what is said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same consideration applies for this ATPS document. /rolf On 12/3/11 9:32 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, December 02, 2011 3:59 PM To: SM Cc: ietf@ietf.org Subject: Re: Last Call:draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) Yes, I've already changed my working copy. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 [...] The working copy now uses ADMD. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. SM and I agreed that changing it to authorized and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 The definition used for Updates, as I understand it, is that we say X updates Y if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the Updates, please let me know. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM- Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
On 8/3/11 7:13 PM, David Morris wrote: On Wed, 3 Aug 2011, Warren Kumari wrote: I seem to remember discussions about this a long time ago, but searching through archives gets no love... How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like [Discussion] or [IETF] or something [0]. I'd REALLY like such a tag ... almost all the other lists I subscribe to use such a prefix. [IETF] would be my preference. Short is good. I'm happy to let those who prefer to not have such a prefix setup their procmail rules to remove it.-:) s/procmail rules/sieve filter/ :-) /rolf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
One final note from me, as I want to state my current position regarding 4871bis, with respect to Last Call. As the receiving verifier has all the information to _reliably_ [0] determine which combination(s) [1] of From [2] and DKIM-Signature verifies correctly, it has the means to provide any consuming application with the right information. The mechanism(s) by which the verification results can be communicated to a consumer (as per par. 6.2 of 4871bis) can be chosen by the verifier and does not restrict the results to only TEMPFAIL, PERMFAIL and SUCCESS [3]. Second, today there is hardly any installed base of MUA's that present any form of DKIM results to the end user, so most of this technology still needs to be written and 4871bis contains sufficient warnings about duplicate From and other fields; so in my view the argument of DKIM not being 'compatible' with the currently installed base of MUA's does not apply. Third, DKIM is only one of multiple technologies that can and will be deployed by both senders and receivers. This means that any policy published by a sender regarding the use of DKIM does not have to provide a sharp 'black' or 'white', 'keep' or 'discard' result. Senders that wish to publish a policy need to take into account that the world is not perfect and that there always will be lousy implementations of protocols (be it RFC5321, RFC5322, RFC4871 or RFC4871bis). [4] It's better to acknowledge this, than to rely on the 'MUST's in this particular DKIM RFC. Policies that do not take this into account, can/may have dramatic results. Hence, I no longer see a problem in 4871bis not mandating the duplicate header check. /rolf [0] irrespective of whether a From field has been prepended or appended or no such thing at all [1] (s) plural form, if there are multiple DKIM-Signatures and multiple From fields. [2] From is mentioned here only: - because it is the only mandatory header field to be used to generate the signature and - for the case that there's a consuming application that would display the From header, which in your view is the attack vector Apart from that, there is no special reason to focus here on From [3] although TEMPFAIL and PERMFAIL are mentioned in 4871, there is no equivalent identifier for a positive result, is there? I suggest to make the success status explicit in 4871bis [4] The fact that a sender doesn't know in advance how well the receiver implements the DKIM verification process will need to be taken into account for any policy protocol that will be built on top of DKIM. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
