Common Email Addressing Errors

Following is a potpourri of common errors we see in ZMailer smtpserver's logs. We are trying also to explain them a bit.

Samples carry SMTP-server log fragments, and the first character on each line describes what kind of event this is:

1. r Something which the smtpserver received from the client
2. w Something what the smtpserver wrote to the client
3. # Smtpserver's processing comments, not shown to the user.

In case of errors the client systems may show to the user the diagnostic messages that the server issues. If user sees such messages, it can be in form of:

450-Mumblemumbe...
450 More mumbe

 Mumblemumbe...
 More mumbe

1: Address syntax errors

• ``Incomplete addresses''

  r  MAIL FROM:<unknown>
  w  501-5.5.2         ^
  w  501 5.5.2 Path data: Missing "@" from mailbox definition
  ...
  r  RCPT TO:<cad>
  w  501-5.5.2   ^
  w  501 5.5.2 Path data: Missing "@" from mailbox definition
  ...
  r  RCPT TO: <User Name>
  w  501-5.5.2      ^
  w  501 5.5.2 Path data: Missing "@" from mailbox definition
        (This one is missing a dot in between name components,
         and the domain name.)
  

  The address entered to the system is not complete. This system is configured so that it demands getting addresses which have also attached domain name. (Domain name means here mandatory inclusion of "@" character, and a certain way formatted text on the right side of it.)

  The demand for domain-name is because while unqualified username might have meaning within one machine, we have multiple systems, along with virtual hosting, etc. We can have

  A few other examples of invalid addresses:

  r  RCPT TO:<www.something.com/foo/bar/index.htm>
  

  Well, this is email, and not WEB!

  r  RCPT TO:<@our-client.com>
  

  This one is missing username; it has only the ``@'', and domain name..

• ``Syntactically invalid addresses'' This is a large category of possible errors.

  r  RCPT TO:<radionova@.fi>
  w  501-5.5.2           ^
  w  501 5.5.2 Path data: Should this be of <dotnum> format ? ( [nn.nn.nn.nn] )
  

  The address syntax is wrong; the part: ``@.fi'' is not correct.
  (Dots appear only in between alphanumeric character sequences, never leading or trailing such sequences!)

  r  RCPT TO: <user.name.@client.domain>
  w  501-5.5.2            ^
  w  501 5.5.2 Path data: Expected an rfc821_string
  

  The address syntax is wrong; there is extra dot in between user.name, and @.
  (Dots appear only in between alphanumeric character sequences, never leading or trailing such sequences!)

  r  RCPT TO:<Trainerakademie Köln@T-online.de>
  w  500-5.5.2                 ^
  w  500 5.5.2 Illegal input characters: 8-bit char on SMTP input
  

  Here are actually TWO problems:
  1. 8-bit characters on address -- always a NO-NO!
  2. Unquoted white-space in the address -- also always a NO-NO!

2: Anti-relay policy violation

The anti-relay policy violation means complex set of rules which are aimed at stopping serious server abuse by people who think they are entitled to send junk (also known as SPAM) to third parties through our servers, even though they are not our customers.

• Third-party trying to relay through our servers

  #  connection from mail.spammer.com ipcnt 1 ident: IDENT-NOT-QUERIED
  w  220 smtp.inet.fi ZMailer Server 2.99.50-SONERA-V1.1 #5 ESMTP ready ...
  r  HELO 
  w  250 smtp.inet.fi expected "HELO mail.spammer.com"
  r  MAIL FROM: <user.name@spammer.com>
  w  250 2.1.0 Sender syntax Ok
  r  RCPT TO: <user.name@elsewere.com>
  w  553-5.7.1 This target address is not our MX service
  w  553-5.7.1 client, nor you are connecting from address
  w  553-5.7.1 that is allowed to openly use us to relay
  w  553-5.7.1 to any arbitary address thru us.
  w  553 5.7.1 We don't accept this recipient.
  

  Ok, this is fairly obvious case. That third party (*.spammer.com) has no business to use our servers to distribute their messages around.

• Our clients using competitor's dialin series

  #  connection from dial1234.competitor.net ipcnt 1 ident: IDENT-NOT-QUERIED
  w  220 smtp.inet.fi ZMailer Server 2.99.50-SONERA-V1.1 #5 ESMTP ready ...
  r  HELO 
  w  250 smtp.inet.fi expected "HELO dial1234.competitor.net"
  r  MAIL FROM: <user.name@our-client.com>
  w  250 2.1.0 Sender syntax Ok
  r  RCPT TO: <user.name@our-client.com>
  w  553-5.7.1 This target address is not our MX service
  w  553-5.7.1 client, nor you are connecting from address
  w  553-5.7.1 that is allowed to openly use us to relay
  w  553-5.7.1 to any arbitary address thru us.
  w  553 5.7.1 We don't accept this recipient.
  

  This looks exactly alike the third-party relaying blocked above. In fact we have no technical way of knowing, which really is the case.

  Had the client contacted our dialin series, or been using networks which are known to be our clients, the message would have been successfully relayed.

  This is especially a problem for people who are using Internet Roaming (like GRIC system), where the users dials to the nearest ISP providing dialin services to the Internet, however the system does not (yet, mid-june, 1998) supply outgoing email server information per ISP.

3: SMTP protocol errors

• ``DATA-dot-algorithm error''

  These are client software errors:

  r  MAIL FROM:<somebody@somewhere>
  w  250 2.1.0 Sender syntax Ok
  r  RCPT TO:<otherbody@elsewere>
  w  250 2.1.5 Recipient address syntax Ok
  r  DATA
  w  354 Start mail input; end with <CRLF>.<CRLF>
  w  250 2.6.0 S.pRugw17588 message accepted
  #  S.pRugw17588: 664 bytes
  #  -- pipeline input exists 993 bytes
  r  
  w  550 5.5.2 Unknown command ''
  #  -- pipeline input exists 991 bytes
  r  ----------
  w  550 5.5.2 Unknown command '----------'
  #  -- pipeline input exists 979 bytes
  r  more text...
  

  In this case the sending system is possibly not doing DATA-phase encoding correctly, and sometimes a lone dot (.) gets into begining of a line (is immediately preceeded with CRLF character pair), and is immediately followed by CRLF character pair.