gmane.ietf.rfc822

Biggest Fake Conference in Computer Science

2013-04-27T16:53:45

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

Authentication-Results

Murray S. Kucherawy — 2013-03-22T16:55:24

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< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Authentication-Results

Murray S. Kucherawy — 2013-03-22T16:54:43

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< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: Different "replying" modes in a MUA

Keith Moore — 2013-01-09T02:25:54

Indeed, it's useful to understand that back in ancient history, "Reply" 
was assumed to only go to the author, and this helps to explain why the 
"Reply-To" field seems to have a peculiar meaning. But user agents 
capable of some variant of "reply all" have been around for a very long 
time.  (since the early 1980s, IIRC)


The problem is, of course, that the author's intent and the recipient's 
intent may not be the same.  But since the author cannot reliably 
anticipate the nature of a recipient's response, and also since the 
recipient responding is responsible for any replies that he sends, 
clearly the recipient who is composing the reply must be the one to 
ultimately choose the recipient(s) of a reply.


I absolutely agree with this.


Users do, on the other hand, suffer embarrassment or worse (sometimes 
much worse) when their replies go to a different set of recipients than 
they expected or intended.

To the extent that users "essentially never" review addresses in 
replies, this might in part be

Re: Different "replying" modes in a MUA

Dave Crocker — 2013-01-08T04:22:27

This note follows the other comments you've already received. I think my 
comments are compatible with the ones you've already received.

Some inline comments, and then more summary ones:


On 1/4/2013 8:44 AM, Jan Kundrát wrote:
...

Just to note this specific point: The specific language in RFC 5322 is 
somewhat milder than the original design of Reply-to and is now:

      "When the "Reply-To:" field is present, it
    indicates the address(es) to which the author of the message suggests
    that replies be sent."

Reply-to was invented to give the orignal author an explicit means for 
specifying a /replacement/ to the From address, for replies, not for 
augmenting it.

So your proposed use of /both/ Reply-To and From is not strictly a 
protocol violation, but runs counter to the intent of the author who 
created the Reply-To. In fact, that's also the intent of mailing lists 
that add a Reply-To.

At that, I think the wording from RFC733 onward is not nearly as crisp 
and complete as it should have been,

Re: Different "replying" modes in a MUA

Ned Freed — 2013-01-05T06:44:11

Indeed.


While I agree with almost all of your subsequent points, I'm not convinced
this constitutes a position that is "diametrically opposed" to what the RFCs
say.


Quite correct. In the case of replies user intent is very complicated and
at best can be approximated by a small set of UA settings.


That summarizes the requirements I personally have for a UA in this regard very
nicely.



I'll also note that it's one thing to pull an address out of a field that's
displayed by default. At least in that case the user knows where it came from,
and has a little context as to what it means. It's quite another to pull it out
of field that isn't displayed. This can be a real surprise. 

And since most users agents don't allow the set of fields displayed by default
to be altered, the worst cases of this problem can't even be ameliorated.


I'm not sure how popular it is, but I personally do it all the time.

reliably be determined from the headers of the subject message.   Only the
author of the reply understand

Re: Different "replying" modes in a MUA

Keith Moore — 2013-01-05T04:14:59

(oh wow.  here we go again.)

1. I disagree with the RFCs about this, and always have.   (I state this up front just to make it clear that I am not proposing a novel way of interpreting the RFCs; I'm just saying that I disagree with them.   So there's no need to try to reconcile my view with what the RFCs say - we're just diametrically opposed.)

2. Regardless of the presence or absence of Reply-To or any other field, it is ALWAYS the recipient's job to decide to whom he wants to address replies.  

3. It is the job of the recipient's mail user agent ("agent" = acting on the recipient's behalf) to obey the recipient's wishes.   In particular, (a) it should allow the recipient to reply to whomever he wishes to reply and (b) make that behavior as obvious to the recipient as possible, so that the MUA's behavior will be unsurprising to the recipient of the subject message (the author of the reply).   

(Note that "to whomever he wishes to reply" might include addresses from any of the headers of the subject mess

Re: Different "replying" modes in a MUA

SM — 2013-01-04T18:15:43

Hi Jan,
At 08:44 04-01-2013, Jan Kundrát wrote:

I read the following in RFC 5322:

   'When the "Reply-To:" field is present, it indicates the address(es)
    to which the author of the message suggests that replies be sent.'

You message did not contain a "Reply-To:" 
field.  As such I am left will the following choices:

  (i)   Reply to the author

  (ii)  Reply to the mailing list

  (iii) Reply to the author and the mailing list

I am replying to you and copying the message to 
the mailing list.  It is a personal decision and not a "best practice".


Ok, you are using "List-Post:" to identify 
whether the reply to the list is possible.


The Bcc would be to your address.  It's like 
replying to yourself.  The "To" is similar if 
your address is in there.  I could remove it or, 
if my MUA has the option, set a preference.

If there is a "Reply-To:" I don't use the 
"From:".  If the "Reply-To:" is set by the 
mailing list I could use the "From:" if I would 
like the reply to go to all addresses.


Ok.

Different "replying" modes in a MUA

Jan Kundrát — 2013-01-04T16:44:33

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

Detecting message/rfc822 file type

Alessandro Vesely — 2013-01-03T15:20:21

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/

Re: [ietf-smtp] [Editorial Errata Reported] RFC5322 (3400)

Christoph Anton Mitterer — 2012-12-05T15:55:39

Hey all.


On Wed, 2012-12-05 at 07:31 -0800, Dave Crocker wrote:
Just to point that out again,.. I never claimed (I hope so) that there
was an error in the specs... just that this could deserve some
highlighting/clarifications.


Cheers,
Chris.

_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [ietf-smtp] [Editorial Errata Reported] RFC5322(3400)

Pete Resnick — 2012-12-05T15:35:32

It does, and I will.

Thanks for the feedback.

pr

Re: [ietf-smtp] [Editorial Errata Reported] RFC5322(3400)

Dave Crocker — 2012-12-05T15:31:06

On 11/28/2012 7:41 AM, Ned Freed wrote:


If there is a pattern of confusion, then clarifying text could be 
useful.  However it does not appear that there is a pattern of confusion.

It's also clear there is no 'error' in the specs.

I don't remember whether Errata rejection permits annotating the reason. 
  If it does, a terse version of Pete's explanatory text ought to 
suffice, for posterity.

d/

Re: [Editorial Errata Reported] RFC5322 (3400)

Ned Freed — 2012-11-28T22:07:59



It's not an unreasonable change but it it does not, as I understand the current
rules, rise to the level of calling for an erratum.




It might be possible to construct an errata there, but I doubt it. I think
a revision is really needed to fix this. But that raises the question of
whether or not it's worth it, which I also doubt.

Ned
_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [Editorial Errata Reported] RFC5322 (3400)

Ned Freed — 2012-11-28T19:34:43



The word "each" gives some weight to your argument. But not a lot - it would
have to be "every" to actually impose the restriction.


This says nothing about unterminated lines.


Well, the bigger problem is that the entire style of the RFC 3030 prose is
obsolete. We no longer mess around with discussions of local storage formats
and how to convert to and from them. We now focus on what's on the wire and
leave the implementation details to implementors.

MIME has some of this too, but not as bad.

In hindsight we should not have included this sort of language, but it seemed
like a good idea at the time.

Ned
_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [Editorial Errata Reported] RFC5322 (3400)

Tony Finch — 2012-11-28T18:18:35

That isn't how I read it:

  "In particular, it is essential that text be canonically encoded with
   each line properly terminated with <CR><LF>."

  "In particular, text/* MUST be sent with <CR><LF> terminated lines."

I agree with your interpretation of the intent of RFC 3030 but the way it
expresses that intent is not quite correct.

Tony.

Re: [Editorial Errata Reported] RFC5322 (3400)

Ned Freed — 2012-11-28T18:04:22


That's correct but really beside the point. The text in RFC 3030 doesn't
explcicitly say "all lines MUST be terminated". Rather, it's saying that when
terminators (it actually uses delimiter in another place) are used they have to
be CRLFs.

Ned
_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [Editorial Errata Reported] RFC5322 (3400)

Tony Finch — 2012-11-28T16:27:06

The problem is that "separators/terminator/delimiters/whatever" is not
sufficiently precise when we are concerned about the last line in the
file. If CRLFs are separators then the terminal one is optional; if they
are terminators then it is not.

Tony.

Re: [Editorial Errata Reported] RFC5322 (3400)

Ned Freed — 2012-11-28T15:54:30

Sorry, that's incorrect. The statements RFC 3030 makes are in the context of
converting to and from local storage formats. The intention is clearly to say
that line separators/terminator/delimiters/whatever have to be represented by a
canonical CRLF sequence.

At no time does RFC 3030 say that all lines in a text part have to be
terminated with a CRLF, only that when lines are terminated the terminator
has to be a CRLF. And as I pointed out previously: MIME explicitly allows
text parts that don't end in CRLF, and encoding is *not* required to
represent such parts inside of a multipart.

Ned
_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [ietf-smtp] [Editorial Errata Reported] RFC5322(3400)

Ned Freed — 2012-11-28T15:41:48

In one sense we do see it: Binary SMTP (RFC 3030) doesn't have any such
restriction.

I'll also note that MIME explicitly allows text parts inside of a multipart
that don't end in CRLF. In practice the CRLF often ends up getting added
and the use case for such parts is no longer relevant, but the fact remains
they are allowed.


Agreed on all points.


Agreed as well. And as for whether or not these issues should be reopened,
if this is causing actual operational problems somewhere I for one am not
aware of it.

If we're going to worry about text handling issues in email, there are far
more pressing problems than this.

Ned
_______________________________________________
ietf-822 mailing list
ietf-822< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822

Re: [ietf-smtp] [Editorial Errata Reported] RFC5322 (3400)

John C Klensin — 2012-11-28T09:17:50


--On Tuesday, November 27, 2012 17:02 -0600 Pete Resnick
<presnick< at >qti.qualcomm.com> wrote:


Pete,

Historically, there was no requirement that SMTP transport only
Msg-Fmt (822/ 2822/ 3822) messages.  There is no such
requirement in 821 other than, implicitly, that whatever is
being transported not be screwed up by SMTP relay addition of
trace fields.  Insisting that only 822-compliant messages be
transported would have combined with the now-deprecated IM-ish
SEND (and possibly SAML and SOML) command(s) would have led to a
UI silly state.    There was a bit of a contradiction there
because an issue with trace fields and what the origin and
delivery SMTP servers were required to add, but that was
clarified in 2821 at the same time that SEND and friends were
deprecated (an additional reason for requiring that Msg-Fmt
messages be transmitted was to make MIME and its body part
description headers work).

Conversely and much more important, 822 and its successors have
never required that message bodies be tran