Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"bob@camb.com"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 10 Oct 92 00:46:40 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Handling broken From:-addrs with PMDF-MR
Newsgroups: bit.listserv.pmdf-l

> It appears that the way I have configured PMDF-MR it bounces messages which
> arrive from the Internet with invalid From:-headers (at least those ones
> with syntax errors, given the attached example).

PMDF-MR does not care if the From: header does not convert. It will ignore any
error produced and generate no header From: information in the Message Router
message header. The original RFC822 header, bogons and all, will be left in the
header attachment so no information is lost.

Header From: information isn't required by Message Router so there is no
problem omitting it.

The envelope address is somewhat different. It is a mandatory element according
to Message Router. So PMDF-MR does the following:

(1) It tries to parse and convert the address.
(2) If (1) fails it uses whatever default address is specified in your
    TO_MR.TXT file (usually the postmaster's address) and adds a note to
    the message saying that a substitution was done.
(3) The result of (1) or (2) is converted to MR formats and checked. If this
    conversion or check fails the message fails.

The error you're getting

  WESTS@a1.decus.org: cannot convert originator address:
        <AVLAB::MRGATE::"AM::westms"%avlab.dnet@aaunix.aa.wpafb.af.mil>
        - mandatory USERID field was not produced

indicates that the check in (3) is failing. This means that either (1) or (2)
is working but is producing a bogus address that will cause Message Router
failures. (We do the check because Message Router doesn't.)

You can track this down in more detail by turning on slave_debug on the
channel.

> Is this something that's hardwired into PMDF-MR, or is it something that I
> control with configuration options?  [I didn't attach my to_mr.txt file, but
> could send it to you if it turns out I broke something there.]

It isn't configurable. It makes no sense for it to be configurable.

> I can see a number of possible courses of action when msgs are received with
> invalid From-addrs:

> 1. Bounce the message.  [I guess this sounds like the safest, but it seems
>    violate the ``be liberal in what you accept'' philosophy.]

PMDF-MR does not do this.

> 2. Pass the message, mapping the From:-addr to something that will reverse
>    map back (when a REPLY is done) to the same (invalid) address.

Cannot be done. Message Router limitations prevent this from being possible.

> 3. Pass the message, translating the From:-addr into one that is
>    syntactically correct, but (admittedly) has little chance of being
>   a symantic equivalent, with a warning msg (of course) that this has
>   happened.  [This seems like a very bad idea to me.]

This is part of what PMDF-MR does.

> 4. Send the message on as an `enclosure' in a msg from the postmaster,
>    with a note of what the problem was.  [This is what I'd do manually
>    today, if I had the time...]

This is also part of what PMDF-MR does.

> If I had all the above choices available, I think I'd choose 2.

PMDF does this but it isn't possible when dealing with a system that fails when
it encouters bogus addresses.

I note in passing that most other gateways will reject this sort of address and
drop the message summarily on the floor. The offending site has to fix the
problem if they expect to interoperate with practically any software besides
PMDF and PMDF-MR.

                                        Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU