Re: header-munging

[[e-mail]]

On 25 Sep 1996 17:42:54 -0000, you said:
> > You tell me how the SMTP server at vtbit.cc.vt.edu can
> > *reliably* tell what the domain name is,
> 
> Although this _sounds_ the same as Keith's frivolous objection, it's
> actually a completely different objection.
> 
> Keith was talking about an injection server. You're talking about an
> SMTP server.
> 
> Everyone agrees that a mailed message must conform to RFC 822. A client
> has no business sending unqualified domain names to your SMTP server.
> This, however, has no relevance to a mail-injection protocol.

Actually, I was addressing the issue of "if this is handed to me, *can* I
fix it up, even if it appears on my injection port".

I would let it pass, if the draft-gellins-submit document added the following:

A) In section 4, it states that an MTA *MUST* ensure all domain names
are fully qualified - with no mention of what to do if it is unable to
do so correctly.  Now, there is text in section 3 saying an MTA can
apply different rules based on whether it is a submission or not - but
there is no text stating *what* to do if the MTA either does not wish
to accept a SUBMIT, or if it is unable to carry out the 'MUST
qualify'.  In my case, I need to know, if vtbit.cc.vt.edu wishes to
tell the PC in Pakistan that it either won't or can't accept the SUBMIT,
what 5xx code I should send back.

B) In section 4, the item about the MTA *may* 'Refuse the MAIL FROM'
probably needs to have text added about if the MAIL FROM *looks*
valid, but the originating IP address is known to be unacceptable.

C) In section 4, there is needed some discussion regarding
what the MTA should do if it attempts a given transformation and fails.
In particular, there seems to be an implicit requirement that all the
transformations be done "on the fly". For instance, point (9) is in regards
to rewriting the RFC822 headers to hide logon names.  If the MTA is unable
to do so (invalid name, database failure, or whatever), it can either
signal back some 4xx or 5xx code after receiving the final '.' (said
code not specified) - but this requires that we can't queue the message
and process later.  Alternatively, we *could* queue the message - but
then we have no good way of signalling back a failure, as we may be unable
to figure out a good address to bounce back to (null@transport-server comes
to mind here).  The issue of background processing will be a big one for
high-volume sites - when you are in the 500K msgs/day and up range, such
considerations start becoming important...

In short, I'm not opposed to a *limited*, *restricted* 'SUBMIT' of some sort,
as long as there are *CLEAR* rules for what the MTA should do if it considers
any given submission as being "out of bounds" or unprocessable.

/Valdis