PA TRADUCIR

4.1. Miscellaneous obsolete tokens

These syntactic elements are used elsewhere in the obsolete syntax or
in the main syntax. The obs-char and obs-qp elements each add ASCII
value 0. Bare CR and bare LF are added to obs-text and obs-utext.
The period character is added to obs-phrase. The obs-phrase-list
provides for "empty" elements in a comma-separated list of phrases.

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
standard. 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. In the future, period may appear in the
regular syntax of phrase.

obs-qp = "\" (%d0-127)

obs-text = *LF *CR *(obs-char *LF *CR)

obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
%d12 / %d14-127 ; LF

obs-utext = obs-text

obs-phrase = word *(word / "." / CFWS)

obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]

Bare CR and bare LF appear in messages with two different meanings.
In many cases, bare CR or bare LF are used improperly instead of CRLF
to indicate line separators. In other cases, bare CR and bare LF are
used simply as ASCII control characters with their traditional ASCII
meanings.

4.2. Obsolete folding white space

In the obsolete syntax, any amount of folding white space MAY be
inserted where the obs-FWS rule is allowed. This creates the
possibility of having two consecutive "folds" in a line, and
therefore the possibility that a line which makes up a folded header
field could be composed entirely of white space.

obs-FWS = 1*WSP *(CRLF 1*WSP)

4.3. Obsolete Date and Time

The syntax for the obsolete date format allows a 2 digit year in the
date field and allows for a list of alphabetic time zone
specifications that were used in earlier versions of this standard.
It also permits comments and folding white space between many of the
tokens.

obs-day-of-week = [CFWS] day-name [CFWS]

obs-year = [CFWS] 2*DIGIT [CFWS]

obs-month = CFWS month-name CFWS

obs-day = [CFWS] 1*2DIGIT [CFWS]

obs-hour = [CFWS] 2DIGIT [CFWS]

obs-minute = [CFWS] 2DIGIT [CFWS]

obs-second = [CFWS] 2DIGIT [CFWS]

obs-zone = "UT" / "GMT" / ; Universal Time

; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7

%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case

Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049. If a two digit year is
encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900.

In the obsolete time zone, "UT" and "GMT" are indications of
"Universal Time" and "Greenwich Mean Time" respectively and are both
semantically identical to "+0000".

The remaining three character zones are the US time zones. The first
letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
"Mountain" and "Pacific". The second letter is either "S" for
"Standard" time, or "D" for "Daylight" (or summer) time. Their
interpretations are as follows:

EDT is semantically equivalent to -0400
EST is semantically equivalent to -0500
CDT is semantically equivalent to -0500
CST is semantically equivalent to -0600
MDT is semantically equivalent to -0600
MST is semantically equivalent to -0700
PDT is semantically equivalent to -0700
PST is semantically equivalent to -0800

The 1 character military time zones were defined in a non-standard
way in [RFC822] and are therefore unpredictable in their meaning.
The original definitions of the military zones "A" through "I" are
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
through "Y" are equivalent to "-0100" through "-1200" respectively;
and "Z" is equivalent to "+0000". However, because of the error in
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
there is out-of-band information confirming their meaning.

Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages. Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band information confirming their meaning.

4.4. Obsolete Addressing

There are three primary differences in addressing. First, mailbox
addresses were allowed to have a route portion before the addr-spec
when enclosed in "<" and ">". The route is simply a comma-separated
list of domain names, each preceded by "@", and the list terminated
by a colon. Second, CFWS were allowed between the period-separated
elements of local-part and domain (i.e., dot-atom was not used). In
addition, local-part is allowed to contain quoted-string in addition
to just atom. Finally, mailbox-list and address-list were allowed to
have "null" members. That is, there could be two or more commas in
such a list with nothing in between them.

obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]

obs-route = [CFWS] obs-domain-list ":" [CFWS]

obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)

obs-local-part = word *("." word)

obs-domain = atom *("." atom)

obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]

obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]

When interpreting addresses, the route portion SHOULD be ignored.

4.5. Obsolete header fields

Syntactically, the primary difference in the obsolete field syntax is
that it allows multiple occurrences of any of the fields and they may
occur in any order. Also, any amount of white space is allowed
before the ":" at the end of the field name.

obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /

obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)

Except for destination address fields (described in section 4.5.3),
the interpretation of multiple occurrences of fields is unspecified.
Also, the interpretation of trace fields and resent fields which do
not occur in blocks prepended to the message is unspecified as well.
Unless otherwise noted in the following sections, interpretation of
other fields is identical to the interpretation of their non-obsolete
counterparts in section 3.

4.5.1. Obsolete origination date field

obs-orig-date = "Date" *WSP ":" date-time CRLF

4.5.2. Obsolete originator fields

obs-from = "From" *WSP ":" mailbox-list CRLF

obs-sender = "Sender" *WSP ":" mailbox CRLF

obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF

4.5.3. Obsolete destination address fields

obs-to = "To" *WSP ":" address-list CRLF

obs-cc = "Cc" *WSP ":" address-list CRLF

obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF

When multiple occurrences of destination address fields occur in a
message, they SHOULD be treated as if the address-list in the first
occurrence of the field is combined with the address lists of the
subsequent occurrences by adding a comma and concatenating.

4.5.4. Obsolete identification fields

The obsolete "In-Reply-To:" and "References:" fields differ from the
current syntax in that they allow phrase (words or quoted strings) to
appear. The obsolete forms of the left and right sides of msg-id
allow interspersed CFWS, making them syntactically identical to
local-part and domain respectively.

obs-message-id = "Message-ID" *WSP ":" msg-id CRLF

obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF

obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF

obs-id-left = local-part

obs-id-right = domain

For purposes of interpretation, the phrases in the "In-Reply-To:" and
"References:" fields are ignored.

Semantically, none of the optional CFWS surrounding the local-part
and the domain are part of the obs-id-left and obs-id-right
respectively.

4.5.5. Obsolete informational fields

obs-subject = "Subject" *WSP ":" unstructured CRLF

obs-comments = "Comments" *WSP ":" unstructured CRLF

obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF

4.5.6. Obsolete resent fields

The obsolete syntax adds a "Resent-Reply-To:" field, which consists
of the field name, the optional comments and folding white space, the
colon, and a comma separated list of addresses.

obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF

obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF

obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF

obs-resent-to = "Resent-To" *WSP ":" address-list CRLF

obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF

obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / [CFWS]) CRLF

obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF

obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF

As with other resent fields, the "Resent-Reply-To:" field is to be
treated as trace information only.

4.5.7. Obsolete trace fields

The obs-return and obs-received are again given here as template
definitions, just as return and received are in section 3. Their
full syntax is given in [RFC2821].

obs-return = "Return-Path" *WSP ":" path CRLF

obs-received = "Received" *WSP ":" name-val-list CRLF

obs-path = obs-angle-addr

4.5.8. Obsolete optional fields

obs-optional = field-name *WSP ":" unstructured CRLF

5. Security Considerations

Care needs to be taken when displaying messages on a terminal or
terminal emulator. Powerful terminals may act on escape sequences
and other combinations of ASCII control characters with a variety of
consequences. They can remap the keyboard or permit other
modifications to the terminal which could lead to denial of service
or even damaged data. They can trigger (sometimes programmable)
answerback messages which can allow a message to cause commands to be
issued on the recipient's behalf. They can also effect the operation
of terminal attached devices such as printers. Message viewers may
wish to strip potentially dangerous terminal escape sequences from
the message prior to display. However, other escape sequences appear
in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
indiscriminately.

Transmission of non-text objects in messages raises additional
security issues. These issues are discussed in [RFC2045, RFC2046,
RFC2047, RFC2048, RFC2049].

Many implementations use the "Bcc:" (blind carbon copy) field
described in section 3.6.3 to facilitate sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of "Bcc:"
has implications for confidential information that might be revealed,
which could eventually lead to security problems through knowledge of
even the existence of a particular mail address. For example, if
using the first method described in section 3.6.3, where the "Bcc:"
line is removed from the message, blind recipients have no explicit
indication that they have been sent a blind copy, except insofar as
their address does not appear in the message header. Because of
this, one of the blind addressees could potentially send a reply to
all of the shown recipients and accidentally reveal that the message
went to the blind recipient. When the second method from section
3.6.3 is used, the blind recipient's address appears in the "Bcc:"
field of a separate copy of the message. If the "Bcc:" field sent
contains all of the blind addressees, all of the "Bcc:" recipients
will be seen by each "Bcc:" recipient. Even if a separate message is
sent to each "Bcc:" recipient with only the individual's address,
implementations still need to be careful to process replies to the
message as per section 3.6.3 so as not to accidentally reveal the
blind recipient to other recipients.