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/12569 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:53:45 http://comments.gmane.org/gmane.ietf.rfc822/12568 <pre>Colleagues, As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Reviews of the update are also welcome: Thanks, -MSK _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </pre> Murray S. Kucherawy 2013-03-22T16:55:24 http://comments.gmane.org/gmane.ietf.rfc822/12567 <pre>Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Reviews of the update are also welcome: https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ Thanks, -MSK _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </pre> Murray S. Kucherawy 2013-03-22T16:54:43 http://comments.gmane.org/gmane.ietf.rfc822/12561 <pre>Hi, I'm struggling to come up with the best approach for designing the "reply" feature in Trojitá. As far as I know, there's no single "best practices" document to follow (and many "XYZ considered harmful" ones and an interesting one about how Evolution works [1]). Here's what I'd like to do: - Always offer multiple ways to reply. These actions will be represneted by an expandable button (i.e. a button with an arrow on the right which performs the "reasonable thing" by default but allows you to click the arrow to see the other actions). - The rules for picking up the recipients will be the following: 1) If there's a List-Post header and its value is not set to "NO" (or an equivalent) and there's at least one mailto: URL in there, the "Reply to List" is enabled and listed as the default option. When user selects this action, all of the Sender, From, Reply-To, Cc and Bcc are ignored. 2) "Reply All" option is always available and will generate a list of recipients using the following rules: - All addre</pre> Jan Kundrát 2013-01-04T16:44:33 http://comments.gmane.org/gmane.ietf.rfc822/12560 <pre>Hi all, as you certainly know, the file utility can detect a message/rfc822 mime type from a message. It does so by recognizing the first line of the file. However, comparisons are qualified as case sensitive in the magic file that I attach, except for the Delivered-To and Return-Path that I just patched adding a "cC". I'm about to send the patch to the maintainer of the utility. I'm not patching the "From:" entry, as I never saw a message starting with it. Should that entry be removed? What other fields actually happen to be on the top of the header? For a short legend, the "!:mime" refers to the line just above it, and the "0" that starts the latter is the offset; "string" implies a string comparison and the "/t" is for text; whitespace is escaped in the test string following it, and a message terminates the line. The magic file supports many other operations, including regex, search, indirection, and more. See the man page. I found the latest version (5.11) online at http://www.dsm.fordham.edu/</pre> Alessandro Vesely 2013-01-03T15:20:21 http://comments.gmane.org/gmane.ietf.rfc822/12544 <pre>Hi, RFC 2045's ABNF grammar for the MIME-Version header does not contain any reference to CFWS or other tokens which can expand to allow comments: version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT Despite that, the RFC is pretty clear that any RFC822 comments are to be ignored [1]. Is that an error in the ABNF grammar, or is there a generic rule for comments somewhere else? With kind regards, Jan [1] http://tools.ietf.org/html/rfc2045#page-10 _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </pre> Jan Kundrát 2012-11-23T12:01:07 http://comments.gmane.org/gmane.ietf.rfc822/12542 <pre>Hi, it seems to me that according to RFC5322 [1], I should never remove the earliest message-ids from the References header when producing responses. Therefore the References header is supposed to grow indefinitely when people keep replying to old messages. Is that really the suggested behavior? Shouldn't I use only something like twenty most recent msg-ids found in my parent's References? With kind regards, Jan [1] http://tools.ietf.org/html/rfc5322#page-26 </pre> Jan Kundrát 2012-11-03T19:49:44 http://comments.gmane.org/gmane.ietf.rfc822/12531 <pre>I'm moving all the threads away from EAI last call, as I think I feel better with the current last call documents. I have been advised to also post to ietf-822&lt; at &gt;ietf.org. So apologies, if I cross post and you miss a bit of history. So I read RFC6530 and I'll try to resume my understanding. No MTA talking to another MTA will downgrade or upgrade an email. If the receiving MTA cannot handle UTF8, then the email will be bounced. Now the submitting MUA, will receive the bounce, and the MUA or the user may decide to provide an ASCII compatible email message, to be transmitted all the way. The RFCs do not seem to indicate specific ways to do a downgrade so that an International email can be converted into an ascii one and sent. It is left to the user may be with some help from its MUA to do this work. However what I see is the possibility, for the MUA to use the group syntax in the From: header and submit that to the MTA to deliver to the final MTA. If my understanding is correct, this is an issue because the </pre> Franck Martin 2012-09-11T23:59:19 http://comments.gmane.org/gmane.ietf.rfc822/12518 <pre>Hello. I am working on an implementation of an e-mail parsing library, and thereby am getting intimate with RFC5322. I am consequently trying to understand how to interpret some of the semantics of whitespace while parsing addresses, and I have come across a specific situation where I have not understood the RFC. I was thereby hoping that someone may be able to offer their expertise. (I will now apologize profusely if this is a misuse of this mailing list. I found a couple previous questions by someone working on a Ruby e-mail library while going through the archives, and thereby figured that it was at least not entirely frowned upon to ask such questions here.) In this case, the specific examples I am working with are as follows. The part I am concerned with is the display name (although depending on the answer to this issue I may be forced to reevalulate other things I currently believe I understand). 1: |Jay "Freeman"| 2: |Jay R. Freeman| For references, here are the higher-level (non-character class</pre> Jay Freeman (saurik 2012-08-25T05:25:16 http://comments.gmane.org/gmane.ietf.rfc822/12507 <pre>The EAI working group has a specific need to use "group" syntax to "downgrade" email addresses that are in UTF-8, when they are presented to a POP or IMAP client that does not understand such addresses. After a great deal of discussion of alternatives, replacing the UTF-8 addresses with empty groups turns out to be the only reasonable approach. But as it also turns out, RFC 5322 does not allow group syntax in the "from" header field. I have written a draft that "updates" RFC 5322, making one change: allowing group syntax in "from": http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ EAI only needs to use this in presenting messages to certain POP and IMAP clients, and does NOT need it as messages wend their ways through MTAs. That said, I think it would be better to remove the restriction than to document a specific-case violation. Please review the draft and comment. Please particularly note if you are aware of failures that will be caused by this change. Please, *speculation* is much </pre> Barry Leiba 2012-07-31T01:19:50 http://comments.gmane.org/gmane.ietf.rfc822/12506 <pre> A new IETF non-working group email list has been created. List address: ietf-822&lt; at &gt;ietf.org Archive: http://www.ietf.org/mail-archive/web/ietf-822/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/ietf-822 Purpose: Discussion of issues related to Internet Message Format [RFC 822, RFC 2822, RFC 5322] Notes: This replaces the existing ietf-822 list hosted at imc.org, and subscriptions will be automatically transferred from that list to this. For additional information, please contact the list administrators. _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </pre> IETF Secretariat 2012-06-14T21:37:51 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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.rfc822