From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Sat, 6 Dec 2014 11:09:51 +0200 From: lucio@proxima.alt.za In-Reply-To: <20141205222130.4EAF6B827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9 Atom - installation troubles Topicbox-Message-UUID: 347c5270-ead9-11e9-9d60-3106f5b1d025 > I can't be certain but looks like proxima.alt.za delegates > actual email delivery to turo-smtp.net. There's a transparent proxy just the other side of my long-distance wi-fi link, I'm not sure why my ISP feels they have to pay a third party to interfere with email, but I think there may be a national intelligence issue involved: our government has mooted digital communication interception regulations for a while, but I haven't followed the details. I know whom to ask, though. In the meantime, I note that the transparent interception does not apply to the "submission" TCP port, port 587, so I think I'll hack smtp to use that instead. Right now, I'm going to build a copy of smtp with a modified mxdial.c, but I wonder what a consensus here would be: an option to smpt that invokes a "submit" function that only differs from mxdial() in the use of the service argument, or a generic port number on smtp's command line with a more complex, but now common to both options, mxdial()? Or maybe, as I'm doing now, a distinct "submit" command instead of "smtp"? Lucio. ------------------------------------------------------------------------------------- This email has been scanned by the MxScan Email Security System. -------------------------------------------------------------------------------------