Vasiliy Faronov | 18 Feb 15:15 2014

List-Id on the receiving end


I'm looking for information on what receiving software does anything with the List-Id header as defined in RFC 2919. I'm especially interested in whether (and how) they process the list description phrase (section 3) if it's included.

Thanks for any pointers. (Not subscribed so please Cc.)

ietf-822 mailing list
ietf-822 <at>
Jan Kundrát | 29 Jan 21:08 2014

Correct value for EHLO when submitting mail

when a MUA submits e-mail over SMTP, what value shall be used in the 
HELO/EHLO greetings? Shall I just stick with "localhost", or trust the 
OS-reported hostname, if any, or shall I use the IP address of my local 

I see problems with all of these, and apparently Thunderbird went through a 
nice discussion on this matter [1]. I didn't find any answer about that in 
RFC 6409, unfortunately, and RFC 5321's discussion [2] about this topic 
leaves me without a definitive answer, either -- the MUA will have zero 
idea about the "primary host name" and its relation to what OS returns, so 
I'm inclinded to interpret this as a suggestion to use address literals, 
but then I've heard about spam filters penalizing such messages [1]...

What is the current best practice?

With kind regards,



Trojitá, a fast Qt IMAP e-mail client --
ietf-822 mailing list
ietf-822 <at>
Dave Crocker | 6 Jan 17:28 2014

Is RFC5322 a 'protocol'?

New year.  New time for abstract queries...

In spite of its title, I believe the *22 series of documents might 
qualify as a protocol, rather than "merely" as an object format 

The difference I see between a format and a protocol is that the latter 
specifies actions to take.

 From RFC 5322's basic specification, the parts of the document that can 
be argued to specify protocol is, therefore:

      Originator fields (From:/Sender:/Reply-to:)

Possibly also: <return>.

I suspect some of the additional fields that have been specified in 
separate documents similarly contain directions about actions to be taken.



Dave Crocker
Brandenburg InternetWorking
ietf-822 mailing list
ietf-822 <at>

johnsonhammond2 | 27 Apr 18:53 2013

Biggest Fake Conference in Computer Science

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 
( ) 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 for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of for comments from well-known researchers 

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 

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   Search Google using the 
keyword worldcomp fake for additional links.

ietf-822 mailing list
ietf-822 <at>
Murray S. Kucherawy | 22 Mar 17:54 2013



(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:


ietf-822 mailing list
ietf-822 <at>
Jan Kundrát | 4 Jan 17:44 2013

Different "replying" modes in a MUA

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,



Trojitá, a fast Qt IMAP e-mail client --
ietf-822 mailing list
ietf-822 <at>
Alessandro Vesely | 3 Jan 16:20 2013

Detecting message/rfc822 file type

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

TIA for any contribution.
# $File:,v 1.20 2011/12/08 12:12:46 rrt Exp $
#  file(1) magic for mail and news
# Unfortunately, saved netnews also has From line added in some news software.
#0	string		From 		mail text
0	string/t		Relay-Version: 	old news text
!:mime	message/rfc822
0	string/t		#!\ rnews	batched news text
!:mime	message/rfc822
0	string/t		N#!\ rnews	mailed, batched news text
!:mime	message/rfc822
0	string/t		Forward\ to 	mail forwarding text
!:mime	message/rfc822
0	string/t		Pipe\ to 	mail piping text
!:mime	message/rfc822
0	string/tcC		Delivered-To:	SMTP mail text
!:mime	message/rfc822
0	string/tcC		Return-Path:	SMTP mail text
!:mime	message/rfc822
0	string/t		Path:		news text
!:mime	message/news
0	string/t		Xref:		news text
!:mime	message/news
0	string/t		From:		news or mail text
!:mime	message/rfc822
0	string/t		Article 	saved news text
!:mime	message/news
0	string/t		BABYL		Emacs RMAIL text
0	string/t		Received:	RFC 822 mail text
!:mime	message/rfc822
0	string/t		MIME-Version:	MIME entity text
#0	string/t		Content-	MIME entity text

# TNEF files...
0	lelong		0x223E9F78	Transport Neutral Encapsulation Format

# From: Kevin Sullivan <ksulliva <at>>
0	string		*mbx*		MBX mail folder

# From: Simon Matter <simon.matter <at>>
0	string		\241\002\213\015skiplist\ file\0\0\0	Cyrus skiplist DB

# JAM(mbp) Fidonet message area databases
# JHR file
0	string	JAM\0			JAM message area header file
>12	leshort >0			(%d messages)

# Squish Fidonet message area databases
# SQD file (requires at least one message in the area)
# XXX: Weak magic
#256	leshort	0xAFAE4453		Squish message area data file
#>4	leshort	>0			(%d messages)

#0	string		\<!--\ MHonArc		text/html; x-type=mhonarc

# Cyrus: file(1) magic for compiled Cyrus sieve scripts
# URL:
# URL:
# From: Philipp Hahn <hahn <at>>

# Compiled Cyrus sieve script
0       string CyrSBytecode     Cyrus sieve bytecode data,
>12     belong =1       version 1, big-endian
>12     lelong =1       version 1, little-endian
>12     belong x        version %d, network-endian
ietf-822 mailing list
ietf-822 <at>
Pete Resnick | 28 Nov 00:02 2012

Re: [Editorial Errata Reported] RFC5322 (3400)

[Bcc'ed to ietf-smtp <at>; please discuss over on ietf-822 <at>]


The following erratum was posted for 5322. I'm inclined to reject it 
since this discussion actually took place during DRUMS (17-18 March 1998 
in a thread with a subject of "Small Clarification to msg-fmt-04" if you 
are inclined to look) and the consensus outcome as far as I could tell 
(as document editor) was that messages without a final CRLF were SMTP's 
problem. However, 5321 (and 2821) says:

    The mail data are terminated by a line containing only a period, that
    is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
    actually the terminator of the previous line (see Section 4.5.2).
    This is the end of mail data indication.  The first <CRLF> of this
    terminating sequence is also the <CRLF> that ends the final line of
    the data (message text) or, if there was no mail data, ends the DATA
    command itself (the "no mail data" case does not conform to this
    specification since it would require that neither the trace header
    fields required by this specification nor the message header section
    required by RFC 5322 [4] be transmitted).  An extra <CRLF> MUST NOT
    be added, as that would cause an empty line to be added to the
    message.  The only exception to this rule would arise if the message
    body were passed to the originating SMTP-sender with a final "line"
    that did not end in <CRLF>; in that case, the originating SMTP system
    MUST either reject the message as invalid or add <CRLF> in order to
    have the receiving SMTP server recognize the "end of data" condition.

Allowing the originating SMTP system to reject the message as invalid 
seems in conflict with 5322 on this point. So my rejecting this erratum 
will simply end us up with an erratum against 5321.

I'm inclined to hear opinions.


> The following errata report has been submitted for RFC5322,
> "Internet Message Format".
> --------------------------------------
> You may review the report below and at:
> --------------------------------------
> Type: Editorial
> Reported by: Christoph Anton Mitterer<calestyo <at>>
> Section: 3.5.
> Original Text
> -------------
>     message         =   (fields / obs-fields)
>                         [CRLF body]
>     body            =   (*(*998text CRLF) *998text) / obs-body
> Corrected Text
> --------------
>     message         =   (fields / obs-fields)
>                         [CRLF body]
>     body            =   (*(*998text CRLF) *998text) / obs-body
> It is RECOMMENDED that message bodies are terminated by CRLF, though this is in principle not necessary
(this does not apply to messages consisting only of a header section, as header fields are always CRLF terminated).
> Note however, that when transporting messages via SMTP the last lines of message bodies MUST be
terminated by CRLF as specified int RFC 5321, section
> Notes
> -----
> Hi folks.
> AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.
> RFC5321 section however states: "The mail data are terminated by a line containing only a
period, that is, the character sequence "<CRLF>.<CRLF>", where the first<CRLF>  is actually the
terminator of the previous line".
> So SMTP forbids, what this RFC allows.
> I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.
> My suggestion was to add this clarification.
> Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't
need the last CRLF.
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> --------------------------------------
> RFC5322 (draft-resnick-2822upd-06)
> --------------------------------------
> Title               : Internet Message Format
> Publication Date    : October 2008
> Author(s)           : P. Resnick, Ed.
> Category            : DRAFT STANDARD
> Source              : IETF - NON WORKING GROUP
> Area                : N/A
> Stream              : IETF
> Verifying Party     : IESG


Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478

ietf-822 mailing list
ietf-822 <at>

Jan Kundrát | 23 Nov 13:01 2012

The MIME-Version header and comments

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,

ietf-822 mailing list
ietf-822 <at>

Jan Kundrát | 3 Nov 20:49 2012

Limiting the amount of msg-ids in the References header

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,



Trojita, a fast e-mail client --

ietf-822 mailing list
ietf-822 <at>

John C Klensin | 12 Sep 19:06 2012


--On Tuesday, September 11, 2012 23:59 +0000 Franck Martin
<fmartin <at>> wrote:

> 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 <at> So apologies,
> if I cross post and you miss a bit of history.

Thanks.  I suspect it should be moved off the EAI list as well.
I won't insist on that (yet), but you should consider it.

> 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.

That is correct,  with one qualification.   If some MTA in the
system decides that avoiding the risk of blowback is more
important than properly delivering an NDN, the message
disappears.  I mention that in order to stress how little a MUST
means in the presence of what RFC 5321 describes as "operational
necessity".  If people are convinced that what the Standard
specifies is inappropriate or hazardous in their environment,
they will ignore the standard and do what they think is right.
In that context, the only difference between "MUST", "SHOULD"
and "Pretty Please" is whether the Standard looks silly when it
is ignored.  The choice of requirement words won't affect the

> 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.

Yes.  There is no "do not seem".  It isn't specified because
circumstances and remedies will differ too much depending on
what information is available and where.

> 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.

That MTA (really a Submission Server in today's vocabulary, see
RFC 6409) has to generate a backward-pointing envelope address
from somewhere to put into the MAIL command.  As far as I know,
there are only two types of methods in use: it figures the
address out from the headers of the message that MUA hands it
and it gets the information out of band.  If it has to figure it
out, it is pretty much stuck: the group syntax isn't permitted
in the envelope and there is no plausible transformation from
it.  FWIW, the Submission Server is prohibited (with a MUST)
from injecting an invalid message into the public Internet.  If
the backward-pointing envelope information is transmitted out of
band, I suppose that the MUA could supply group information in
the "From:" header field and a valid (and ASCII) address in the
envelope.  But that would be at least stupid and probably
malicious.  It is hard for me to believe that specific language
banning it --language that goes beyond the "don't do this"
language that already appears in
draft-leiba--5322upd-from-group-04-- would have any effect on
the author of an MUA who wants to do that or on the author of a
Submission Server who want to allow it.

So I think you are getting very excited about a non-problem.

> 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.

To say part of what I think John Levine has been saying, one of
the characteristics of FUSSP proposals in the past has been
that, having invented the FUSSP, not only the IETF will get in
line and change the way email works to accommodate your
solution, but those changes will deployed immediately worldwide
because the FUSSP is so important (see if you are
not familiar with it).  Not going to happen -- on the one hand,
there are lots of ways in which a receiving MTA (relay or
delivery server) may not have enough information to usefully
provide the checks you are looking for.  If the particular case
of a group in the "From:" header field is important enough, than
all an ADSP or DMARC procedure needs to do is to identify
messages containing such fields as non-validatable.  It isn't as
if there are no other circumstances that can result in a message
that can't be validated by those techniques.

> 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.

See above.  Good luck with that.

> I think this course would keep the security benefits that
> ADSP/DMARC provide to the email environment.
> Did I miss something?

Yes.  See above.



p.s.  I use different subscription addresses on different IETF
mailing lists.  If I were to try to reply to your message
accurately with a message that would be posted by the mailing
list expander to the EAI and ietf-822 or ietf-smtp lists, just
about the only way to do it would be to put multiple addresses
in the "From:" header, one that corresponded to each list.  Yet
another example of where that construction is potentially useful.

ietf-822 mailing list
ietf-822 <at>