Email Alerting with DRAC5

Brian A. Seklecki lavalamp at
Wed Feb 4 11:30:40 CST 2009

here's tehe thing -- RFC2821 says:

" ...consolidates, updates and clarifies, but doesn't add new or change
existing functionality of the following:

   -  the original SMTP (Simple Mail Transfer Protocol) specification of
      RFC 821 [30]..."

But it also says:

   "It obsoletes RFC 821..."

Here are my notes from July of 2008:


Page 30 of rfc821.txt actually indicates that "[]" is a
valid SMTP FROM syntax:

 MAIL <SP> FROM:<reverse-path> <CRLF>

 <reverse-path> ::= <path>
   <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"

  <mailbox> ::= <local-part> "@" <domain>

And Finally:

 <domain> ::=  <element> | <element> "." <domain>
 <element> ::= <name> | "#" <number> | "[" <dotnum> "]"

Where [DotNum] is okay.


"Sometimes a host is not known to the translation function and
         communication is blocked.  To bypass this barrier two numeric
         forms are also allowed for host "names".  One form is a decimal
         integer prefixed by a pound sign, "#", which indicates the
         number is the address of the host.  Another form is four small
         decimal integers separated by dots and enclosed by brackets,
         e.g., "[]", which indicates a 32-bit ARPA Internet
         Address in four 8-bit fields."

On Wed, 4 Feb 2009, Brian A. Seklecki wrote:

> > 3.6 Domains
> >
> >    Only resolvable, fully-qualified, domain names (FQDNs) are permitted
> >    when domain names are used in SMTP.  In other words, names that can
> >    be resolved to MX RRs or A RRs (as discussed in section 5) are
> IIRC, our determination that IP addresses were acceptable was from RFC822,
> maybe not.  It has been a while:
>   4.1.2 Command Argument Syntax
>       MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
>       "MAIL FROM:" ("<>" / Reverse-Path)
>                        [SP Mail-parameters] CRLF
> >> If I recall correctly, reverse-path had some object dependencies that
> >> let both a string value, and dotted decimal value be valid
> Also:
> 4.1.3 Address Literals
>    Sometimes a host is not known to the domain name system and
>    communication (and, in particular, communication to report and repair
>    the error) is blocked.  To bypass this barrier a special literal form
>    of the address is allowed as an alternative to a domain name.  For
>    IPv4 addresses, this form uses four small decimal integers separated
>    by dots and enclosed by brackets such as [], which
>    indicates an (IPv4) Internet Address in sequence-of-octets form.  For
>    IPv6 and other forms of addressing that might eventually be
>    standardized, the form consists of a standardized "tag" that
>    identifies the address syntax, a colon, and the address itself, in a
>    format specified as part of the IPv6 standards [17].
> And this section:
>  Extended HELLO (EHLO) or HELLO (HELO)
>    These commands are used to identify the SMTP client to the SMTP
>    server.  The argument field contains the fully-qualified domain name
>    of the SMTP client if one is available.  In situations in which the
>    SMTP client system does not have a meaningful domain name (e.g., when
>    its address is dynamically allocated and no reverse mapping record is
>    available), the client SHOULD send an address literal (see section
>    4.1.3), optionally followed by information that will help to identify
>    the client system.
> >    permitted, as are CNAME RRs whose targets can be resolved, in turn,
> >    to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
> >    used.  There are two exceptions to the rule requiring FQDNs:
> >
> >    -  The domain name given in the EHLO command MUST BE either a primary

	-lava (Brian A. Seklecki - Pittsburgh, PA, USA)

    "Show me a young conservative and I'll show you someone with no heart.
    Show me an old liberal and I'll show you someone with no brains."
    ~ Winston Churchill

More information about the Linux-PowerEdge mailing list