Re: bug with the Message-ID ?

[Brian Stafford <brian stafford uklinux net>]

On Sun,  2 December 22:14 Carlos Morgado wrote:
> On Sun, Dec 02, 2001 at 09:56:08PM +0100, Jens Askengren wrote:
> > On sun, 2001-12-02 at 21:30, M. Thielker wrote:
> >
> > > > > netscape: Message-ID: <3BF223EC.F2514A11@compuserve.de>
> > > > > balsa:    Message-ID: <3BF223EC.F2514A11@Hugo.comic.net>
> >
> >
> > > The message ID is in fact generated by Compuserve not Netscape. NS will
> > > submit the message without a message ID while Balsa does generate one.
> CIS
> > > sees that as relaying and rejects the message, as far as I (also a
> > > Compuserve subscriber) know.
> > > To allow for such braindead mail servers, there really needs to be an
> > > option to generate _no_ message ID
> >
> > Why do we generate a message id when this seems to be causing trouble
> > and mailservers add it anyway?
> >
> 
> Cause mailservers aren't supposed to message-id headers.
> a little preaching here brian ? :)

How can I resist your invitation Carlos? ;)

OK, here goes!  RFC 2822 requires that all messages have a unique message 
identification.  From RFC 2822 :-

    The "Message-ID:" field provides a unique message identifier that
    refers to a particular version of a particular message.  The
    uniqueness of the message identifier is guaranteed by the host that
    generates it (see below).  This message identifier is intended to be
    machine readable and not necessarily meaningful to humans.  A message
    identifier pertains to exactly one instantiation of a particular
    message; subsequent revisions to the message each receive new message
    identifiers.

Furthermore, RFC 2821 prohibits publicly referenced MTAs from examining or 
altering a message in transit except for adding trace headers, i.e. a 
Received: header for every hop and a Return-Path: header when the message 
leaves the SMTP environment, e.g. when delivered to the recipient's mailbox.

A mail submission server as defined in RFC 2476 is allowed to add missing 
headers and change sender and recipient headers to canonical form amongst 
other things, however a publicly referenced server MUST NOT do this for 
messages transferred on port 25 - this is why the submission port is 587.  
Alternatively, for non publicly referenced MTAs, the submission service MAY be 
present on port 25.

I ran the following on compuserve.de

$dnsquery -t mx compuserve.de
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35448
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;;      compuserve.de, type = MX, class = IN
compuserve.de.          1H IN MX        10 mx.compuserve.de.
compuserve.de.          1H IN NS        arl-name-svc-1.compuserve.com.
compuserve.de.          1H IN NS        dub-name-svc-1.compuserve.com.
mx.compuserve.de.       1H IN A         62.52.27.100
arl-name-svc-1.compuserve.com.  1H IN A  149.174.211.5
dub-name-svc-1.compuserve.com.  1H IN A  149.174.213.5

$ dnsquery -t a compuserve.de
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5004
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;;      compuserve.de, type = A, class = IN
compuserve.de.          15M IN A        193.189.238.3
compuserve.de.          1H IN NS        arl-name-svc-1.compuserve.com.
compuserve.de.          1H IN NS        dub-name-svc-1.compuserve.com.
arl-name-svc-1.compuserve.com.  1H IN A  149.174.211.5
dub-name-svc-1.compuserve.com.  1H IN A  149.174.213.5

compuserve.de seems to be both publicly referenced via MX and private via A!  
(I cannot telnet to 193.189.238.3.)

Since a publicly referenced MTA may not examine the message to determine if 
the headers are "correct" - the MUA must generate the complete header set.  
Therefore Balsa is correct to do this - furthermore Balsa is *required* to do 
this if it is to be standards compliant and to be able to submit mail on a 
publicly referenced MTA.

As the A record for compuserve.de is private the RFC 2476 submission rules may 
be applied. Although it is entitled to change the message, according to RFC 
2476 :-

8.3.  Add 'Message-ID'

    The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
    it is not valid syntax (as defined by [MESSAGE-FORMAT]).

It seems to me that the non-public compuserve.de is wrong to *reject* a 
message on the basis of its message-id: header since it is only supposed to be 
a unique tag to distinguish the message from others.  More likely, rejection 
occurs because of the sender mailbox address.  Check out the identity in Balsa.

And finally, as mentioned many, many times before, build the example program 
that comes with libesmtp and try using that to submit the test message.  The 
--monitor option will trace the SMTP session which is useful to locate the 
problem.

--
Brian Stafford