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.
Focussing on changing the mail submission aspect of the picture may
introduce unexpected side effects, such as how other providers parse and
block your messages (which some do based on client *and/or* relay IP).
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.
--
Dan White
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
