Quoting Charles Marcus <[EMAIL PROTECTED]>: > On 2/21/2008, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: >> What got me going is that ASSP is basically useless to me, as I >> require the remote users to use SSL or TLS before authenticating. > > Ok... but what is the problem? > > Personally, I would love to see native TLS/SSL support in ASSP, but it > isn't really necessary if you have your mail flow properly set up... > > http://www.asspsmtp.org/wiki/Mail_flow_example_-_collaborative_MTA > > Your remote users should NOT be connecting through ASSP, they should be > authenticating direct with your MTA (I use postfix) - and your MTA > *should* have proper TLS/SSL support - if it doesn't find another MTA.
It does and they do and it works like a charm. Currently, I'm just playing with this: ASSP on port 25, forwarding to a postfix smtpd instance somewhere. postfix on port 465, forwarding to ASSP on port 25 (some clients require it) postfix on port 587, forwarding to ASSP on port 25. The problem is that I have no clue who is the client that submitted mail over port 465. On port 587, I require TLS and authentication before receiving a message, and the mail is most certainly from a local user. I have no such knowledge about mail that is coming in over port 465, and I don't think I can require authentication there, can I? I could drop it altogether, but I don't think my users would appreciate it. With XCLIENT I can really see where the connection is from, what HELO/EHLO the client used etc. I still don't know whether they authenticated or not, but that's a minor annoyance and I'm sure I could solve it somehow. Anyway, I think such a setup (frontend smtp server -> ASSP -> backend) is the right thing to do anyway, the incompatibility with TLS was just what got me going implementing this. When I put my setup in production, it's going to be only postfix listening on outside interfaces. It's more lightweight and can throw away lots of connections before they even come to ASSP. And if ASSP rejects mail, it's still going to be rejected at SMTP level (that's what pre-que ue filter in Postfix is about). XCLIENT is necessary in this case for ASSP to have the real information on the client - the conection comes from 127.0.0.1 and that would kill all RBLs and everything that is keyed on client's IP address. I think, at least in my case, that implementing XCLIENT is the sensible approach - as I see Mr. Macpherson does not agree and I would be most delighted if they would explain their stance in a few more words. I'm a newcomer to ASSP and all I could find about XCLIENT is here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06863.html. Almost a year ago and nothing happened? Am I the only one to find this approach less troublesome than exposing a large piece of unknown code (to me at least) to the Internet? To cut a long story short - I've done it, it seems to work and should have no adverse effects on those not using it. I'll clean it up a little and post a patch here. regards, Borut Mrak. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
