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 </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 mus</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 </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 adv</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