On Fri, Feb 17, 2012, at 12:40 AM, Adrien de Croy wrote: > On 17/02/2012 12:22 a.m., Dave Cridland wrote: > > Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to > > do with it? > > back to my point about getting everything over 1 port. If we had that, > then blocking 25 wouldn't have affected me.
If you were using port 587, it wouldn't have affected you - that's been standardised for a while. The more important thing is - if we were going over one port, it would have either not affected you, or TOTALLY affected you - with nothing working. Either of those is significantly more understandable to the "punter" than some things working, and others not. The same with "Send succeeds, but then append-to-Sent-folder fails" if your IMAP connection is unavailable but your SMTP server isn't. Or if you're over quota. BURL at least solves the second one, but it solves it in a half arsed way that the little XSEND I put together last week doesn't. With XSEND, you upload the message to IMAP first, then you say: TAG XSEND UID Which sends the message UNLESS it has the \XSent flag already. And it sets the \XSent flag as soon as the message is sent. No waiting on network IO. So the only gap is a failure within the server itself. If the client disconnects and tries again, the flag will already be set, and it will not duplicate the message. No partial failures. No multiple systems depending on each other to be up, configured correctly, routing to each other. (Implementation in this case is "Call sendmail -bmi and pipe the spool file to it") > > What we need to do is identify the core problems to be solved, instead > > of finding solutions and trying to figure out how to use them. > > * SPAM There's a checklist for why this one won't be solved. > * UDNs In the case of wingate, because of the embedded SMTP server, you could theoretically hold the client waiting until you had tried one outbound SMTP. Only fixes the first hop of course. A "ocean boiling" solution to this would involve server level magic on control messages. You'd want forgery protection though... gets trickier when you consider active attacks. Mind you, MDN is already fraught with active attacks. Bron. -- Bron Gondwana [email protected] _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
