On 17/02/2012 12:29 p.m., Dan White wrote:
On 02/16/12 14:57 -0800, Brandon Long wrote:
On Thu, Feb 16, 2012 at 2:41 PM, Dan White <[email protected]> wrote:
However, spam is a problem caused by a deficiency (or whatever you
want to
call it) within the smtp protocol. imap does not directly or
indirectly lead
to the generation of spam, unless you want to consider backscatter
from a
sieve notification to be spam.
smtp (or submission) is one of those things that's actually easy to
configure in an email client. I fear that if the two get combined on
the
same port that imap server IPs may start to get caught up in the cat
and mouse game spam parsers play.
IMAP playing the game is no different than SMTP-MSA playing the game,
it still requires authentication. I'm not sure how wide-spread it is,
but we certainly already have to deal with spam through spammy
accounts or hijacked accounts over SMTP-MSA. I find it hard to
believe that IMAP doing mail submission is going to change any of
that, but perhaps you mean that you would have to have the same smarts
for protecting against bad logins in IMAP that you have in SMTP-MSA...
but I would expect anyone who's under attack for either already does
that as well (we certainly use the same auth backend for both.
Separating imap from submission allows those functions to (easily) run on
separate servers, like where the smtp server is a black box appliance,
which is not uncommon in the service provider or enterprise space.
Whichever way you do it, BURL vs SUBMIT, there is an issue of trust if
the 2 servers are in different realms.
And those issues were addressed in the BURL RFC, and the same security
conditions apply.
Notwithstanding all of that. It's still easier for a developer to hook
up a way for an IMAP server to submit mail to SMTP than it is to hook up
SMTP to retrieve IMAP.
If the servers are on the same computer, it can be as simple as a file copy.
One option would be an extension for submission that would only be
available if the SMTP server trusted the IMAP server.
That would then avoid the need to smuggle SMTP creds across your IMAP
session (c.f. the way that BURL specifies IMAP creds in BURL requests).
I think in most organisations this would prove a lot simpler to manage.
Certainly a lot simpler to code as a developer.
Maybe it should be an optional extension, usable as an alternative to BURL.
I'd still be keen on any deployment stats on BURL.
imap essentially already has its own mail submission component via imap
append. Users can trust who sends them messages, and can limit who can
send
them messages (via enforceable acls). I just wish smtp worked more like
that, but that's a pipe dream.
I don't know how you can use APPEND to send a message to another user
unless you share a folder with them.
Adrien
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
