>i've just build/installed latest git. now that post defaults to port >587, i'm wondering how to configure the port number back to 25. i've >found the -port option to send and post, but no mention of a means >to configure this in mts.conf.
Well, I guess our thinking was you could always configure this in your .mh_profile, e.g.: send: -port 25 We've been getting away with putting stuff in mts.conf ... and I'll be honest, the idea of writing more code to parse entries in mts.conf really does not appeal to me. >the error, when attempting to send a message, is: > > post: problem initializing server; [BHST] no servers available > send: message not delivered to anyone > >which isn't particularly indicative that it's actually the default >port that's changed. If you add -snoop, the errors become more verbose: What now? send -server localhost -snoop Trying to connect to "localhost" ... Connecting to ::1:587... Connection failed: Connection refused Connecting to 127.0.0.1:587... Connection failed: Connection refused Connecting to fe80::1%lo0:587... Connection failed: Connection refused post: problem initializing server; [BHST] no servers available send: message not delivered to anyone In true nmh fashion, this was also the subject of a discussion here: http://lists.nongnu.org/archive/html/nmh-workers/2009-01/msg00009.html >if adding a port specifier (does it need to be per-server?) to >mts.conf is too hard, perhaps the "mts" parameter should gain a new >"submission" alternative, which would always imply port 587. "smtp" >would continue to imply port 25. My thinking is that if we're going to go that route, we really should simply make the port number be configurable; we had a user who wanted to speak SMTP on port 80 (yeah, I thought it was strange). >(i've configured my local postfix listen on 587, so things are >working, but it seems there's a documentation (or functionality) piece >missing in MH.) The problem is that there are more and more knobs you can adjust when it comes to message submission (c.f. SASL, TLS, authentication, etc etc). I don't think it makes sense to put those all in mts.conf. Once you've come to that realization then it's not very far to get to the point of not adding any new features to mts.conf and stick with .mh_profile customization for the vast majority of things. This was sort-of hashed out this July: http://lists.nongnu.org/archive/html/nmh-workers/2014-07/msg00000.html --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers