headers
Dirk Fieldhouse | 3 Nov 1995 15:17
Picon
Favicon

Re: host vs hostname (Was: CID: and MID: URL schemes)

In article <9511021619.AA03957 <at> Accurate.COM>, elevinso <at> Accurate.COM says...
>
>In examining the syntax of id-spec in draft-levinson-cid-01 I
>considered substituting host for the existing hostname.  I.e.,
>changing the present syntax from
>        id-spec  := local-part " <at> " hostname
>to
>        id-spec' := local-part " <at> " host
>where (from rfc 1738)
>        host     := hostname | hostnumbmer
>and
>        hostnumber := digits "." digits "." digits "." digits

On a slight tangent (PMFJI, etc), all such references to addresses as a.b.c.d 
should be updated to handle IPv6 literal format. About this time last year that 
meant the following (I would look up the current version but our firewall is 
crawling at the moment):

TEXT REPRESENTION OF ADDRESSES 

	 Basic Format 
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 
1080:0:0:800:200C:417A 
	 Compressed Format 
FF01:0:0:0:0:0:0:43 as FF01::43 
	IPv4 Format 
0:0:0:0:0:0:0:13.1.68.3 
0:0:0:0:0:0:1:129.144.52.38 
::13.1.68.3 
::1.129.144.52.38
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Gardiner Myers | 3 Nov 1995 22:40
Picon
Favicon

Re: host vs hostname (Was: CID: and MID: URL schemes)

It is not possible to put ':' characters in the domain part of an
RFC822 address.  It's already used for source routing and too many
existing systems would interpret those characters as such.

IPv6 addresses are going to have to be handled some other way, perhaps
by using the IN-ADDR.whatever domain.

-- 
_.John G. Myers		Internet: jgm+ <at> CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From wohler <at> newt.com Mon Nov  6 13:12:27 1995
Received: from dimacs.rutgers.edu (root <at> dimacs.rutgers.edu [128.6.75.16]) by list.cren.net
(8.6.12/8.6.12) with ESMTP id NAA13109 for <ietf-smtp <at> list.cren.net>; Mon, 6 Nov 1995 13:12:21 -0500
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by dimacs.rutgers.edu
(8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA24415 for
<ietf-smtp <at> dimacs.rutgers.edu>; Mon, 6 Nov 1995 13:12:16 -0500
Received: from tango.rahul.net by relay2.UU.NET with SMTP 
	id QQzose15750; Mon, 6 Nov 1995 13:11:10 -0500 (EST)
Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA12216
  (5.67b8/IDA-1.5 for <info-ietf-smtp <at> uunet.uu.net>); Mon, 6 Nov 1995 10:09:53 -0800
Received: from bug.rahul.net by bolero.rahul.net with SMTP id AA10043
  (5.67b8/IDA-1.5 for <info-ietf-smtp <at> uunet.uu.net>); Mon, 6 Nov 1995 10:09:52 -0800
Received: by bug.rahul.net (5.67b8/jive-a2i-1.0)
	id AA15919; Mon, 6 Nov 1995 10:09:56 -0800
To: info-ietf-smtp <at> uunet.uu.net
Path: wohler.a2i!wohler
From: Bill Wohler <wohler <at> newt.com>
Newsgroups: info.ietf.smtp
Subject: Re: coordination with fax BFT and ITU
Date: 6 Nov 1995 18:09:55 GMT
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes E. Eggers | 30 Nov 1995 22:31
Picon

Help: Bloody DATE: Line in RFC 822

Hi,

I'm writing an SMTP receiver client and have problems interpreting RFC822 on
page 26 (Date and Time specification).

My problem is with the ZONE field.

>From my reading the spec, it seems that the Local differential can be used
INSTEAD of the Zone-Code.  Sureley that's not correct ?  I thought the point was
to use a zone-code as a minimum.  But then, the semantics say that it is allowed
to use an offset from UT without specifying whether or not the UT is acually
included...

My interpretation is as follows, and I'd appreziate if someone could confirm or
deny this:

zone = [Any-of-the-zone-descriptors][+ or - or nothing followed-by-4-Digits]
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                Mandatory                          Optional

I also take it that if there is + or - there has to be 4 digits after that

I also take it that there is no space allowed between the zone-name and the + or
- or 4-digit offset.

Is this correct ?

Thanks,

  Johannes
(Continue reading)

Permalink | Reply | 501 comments |
headers
Ned Freed | 1 Dec 1995 00:06

Re: Help: Bloody DATE: Line in RFC 822

> Hi,

> I'm writing an SMTP receiver client and have problems interpreting RFC822 on
> page 26 (Date and Time specification).

> My problem is with the ZONE field.

> >From my reading the spec, it seems that the Local differential can be used
> INSTEAD of the Zone-Code.  Sureley that's not correct ?

Nope, its quite correct. Note that all use of time zone names is discouraged --
numeric values should be used if at all possible. Quoting from RFC1123 (which
supersedes RFC822 in a number of areas):

         There is a strong trend towards the use of numeric timezone
         indicators, and implementations SHOULD use numeric timezones
         instead of timezone names.  However, all implementations MUST
         accept either notation.  If timezone names are used, they MUST
         be exactly as defined in RFC-822.

> I thought the point was to use a zone-code as a minimum.  But then, the
> semantics say that it is allowed to use an offset from UT without specifying
> whether or not the UT is acually included...

Nope. The point is to specify an offset from UT. Either a zone name or a
numeric offset does this.

A numeric offset, if present, provides the exact offset from UT. If you want
to add a zone name to this information, use a comment field, e.g.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Keith Moore | 1 Dec 1995 02:31
Picon

Re: Secure EMail, How?

> How can I send and receive email securely without any end user
> complexity? 

Unfortunately, that's sort of like asking how to make pigs fly.

First of all, what do you mean by "secure"?  Whom do you trust
not to snoop on your data or try to change it as it goes by?
The Internet? (probably not)  Your local network?  The local 
network at the other end of the connection?  You have to evaluate
your level of trust for every element in the path that handles
unencrypted data.

Do you trust the user's PC?  How do you make sure nobody else is
using it?  How do you make sure that nobody has modified the 
software on it, (either directly or due to infection by some virus)
to compromise the encryption program or the encrypted data?
(this is equivalent to asking "How do you stop users from installing
ANY outside software on their PCs?")

How do you know the user is who he says he is?  Do you store a
secret on a file on his disk that the user must possess before
you believe him?  How do you keep someone else with access to 
that PC (or a virus writer) from getting that secret or changing
it so that the user cannot access his bank account?  What happens
if the user's files (containing this secret) get copied to some 
other machine?

If you store the secrets or the encryption software on a file 
server, how does the PC authenticate itself to the file server?
(And how does the file server authenticate itself to the PC?)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald.T.Alvestrand | 1 Dec 1995 09:43
Picon
Picon

Re: Secure EMail, How?

YOu can't do it without SOME end-user complexity.
The user needs at least to be aware of who he is and who the
recipient is.
The systems manager needs to be aware of a good deal more than that.

Keywords are:
- PGP
- MOSS (PEM)
- Certificates
- Chains of trust
- Keyservers
- Secure password storage
- Trusted binaries
- Trusted local environment

If you don't know what security you are aiming for, deploying encrypted
E-mail is rather useless.

        Harald A
From majordomo <at> singnet.com.sg Tue Dec  5 17:36:54 1995
Received: from dimacs.rutgers.edu (root <at> dimacs.rutgers.edu [128.6.75.16]) by list.cren.net
(8.6.12/8.6.12) with ESMTP id RAA01850 for <ietf-smtp <at> list.cren.net>; Tue, 5 Dec 1995 17:36:01 -0500
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by dimacs.rutgers.edu
(8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA17045 for
<ietf-smtp <at> dimacs.rutgers.edu>; Tue, 5 Dec 1995 17:35:56 -0500
Received: from lantana.singnet.com.sg by relay2.UU.NET with SMTP 
	id QQzsvy26745; Tue, 5 Dec 1995 17:35:49 -0500 (EST)
Received: (from news <at> localhost) by lantana.singnet.com.sg (8.6.12/8.6.9) id GAA10671; Wed, 6 Dec 1995
06:35:46 +0800
To: info-ietf-smtp <at> uunet.uu.net
(Continue reading)

Permalink | Reply | 0 comments |

Gmane