Errors-to: owner-drums@CS.UTK.EDU
To: Keith Moore <moore@CS.UTK.EDU>
Cc: drums@CS.UTK.EDU
Subject: Re: support for Postmaster address 
In-Reply-To: Your message of "Fri, 22 Sep 1995 03:40:25 -0400."
             <199509220740.DAA17233@wilma.cs.utk.edu> 
Date: Sun, 24 Sep 1995 06:17:39 +1000
Message-Id: <19990.811887459@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Fri, 22 Sep 1995 03:40:25 -0400
    From:        Keith Moore <moore@CS.UTK.EDU>
    Message-ID:  <199509220740.DAA17233@wilma.cs.utk.edu>

    But it's not clear in the world of MX records whether the
    Postmaster address must be supported for every domain name
    that can possibly receive mail, or for every parent domain
    of a domain that can possibly receive mail.

The former, surely.   munnari.oz.au can receive mail, however
oz.au is nothing more than a zone file, sending to
postmaster@oz.au neither can, nor should, go anywhere.
    
    I'm tempted to suggest that the Postmaster address must be
    supported for 

    + any domain that appears on the right-hand side of an @ in a 
    sender address (either header or envelope), or

Yes

    + any domain which is listed as a mail exchanger for some other 
    domain, or

Perhaps - MX targets don't necessarily have any kind of UA
functionality though - there is no requirement that an MX
target be able to receive mail, just relay it to its destination.
A host running a SMTP to UUCP gateway, and nothing else at all
would be an MX target.

Another case: if you send to user@murrawan.cs.mu.oz.au your
mail will be bounced (murrawan is a terminal server, it has
no mailer, and never will, still people see people logged in from
there, and assume it must be a workstation, so send mail there...)

The bounce is done by...

	murrawan IN MX 0 mailbounce

where mailbounce.cs.mu.oz.au is a (non CNAME) alias for a
host that runs a really trivial mailer that simply bounces
everything - that is, every RCPT command elicts an error
response, whatever the address is.   A typical dialog
follows...

220 muri.cs.mu.OZ.AU waiting to bounce your mail
HELO munnari.oz.au
250 No idea why you're sending me mail, it'll bounce!
Mail From:<kre@munnari.oz.au>
250 I don't care who its from
Rcpt To:<anyone@anywhere>
550 No mail for that host name, try another
quit
221 muri.cs.mu.OZ.AU has finished trashing your mail.

Note, no examination is done of the address in the rcpt-to,
you get the same message whatever is there.   Clearly mail
to postmaster@anything won't be delivered either, and I would
hate to have to attempt to make it (where should it really go?).

    + any domain which appears in a Received header.

But this might be just too much.   Apart from anything else, lots
of places don't put legal domains in Received headers, all kinds
of crap goes there (even I do that, and I, sort of, know better).

Received headers are on our list for sometime later I believe,
we should probably not speculate now on how they will turn out.

    Also, when trying to track down a mail problem at a remote
    host, I almost invariably find that the Postmaster address
    at that host does not work

You must have bad luck, or perhaps your "does not work" is
being more general than I expect.  I get bounces for mail
to postmaster less often than you seem to imply.   That isn't
to say that anyone reads the mail (that the rfc pretends to
require, but it's not possible, rfc's can't constrain human
behaviour), or if they do, that they take much notice of the
problem, or bother to reply.   However the postmaster address
notionally works most of the time.

    So I am wondering whether we can require an MTA to test
    on startup

I doubt we can require it.  We can probably suggest it.
Not that this helps a lot, without actually sending a message
to the actual mailbox (which would become annoying quite quickly)
there's no way to know that the address really works - many of
the problems I see are "over quota" and similar stupidities, which
can't possibly be determined by a quick check that the addr is
known.   But doing the check at least avoids the trivial
problems.

    (In particular, it should know how to route mail to 
    postmaster@local.domain.name and postmaster@[my.ip.address].)

Most mailers can't handle anything@[my.ip.add.ress] - if they
can handle any (incoming) addresses of that form, then postmaster
is not likely to be a problem (that is, if postmaster@domain works).

kre