🚀 go-pugleaf

In article <00932CA6.30EE8E00@vms.ecs.rpi.edu>, madison@vms.ecs.rpi.edu 
(Matt Madison) writes:
> Problem 1.  In implementing a gateway between VMS MAIL coming in over
> DECnet and SMTP, my software generates return addresses of the form
> <"node::user"@domain>.  The quotation marks are necessary because colons
> are considered "special" by RFC 822.  This immediately started to cause
> problems because (I'm told) sendmail by default strips quotation marks
> from the user portion of an address.  So when UNIX users tried to reply
> to messages sent from my system, the replies would be rejected by my
> SMTP server becuase <node::user@domain> is not valid RFC 822.

I suggest that you do what we (the DECUS uucp folks) do for our
"user base":  We have an address rewrite mechanism that, for From addresses
on outbound mail, can be set up to rewrite

	node::user

to

	user@node.rest_of_domain

eg, stuff coming from SKYVAX::user here ('here' is simpact.com) ends up
coming from user@skyvax.simpact.com.  This is in concert with most domain
naming schemes anyway, where the second-level domain ('simpact' in our 
case) specifies which company within .com, and the third-level specifies
which machine within .simpact.com .

Our rewrite rules can get fancier; for example, if there may be overlaps
between DECnet nodename space and some other internal network's namespace 
to which you must also delivery mail, you can choose to rewrite to something 
like

	user@node.decnet.simpact.com

or even 

	user%node@decnet.simpact.com

(but a lot of other mailers don't do what you want with %'s)

And, of course, for To: addresses on inbound mail, we can look for things
that match whichever of the above patterns the user wants, and rewrite
to node::user for inbound delivery.  

This works for us (simpact), even in a horribly mixed decnet/tcp-ip/uucp 
environment, and we don't even use PMDF (yet).  

> ...[descriptions of other hassles deleted]

> What really burns me up about this, is that it's considered _my_ fault that
> this stuff doesn't work!  Argh.

Being chief recipient for e-mail and phone calls regarding DECUS uucp, 
I know EXACTLY what you mean.  (And thanks to all of you who have communicated
thanks to us for the package; you are keeping us going!)  The above commentary 
is in no way meant to suggest that mailers Out There ought NOT to take 

	"anything_at_all"@domain

and pass the stuff in quotes intact.  But suggesting that they do so is
probably tilting at windmills.  

(p.s.:  DECUS uucp is uucp for VMS with full mail and netnews support.  It 
is essentially free.  Send mail to me for info.)

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh

[From RFC1123]

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:


                "Be liberal in what you accept, and
                 conservative in what you send"

UNIX doesn't let you forget that.
-- 
Eliot Lear
[lear@TURBO.BIO.NET]

Welcome to the real world of mailers! As the primary author of PMDF, a very
popular mail system for VMS machines, I've run into all the problems you
cite on numerous occasions. You've only just started -- there are lots
more waiting for you.

Now some advice. You'll never get mailers to accept "node::user"@domainhost
format. It is a hopeless task. So I'd recommend using something of the form
user%node@domainhost if possible. This even generalizes to multiple nodes
if you need them. Note that this does not solve the entire problem of
how to handle all the wierd stuff VMS MAIL likes to use, but it will get
you started at least.

The problem of mailers inserting some bogosity into the personal name
field in an address is well-known too. My advice on this one is to simply
ignore it. You should not be looking at header lines for delivery purposes
anyway. The envelope should suffice, and personal name fields are flagrantly
illegal in an envelope (PMDF accepts them but strips them for reasons that
I won't get into in this forum). You can either insert a sanitized header
line in place of the incorrect line or just pass it on unchanged and let
the next mailer downstream worry about it. If it rejects it your hands are
clean -- that's a battle between the offending mailer and the picky mailer!

A final note. All the standards say that a blank address is completely
legal in various places, e.g. an SMTP MAIL FROM: line. Watch out for those.
Several UNIX mailers (you know who you are) go into infinite loops when they
get one of these. And if you think you've had trouble with users whose mail
got lost in the past, you've got a new treat when you deal with a sysmgr
whose load average was at 50 before he wiped out all those looping mail
processes. Not a pretty sight.

Good luck on your project. I saw an announcement of your system on the
JNET-L list, I believe. Sounds good.

				Ned Freed
				ned@ymir.claremont.edu