<content transferred from bug 334445> draft-gellens-submit-13, the message submission protocol, has been approved by the IESG as a Proposed Standard. Communicator should support it. Support means trying to use port 587 for submitting new messages. If a connection to port 587 cannot be made, then fall back to port 25. The rest of the protocol is the same (for now).

Setting all current Open Critical and Major to M3

qa contact to esther

Scott, here's an SMTP-ish RFE. If/when you add this, please make it configurable with a JS pref.

I don't think this needs an additional JS pref. If you specify your SMTP/submission server as "nsmail-1", then it should first try port 587. If the connection fails, then try port 25. To get the old behavior, the user would specify their SMTP/submission server as "nsmail-1:25"

That doesn't sound good. Every outgoing message has to fail one one port before trying the one which is more likely to succeed? How about if we make 587 available via a pref, and see how many people want it. If a lot of people want it, we can change the pref in 6.0. M9, which is relatively close to "later".

Why is this not good? The failover will be undetectably fast, since the connection to 587 will get a "Connection Refused". The submission protocol is going to fall flat on its face if new clients don't start using it without users going out of their way to turn it on.

This has been moved to post beta work. We've had a lot of meetings to pair down new features to a bare minimum in order to ship our beta on schedule.

Agree that this bug does not need to be fixed until after PR1.

Suggestion only: how about caching whether 587 failed for a given host, so you don't try it every time? Then it'll be amazingly fast and still not require that users go out of their way. 587 support is important for AOL members trying to connect to non-AOL SMTP hosts, since right now we redirect all port 25 connections to our own, spam- filtering SMTP server. If they need to authenticate with a non-AOL server, they can't do it right now. This would fix that without removing the anti-spam protection on port 25. (Presumably anyone running a submission server is going to be authenticating, preventing relaying, etc. since this implies a sysadmin who keeps current on things.)

How often would the information be cached? A site might add support for port 587 when they previously did not have it. I tried devising a patch for this, but got hung up on the temporary URL parsing code in the current mail submission stuff.

*sigh* Futuring....we didn't get to this before feature freeze....

is this still valid? Should summary be changed to "if connection to port 587 cannot be made, then fall back to port 25"?

The feature request is for the client to, when an SMTP server is configured without a port, first try port 587, failing over to port 25. When an SMTP server is configured with an explicit port, the client should use only that port. This results in a default behavior which gives users whose server supports the new protocol the benefits of that protocol, but doesn't break all of the users whose server does not support the new protocol. In case of strange router behavior, there would be a mechanism to force use of one port or another.

given what account manager does, is it not unlikely an account will not have a port number associated with it? (still, the summary is vague)

Nelson, does this match up with your bug 383877? If so we can dupe this to yours. If not, is "backend" the correct component for this?

The two bugs are very related, but not identical. They propose different solutions to the same problem. bug 383877 proposes to let the user easily configure port 587 (or port 25), and make 587 the default configuration. This bug proposes to implement a try-and-fall-back algorithm. With regard to the issue in comment 5 above, the obvious solution is to reconfigure the server (change the pref) to use port 25 after a failure-and-successfull-fall-back event.

With respect to comment 14: This bug was originally opened when the account manager didn't have a separate port field. I would suggest that the port field default to blank, which would trigger the 587-then-25 behavior. An alternative would have the default be "587,25". With respect to the second paragraph of comment 16, I dislike that approach as it would cause a user to suffer a strange, permanent behavior change should they encounter a temporary network failure when attempting to connect to port 587. They would also tend to get this silent reconfiguration if they are mobile and temporarily connect through a network which has outgoing port 587 firewalled off.

bienvenu, will the new autoconfig stuff tackle this issue by any chance?

no, just a one time shot...

I think that deciding (by default) which port to use (25 or 587) should be at account configuration time and not runtime (by trying). http://www.ietf.org/id/draft-daboo-srv-email-02.txt defines DNS SRV RR for email staff and I think it's best if during Thunderbird account creation servers fields to be filled using these SRV records based on (local part)@(domain) entered at start. Guidelines in the darft are worth reading. Example SRV RR for example.com zone from the draft: _submission._tcp SRV 0 1 587 mail.example.com. _imap._tcp SRV 0 1 143 imap.example.com. _imaps._tcp SRV 0 1 993 imap.example.com. _pop3._tcp SRV 0 1 110 pop3.example.com. _pop3s._tcp SRV 0 1 995 pop3.example.com. Implementing the above is very different from title of this bug, so it's natural to be new enhancement bug.

Yes with the new (Quick) Account setup, 587 is probed first. As such, i suspect this bug is WONTFIX (since it's really about run-time automatic fallback).

This is the closest to the issue I have found.. As a simple user, with a simple set up, I entered my smtp Host.. It tried to detect something, but failed.,. From that point I had to edit the details manually. I did not alter the smtp server port. It continued to not connect.. eventually I found it was the fact the port was not set to 25 even tho it does say thats the default.. My original bug was that the default should start with the default!!! having read this bug, if I understand it correctly, its something else, becaiuse its been opff trying to detect settings.. However, if it fails, it really should come back to 25 - as the majority of users aren't going to understand the port number thing, and they often just get told.. host user pass smtp none with ports.