Hi Lyndon,
Let me rephrase that. I know (hope?) we aren't ditching 7but support.
My point is that 7bit and friends will be here almost forever, so
there is no purpose to be served in arguing about supporting them.
Sure there is. The number of 7-bit MTAs is tiny and becoming ever
smaller. Perhaps because they're likely to be full of security holes
too. With nmh's limited resources (Hi Ken!) it could be beneficial to
not waste time supporting them when we could get something more
beneficial to nmh's users instead.
We have to support it, fini.
AFAICS, if nmh wanted 8BITMIME on the MTA it directly talks to and
didn't find it, giving up with a very clear error, then that's
RFC-compliant and just makes the user get a decent MTA to talk to. If,
by some tiny chance, it's a 7-bit corporate MTA over which he has no
control then he needs to add a more local 8-bit MTA that'll downgrade
the comms to 7-bit when it simply forwards it onto the old one.
By clear error I'd suggest referencing the paragraph in the RFC where
giving up is allowed and perhaps a link to this thread on the mailing
list archive. :-)
As a half-way step to coping with a 7-bit MTA peer, how hard would it be
to scan the DATA ahead of HELO/EHLO for top-bits and only insist on
8BITMIME if they're set. Then the user can cope with a 7-bit MTA peer
by not sending 8-bit DATA?
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers