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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </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 addresses in the message's From and Reply-To will be used in the "To" field - All addresses in the message's To will be in the Cc - All addresses in the message's Cc will be in the Cc - All addresses in the message's Bcc will be in the Bcc After this is complete, a list will be "sanitized": - Duplicate enteries in each To/Cc/Bcc are be removed - Addresses already in To are removed from Cc and Bcc - Addresses already in Cc are removed from Bcc The List-Post and the Sender headers are ignored when doing the Reply-All thing. The "Reply All" is the second candidate for a default (i.e. the default when "Reply List" is not available). 3) "Private Reply" option is always available and produces a message with the following recipient(s) in the "To" field: - If the message contains a Reply-To, each of those which are at the same time *not* listed in any List-Post addresses are used. If the resulting set is non-empty, the From header is ignored. This means that any address in the Reply-To which is also listed in the List-Post is silenty ignored and anything not in the List-Post is used. - The Sender header is always ignored. - If the recipients list is empty at this point, everything from the From field is used. - If the resulting set contains more than one address, the duplicates are eliminated. I am very interested in hearing what you think about this scheme. I realize that this is a topic with a huge potential for a good flame, and I suspect there are people who have very different opinions as to what is best. Despite that, I'll be happy to hear what issues are lurking in the algorithm I describe and what drawbacks I'm eniterly missing. Please also feel free to point me to any existing discussion as long as it's different from [1], [2] and [3] which I've read already. When the discussion settles, I plan to impleemnt the outcome in Trojitá (along with a test case with plenty of examples matching real-world scenarios). Thanks for your help! With kind regards, Jan [1] http://david.woodhou.se/reply-to-list.html [2] http://www.unicom.com/pw/reply-to-harmful.html [3] http://woozle.org/~neale/papers/reply-to-still-harmful.html </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/cgi-bin/man-cgi.pl?topic=magic&amp;ampsect=5 TIA for any contribution. #------------------------------------------------------------------------------ # $File: mail.news,v 1.20 2011/12/08 12:12:46 rrt Exp $ # mail.news: file(1) magic for mail and news # # Unfortunately, saved netnews also has From line added in some news software. #0stringFrom mail text 0string/tRelay-Version: old news text !:mimemessage/rfc822 0string/t#!\ rnewsbatched news text !:mimemessage/rfc822 0string/tN#!\ rnewsmailed, batched news text !:mimemessage/rfc822 0string/tForward\ to mail forwarding text !:mimemessage/rfc822 0string/tPipe\ to mail piping text !:mimemessage/rfc822 0string/tcCDelivered-To:SMTP mail text !:mimemessage/rfc822 0string/tcCReturn-Path:SMTP mail text !:mimemessage/rfc822 0string/tPath:news text !:mimemessage/news 0string/tXref:news text !:mimemessage/news 0string/tFrom:news or mail text !:mimemessage/rfc822 0string/tArticle saved news text !:mimemessage/news 0string/tBABYLEmacs RMAIL text 0string/tReceived:RFC 822 mail text !:mimemessage/rfc822 0string/tMIME-Version:MIME entity text #0string/tContent-MIME entity text # TNEF files... 0lelong0x223E9F78Transport Neutral Encapsulation Format # From: Kevin Sullivan &lt;ksulliva&lt; at &gt;psc.edu&gt; 0string*mbx*MBX mail folder # From: Simon Matter &lt;simon.matter&lt; at &gt;invoca.ch&gt; 0string\241\002\213\015skiplist\ file\0\0\0Cyrus skiplist DB # JAM(mbp) Fidonet message area databases # JHR file 0stringJAM\0JAM message area header file # Squish Fidonet message area databases # SQD file (requires at least one message in the area) # XXX: Weak magic #256leshort0xAFAE4453Squish message area data file #&gt;4leshort&gt;0(%d messages) #0string\&lt;!--\ MHonArctext/html; x-type=mhonarc # Cyrus: file(1) magic for compiled Cyrus sieve scripts # URL: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.6/internal/bytecode.php # URL: http://git.cyrusimap.org/cyrus-imapd/tree/sieve/bytecode.h?h=master # From: Philipp Hahn &lt;hahn&lt; at &gt;univention.de&gt; # Compiled Cyrus sieve script 0 string CyrSBytecode Cyrus sieve bytecode data, _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </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 receiving MTA will not have enough information to provide a check using ADSP or DMARC. This case should not be allowed. That a receiving MTA downgrade the From: into a group syntax for the MUA to be able to display the email to the end user, is an annoyance in terms of ADSP/DMARC but as mentioned the fix is for the end user to upgrade its MUA. ADSP/DMARC would have already been applied to the email at this stage, so no core functionality would be lost in that transaction. The MTA would also have added Authentication-Results: header with the necessary information to indicate the result of SPF, DKIM, ADSP, DMARC. However this header is not easily visible to the end user. The DMARC spec can alert people about this case in Security Considerations, i.e. We could live with it. So in summary, my opinion is that a submitting MUA MUST NOT be allowed to use the group syntax when submitting an email to an MTA. Corrolary a MTA MUST not accept an email where the From: header contains the group syntax and should bounce that email. I think this course would keep the security benefits that ADSP/DMARC provide to the email environment. Did I miss something? This opinion is not the opinion of the DMARC group nor my company, etc… this is an individual submission as anything IETF related. _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </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) rules from RFC5322 that are important for these two parses. display-name = phrase phrase = 1*word / obs-phrase obs-phrase = word *(word / "." / CFWS) word = atom / quoted-string atom = [CFWS] 1*atext [CFWS] quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] Now, one problem I run into is that the grammar is somewhat ambiguous with regards to the placement of CFWS, however, I will use a greedy expansion for the purposes of interpreting these examples. In the first case, I end up with a phrase, and in the second an obs-phrase. (I have included two different versions of the second parse, as technically both are greedy but using a different order for the arguments of the alternation in the obs-phrase rule.) 1: atom:|Jay | quoted-string:|"Freeman"| 2: atom:|Jay | atom:|R| "." atom:| Freeman| 2: atom:|Jay | atom:|R| "." CFWS atom:|Freeman| At this point, the standard is clear that the whitespace surrounding the atoms and the quotation marks surrounding the quoted string (in addition to any whitespace outside of those, although this example has none) are semantically not part of the values. Both atom and dot-atom are interpreted as a single unit, comprising the string of characters that make it up. Semantically, the optional comments and FWS surrounding the rest of the characters are not part of the atom; the atom is only the run of atext characters in an atom, or the atext and "." characters in a dot-atom. Semantically, neither the optional CFWS outside of the quote characters nor the quote characters themselves are part of the quoted-string; the quoted-string is what is contained between the two quote characters. As stated earlier, the "\" in any quoted-pair and the CRLF in any FWS/CFWS that appears within the quoted-string are semantically "invisible" and therefore not part of the quoted-string either. In these cases, I would then presume, I would end up with the display names |JayFreeman| and |JayR.Freeman|. In the first case I find this perfectly reasonable. In the second case, however, I'm somewhat confused by the lack of resulting whitespace. Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other specification. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. Given this description, I would have assumed that the purpose of this expansion is to support clients that don't feel they need to provide quotation marks around names. I feel somewhat vindicated in this understanding due to RFC5536 2.1. o Articles are conformant if they use the &lt;obs-phrase&gt; construct (use of a phrase like "John Q. Public" without the use of quotes, see Section 4.1 of [RFC5322]), but agents MUST NOT generate productions of such syntax. However, without the whitespace--which I am required to ignore due to the rules on how atoms are parsed--this seems to not be a useful obs- exception. Am I fundamentally misunderstanding this situation? Is whitespace in these contexts actually preserved? (If whitespace is preserved, how does one handle the whitespace between the display name and the addr-spec, or whitespace between other random atoms in the specification, or whitespace preceeding the display name after the "To:"?) For completeness, I can also come up with a second way to interpret the second example, which is |JayR. Freeman|, as neither of the above semantics rules indicate that the CFWS in the obs-phrase is to be semantically ignored, and should thereby become a space. Runs of FWS, comment, or CFWS that occur between lexical tokens in a structured header field are semantically interpreted as a single space character. That said, I am not certain if these are technically even "lexical tokens in a structured header", as my read of other sections of the specification indicate that the structured header itself only has a single token, an addr-list, and inside of that token there must be explicit rules regarding how whitespace is parsed. Finally, for comparison, I have attempted to parse this using a few implementations to see what they do. (BTW, if this is interesting, I'm happy to do more work and test actual clients.) I have added an additional test, 3:|"Jay" R Freeman|, to stress multiple spaces. Java JavaMail: 1:|Jay "Freeman"| 2:|Jay R. Freeman| 3:|"Jay" R Freeman| Java MIME4J: 1:|Jay Freeman| 2:|Jay R. Freeman| 3:|Jay R Freeman| 3:|Jay R Freeman| (Lenient) Python email.utils: 1:|Jay Freeman| 2:|Jay R. Freeman| 3:|Jay R Freeman| Ruby TMail: 1:|Jay Freeman| 2:|Jay R.Freeman| 3:|Jay R Freeman| PHP mailparse_rfc822_parse_addresses: 1:|Jay Freeman| 2:|Jay R.Freeman| 3:|Jay R Freeman| PHP imap_rfc822_parse_adrlist: 1:|Jay Freeman| 2:|Jay R. Freeman| 3:|Jay R Freeman| Of these results, there is actually very little similarity :(. MIME4J, when using its "lenient" parser returns the same results as Python's e-mail.utils, and Ruby's TMail returns the same results as PHP's mailparse extension. (Incidentally, I believe that the reason the PHP imap extension returning different results from the PHP mailparse extension is that the imap extension is calling out to c-client, whereas the mailparse extension was coded in-house.) So, again, if anyone here is willing to help me understand what the correct behavior here is, I would be most appreciative. ;P Sincerely, Jay Freeman (saurik) saurik&lt; at &gt;saurik.com _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </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 less useful than specifics of what you *know* will break. Barry _______________________________________________ ietf-822 mailing list ietf-822&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-822 </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 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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.rfc822