http://blog.gmane.org/gmane.ietf.rfc822 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.rfc822/12504 <pre>Hi all, Over on ietf-smtp, https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ was developed late last year. This is an optional tweak to Received fields allowing annotation of entry into special states of mail handling, such as quarantines or hold-for-moderation MLM actions that would help to explain large gaps in timestamp sequences. I'm looking for a wider audience of reviewers and (hopefully supporters). If this sort of thing seems like a good (or terrible) idea, please do follow up and comment. How much and what kind of support is evident will guide the choice of what its next steps are (if any). Thanks, -MSK </pre> Murray S. Kucherawy 2012-01-09T22:44:07 http://comments.gmane.org/gmane.ietf.rfc822/12504 <pre>Hi all, Over on ietf-smtp, https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ was developed late last year. This is an optional tweak to Received fields allowing annotation of entry into special states of mail handling, such as quarantines or hold-for-moderation MLM actions that would help to explain large gaps in timestamp sequences. I'm looking for a wider audience of reviewers and (hopefully supporters). If this sort of thing seems like a good (or terrible) idea, please do follow up and comment. How much and what kind of support is evident will guide the choice of what its next steps are (if any). Thanks, -MSK </pre> Murray S. Kucherawy 2012-01-09T22:44:07 http://comments.gmane.org/gmane.ietf.rfc822/12502 <pre>Hi, just to check: S/MIME (http://tools.ietf.org/html/rfc5751) does not does include/cover the 5322.From and the 5322.To fields as part of the cryptographic payload. Protection of headers can be achieved by wrapping up a the complete message into a message/rfc822 bodypart and sign/encrypt that (par. 3.1 of that RFC). How is that with OpenPGP (http://tools.ietf.org/html/rfc4880)? OpenPGP does not protect 5322.From and 5322.To either, does it? Par. 5.11 of RFC4880: A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes anRFC 2822 &lt;http://tools.ietf.org/html/rfc2822&gt; [RFC2822 &lt;http://tools.ietf.org/html/rfc2822&gt;] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID. The recipient address is not mentioned anywhere. So is the following statement correct?: Neither S/MIME nor OpenPGP protects the '5322.headers' of a message, unless that message itself is wrapped up and used as body of an enclosing S/MIME or PGP message /rolf </pre> Rolf E. Sonneveld 2011-12-28T15:27:42 http://comments.gmane.org/gmane.ietf.rfc822/12501 <pre> In abuse reporting, an established albeit discouraged practice consists of redacting reported messages. In a nutshell, users may have the ability to signal some received messages as being abusive. Their mailbox providers should then wrap those messages according to abuse reporting format (ARF, RFC 5965) and send them back to the senders if they had subscribed to the relevant feedback loop. See http://en.wikipedia.org/wiki/Feedback_loop_%28email%29 Redaction conceals the recipient, rather than the sender. In this case, authors should markup the parts of the messages that contain sensible data, in case the recipients report those messages as spam, possibly inadvertently. A document describing how to carry out redaction is now in LC, so it can hardly mention privicons. However, privicons could consider this possible use. The redaction doc is at http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ For casual readers, privicons are defined here: http://tools.ietf.org/html/draft-koenig-privicons </pre> Alessandro Vesely 2011-12-09T12:18:22 http://comments.gmane.org/gmane.ietf.rfc822/12500 <pre> My comments on "Privacy Preferences for E-Mail Messages" . . . It would be more correct to use the term "header field" rather than "header" here and in the rest of the document. . . . . . . The definition of Sending User needs to be clarified: is it the email-address from the Sender: header field? Or one or more of the email-address from the From: header field? . . . . . . This "MUST" seems to conflict with the MAY later in this spec. . . . These definitions need to be formatted to more clearly distinguish the term from its definition. Perhaps like the "privicon" definition. The definition of "first line" is not at all clear except for a TEXT/PLAIN body. In the case of a TEXT/HTML body, the intent seems to be that the first line is the topmost "line" visible to the Receiving User. However, since the "first line" privicon is the determining specification in the case of disagreements and the MUA is expected to "enforce" this, the MUA must be able to *find* the privicon. This could be difficult for the MUA with sophisticated HTML code. For bodies such as IMAGE/*, AUDIO/*, VIDEO/*, MODEL/*, or APPLICATION/* how is the "first line" to be found? In the case of a MESSAGE/* the first line would be part of the embedded message's header and would probably cause a parse error. In the case of MULTIPART/MIXED the first line would presumably be the "first line" of whatever the first embedded part is. And in the case of MULTIPART/ALTERNATIVE the first line would have to be the "first line" of each embedded version with a method of resolving conflicts there, too. The remaining MULTIPART/* type bodies would have similar issues. The use of MUST here without specifying the required text is unenforceable and is better expressed with a SHOULD. . . . As mentioned above this MAY conflicts with the MUST earlier in the spec. I find the requirement of a single space character following the colon to be objectionable, this is not Usenet! There should also be provision for a comment or explanatory text following the privicon. . . . The preceding paragraph seems out of place. This example seems to imply that the "firstLine" is the first non-blank line, does this also apply to the body "first line"? By "Footnote" here do you mean "Footer"? . . . . . . It is not clear what privacy issue is being addressed with the "Don't print" privicon. If the Receiving User can more easily keep a message private by printing it, locking it in a safe, and deleting the electonic copy, why would the Sending User object? What danger does the Sending User prevent with this option? . . . The preceding paragraph is not clear. Do the privicons "OR" together or replace the first with the second under some conditions? This table is not symmetrical, so which is the first privicon and which is the second? Otherwise, explain why [/] and [o] cannot be in either order. . . . The first use of the word "header" in the preceding paragraph is correct, but the second is not! . . . This example places the (presumably first body line) privicon as part of the message header and thus will cause a syntax error and likely make the privicon invisible to the Receiving User. . . . If the following instructions are OPTIONAL, the use of 12 "MUST"s in them is hard to justify. . . . It seems to me that the list of *all* of the From: addresses, the Sender: address, and the To: addresses should be considered as non-third party addresses since they presumably are all aware of the message already. . . . The preceding paragraph is not clear. . . . Where is the option to tell the MUA "Do NOT delete, and never bother me again."? Where is the option to tell the MUA "Do NOT delete, and never bother me again."? Where is the option to tell the MUA "Do NOT delete, and never bother me again."? Esactly how can the MUA determine in the *body* that the Sending User identity has been removed? . . . Should the Sending User and all Receiving Users be considered as added to "internal" automatically for the purposed of this reply of forward? . . . It may be appropriate to forward the privicons of the original message, optionally. </pre> Bill McQuillan 2011-12-05T20:54:06 http://comments.gmane.org/gmane.ietf.rfc822/12498 <pre>FYI. </pre> Alexey Melnikov 2011-04-20T21:45:29 http://comments.gmane.org/gmane.ietf.rfc822/12445 <pre>This is some work starting up in the APPS area. Please comment on the apps-discuss list if you're interested in participating. From: apps-discuss-bounces&lt; at &gt;ietf.org [mailto:apps-discuss-bounces&lt; at &gt;ietf.org] On Behalf Of Simon Tyler Sent: Thursday, April 14, 2011 2:59 AM To: apps-discuss&lt; at &gt;ietf.org Subject: [apps-discuss] Comments on Malformed Message BCP draft Hi, Having read the Malformed Message BCP draft I am interested in getting some discussion going on its content and to find the best way forward. For those who missed it, the draft is at: https://www1.tools.ietf.org/html/draft-kucherawy-mta-malformed-00 I have a few comments on it. One thing that concerns me is the proposal that processing should stop when certain malformations are identified. For example it is proposed that should a badly wrapped header field be found (quite how we define this is left open, I presume a line that does not start with a valid header field name followed by a colon) then the processing agent should treat this as the end of the header. My feeling is that this opens up a greater potential hole than the one closed and that can be exploited. An example of the type of issue this could is cause is that should such a malformation occur before the MIME header fields in the header then this would cause the rest of the header and the message body to be treated as plain text. This could cause content analysis system to fail as they would not interpret the MIME content in the way that was presumably intended. Given that these recommendations are unlikely to be followed by all clients and servers, I feel that this suggestion will allow content through an agent without suitable processing. My preference on this particular malformation would be to continue processing the header fields, this is based on the assumption that what follows the malformed header field is more likely to be further header fields and not body content. What we do with the malformed header field I am less certain about. We could just ignore it or we could treat it as part of the previous header field - both will be right as often as they wrong. I would welcome some additional thoughts on this. I have similar feelings about some of the other suggestions including the lack of a MIME-Version header. We cannot ignore intended meaning just because a non-compliant application made a small error in the header fields. Everyone will be best served if we subject such messages to more analysis, not less. On the whole I think a set of guidelines in this area is good but it will be hard to reach consensus without agreement on some basic underlying principles. I would suggest that one such principle is to try to do what the intended recipient would most likely prefer, which is generally to fix and deliver non-spam messages. I would also propose some additions to the draft. At Mimecast we see a lot of messages generated by all sorts of systems and amongst these we see a lot of different kinds of message malformations. I'll suggest more as I think of them but for starters here are a few: 1. Excessively long lines in both headers and body. I commonly see lines that are several hundred Kbs in length. These are often valid messages in the sense that the content is desired by the receiver and in all respects other than line length are well formed. Obviously a limit has to be enforced and I would like to find a consensus on what sort of limit is reasonable. Initially I felt 8K was a good limit - it is after all 8 times the limit in RFC 5321. But it appears that this is too small a limit in real situations. When the limit is exceeded, what is the best option - a rejection or forced line wrap. I am open to both. 2. Invalid characters in headers. I often see headers with un-encoded 8bit characters. These are often displayed correctly to the recipient where the client happens upon the correct character set by virtue of chance. 3. 8bit characters in MIME sections with a content-transfer-encoding of 7bit. If you have read this far then I think you will agree with me that Murray has made a good start on a much needed set of guidelines. Now let's see if we can support him to expand on the work he has done and reach a consensus on the best approaches. Simon _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Murray S. Kucherawy 2011-04-14T19:07:39 http://comments.gmane.org/gmane.ietf.rfc822/12435 <pre>Another effort that was mentioned here previously. This one is just a re-posting of RFC3462 (multipart/report) removing the must-be-outermost-MIME-type restriction. Comments welcome. -MSK </pre> Murray S. Kucherawy 2010-11-08T05:40:54 http://comments.gmane.org/gmane.ietf.rfc822/12434 <pre>Some time ago I started looking into what the consensus is for various MTAs' handling of common malformations of email messages and MIME structures. The collected wisdom thus obtained so far appears in the draft I've introduced, which is only meant as a starting point for such a collection of other cases. There was some consensus that this would be a useful effort to start, so here I am starting it. :-) Please do feel free to review what's there and comment, and also submit suggestions for other cases that might be of interest to record for future implementers. -MSK </pre> Murray S. Kucherawy 2010-11-08T05:28:19 http://comments.gmane.org/gmane.ietf.rfc822/12423 <pre>In some R&amp;D I'm doing I'm comparing numerous MTAs about how they handle things like a non-header line before CRLF between the header and body. I'm trying to figure out if there's a rough consensus among them about how to handle such exceptions. Would a compilation of the results of that investigation be a useful candidate for publication as a BCP or Informational? -MSK </pre> Murray S. Kucherawy 2010-09-28T22:48:47 http://comments.gmane.org/gmane.ietf.rfc822/12416 <pre>I'm doing some work with the OMA in the area of spam reporting. They have developed an XML message format for reporting spam from a mobile handset. Because SMS and MMS (and even IM) have different structure than email, they went with something more extensible than what we currently do with DSNs. I'm helping that group try to converge with what we do in the email world, especially with what the MARF working group is producing (e.g., ARF, specified by recently-published RFC5965). The first thing is to register the MIME type they've created, and so I've crafted a template for that. The next thing we'd like to achieve is to be able to specify multiple spam reports in a single message, regardless of transport (they currently use HTTP POST, but there's no reason SMTP couldn't be used). The most obvious thing to do would be to use a multipart/mixed MIME message, and then include their MIME type in each of "n" parts. However, this is different than what was done with ARF, which used multipart/report. The advantage to using multipart/report, which stipulates that it must be the outermost MIME type, is that you know right away that you're processing a report rather than having to parse part way into the MIME tree to figure that out. (According to Tony Hansen, that's why this rule was put in place.) But although multipart/report is the most obvious construct for doing this, it doesn't lend itself to multi-report messages. So to get these to converge, we have to be a little creative or be very creative (in the "create a lot of documents" sense). We could do a message/digest, each sub-part of which is message/rfc822 and the MIME type within that is multipart/report. One could argue that this approach conforms to the multipart/report rules by having that be the outermost MIME part of each constituent message in the aggregate message, but that might be hard to defend given the spirit of that rule. There's also a stipulation that the MIME subtype of the second part in a multipart/report message must be equal to the report-type of the outermost part, with no other constraints. Thus to keep multipart/report at the outermost MIME but allow multi-message reports, we could comply by using "multipart/report; report-type=mixed" as the outermost MIME type and then use "multipart/mixed" inside. But this also sure feels hack-ish. So what would be more palatable to this community? Could multipart/report be updated to accommodate this use case? Should we register multipart/multi-report that relaxes some of the existing restrictions without changing the existing media type? Feedback/guidance is welcome. -MSK </pre> Murray S. Kucherawy 2010-09-22T05:52:59 http://comments.gmane.org/gmane.ietf.rfc822/12411 <pre> Section 3.4. Address Specification of RFC2822 specifies name-addr = [display-name] angle-addr What are the length limits on the display-name field? I take it a long display-name value would simply be folded as described under 2.2.3. Long Header Fields Are there practical length limits with respect to current SMTP clients and servers? Stephan </pre> Stephan Wehner 2010-09-18T04:44:06 http://comments.gmane.org/gmane.ietf.rfc822/12403 <pre></pre> Sonneveld, Rolf 2010-04-16T08:02:54 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.rfc822