On 17/02/2012 1:11 a.m., Bron Gondwana wrote:
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.
that's what I've noticed in support.
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.
aieeee BURL...
until then, a mail server vendor had no need to write an IMAP client.
Would have been a trillion times simpler to implement submission from
IMAP. I can't even think of a mail server product with IMAP that
doesn't have SMTP already.
Did anyone actually implement this?
It seems so fraught with problems / fragile that I'd expect very few
implementations. That's even apart from the complexity.
With XSEND, you upload the message to IMAP first, then you say:
TAG XSEND UID
how do you provide the SMTP forward path? Is that scraped from the headers?
maybe should be
TAG XSEND UID (addr, addr...)
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.
sure, but if you're delivering direct to end MTA, you have pretty much
the whole path.
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.
half the problem is lack of standardisation. MDNs should be
machine-readable.
Adrien
Bron.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
