So feature complete in SMTP is a loaded term. Does that mean there won't be features that affect SMTP in the future? No (Never will reach that level of "feature complete"). I mean that we'll be able to run feasibly in a secure multi-user environment. There are presently issues that would allow authenticated users to forge other authenticated users. Not a biggy, most mail servers let you do this anyhow and the logging can still cause said person to be fired. However these will be fixed in M3. There will of course be RFCs and other things that aren't supported (S/MIME for instance).
The letter....probably not in M3. That RFC seems to talk about partial incremental mail transfers. Thats a ball of wax I don't even want to get in to yet.
The spirit, It will be possible to have this configuration in M3. We'll support the right set of features to allow you to set up a TLS/SSL on 587 and SMTP on 25. The one not allowing relaying without authentication and the other only allowing sending to local users. Of course I regard the multi-port thing as a bit silly. Require STARTTLS and authentication for relaying, no port 587 required. (I do not believe that some ports are inherently more secure than others). however you should be able to do that in the final M3.
I think you're right. It should be 995. I think it was set to 443 because no one new what port it should be. I'll fix it.
I agree with no ports being inherently "safer" than others... I myself was wary at first that this RFC was trying to implement a "security through obscurity" process. After trying to understand the practical use of running 2 SMTP servers with different functions and on different ports I came to realize that there was a real need for this measure. I know this is sort of "off-topic" for this forum, but for those that stumble onto this thread it may make sense to understand why I think that the possibility of running 2 SMTP servers was after all not a bad idea, and should definitely be available in JBoss Mail (and btw I am glad to see that it will be).
Because spammers abuse open relays, which most often are found on port 25 SMTP servers, some ISPs block out-of-network calls to this port if they don't originate from their mail servers. Now, a well configured TLS/SSL SMTP server is not an open relay, nor an easy target for abuse... regardless of what port it's on, but an ISP has no way of knowing whether this is the case or not. Blocking port 25 across the board is their only way to make sure a spammer can't use their network to abuse an open relay.
If SMTP servers found on port 587 are implemented with TLS/SSL as a standard measure (which seems to be the common practice), they will very rarely be the target of abuse (i.e. only if the security is weak, like bad passwords). Therefore servers running on these ports won't be subjected to the same blocking policies as port 25 because ISPs won't see the spammer abuse on those ports very often at all.
The ability to use port 587 is really most beneficial to roaming users and users permanently outside the network, since inside your own network your users should send mail through your server anyway. Normally if you couldn't connect to port 25 for your mail server from a remote network, you'd have the option to use that network's mail server and still send email with your regular domain's email address... however, SPF and DomainKeys are changing the rules for that in an effort to curb some forms of spam and now using your domain's mail server has become the preferred method for on and out-of network users.
Of course, if everyone implements TLS/SSL for relaying on every SMTP server out there, the problem would be solved and using port 587 would be unnecessary. The reality is that SMTP servers on port 25 are an unknown entity right now so standardizing the use of an alternate port helps migrate everyone in a way that can be easily tested by ISP's firewall rules. Ideal?... no, but it serves the right purpose.
Yeah that actually makes sense. I presently have to do ssh tunneling in most hotels.