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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
