[Dovecot] SMTP Submission/Proxy server - WAS Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.

[Charles Marcus]

On 2013-05-10 10:37 AM, Stephan Bosch <stephan at rename-it.nl> wrote:
> On 5/10/2013 4:02 PM, Charles Marcus wrote:
>> On 2013-05-09 5:23 PM, Stephan Bosch <stephan at rename-it.nl> wrote:
>>> First of all, it provides a convenient way to add SMTP AUTH support 
>>> to any MTA.
>>
>> Just to make sure I understand this correctly, basically, this means 
>> that if someone needs to provide SASL *client* capability on a 
>> postfix+dovecot system - ie, so that postfix can relay certain emails 
>> to certain destinations through an alternate relay server that 
>> requires SASL based SMTP AUTH - they would no longer need cyrus-sasl 
>> to accomplish this?
>
> Ehhh.. no :) It implements the server-side SMTP AUTH, so that your MTA 
> doesn't have to any more. So the client will authenticate to Dovecot 
> rather than to the regular MTA/MSA. But, again, this is a rather 
> trivial matter and not the main reason for building this proxy.

Ok... so, will this make it easier to add client side sasl support to 
dovecots dovecot-sasl implementation to eliminate the need for 
postfix+dovecot systems to continue to rely on cyrus-sasl for MTA client 
side sasl support?

>>> The LEMONADE profile is rather elaborate and not many clients or 
>>> servers support it yet. I'm hoping that by providing a chicken, more 
>>> eggs will follow soon.
>>
>> I like that dovecot is willing to take a chance on being first to 
>> support these kinds of enhanced services, but I will say, it is very 
>> important that any support for said enhancements be rock-solid.
>
> What do you mean exactly?

Sorry - was referring mainly to my later comments about how to implement 
the Save-To-Sent folder stuff...

>> Would there be some reasonably reliable way to detect when an MUA is 
>> uploading/saving messages to the Sent folder,
>
> Hmm, not sure. Do MUAs normally generate the Message-ID header, or is 
> that created by the server? That could be one way to detect the 
> duplicates in the Sent folder.

Sorry, I have no idea... but...

Maybe this feature could simply require the use of the dovecot 
submission server, so all you'd have to do is figure out how to best let 
the submission server handle it. Maybe have it add a custom ID header 
that is later removed? Or maybe even not removed?

>> and if so, could the LEMONADE protocol be leveraged to create/send a 
>> 'notification' email to that user based on some kind of system 
>> template (hard coded? customizable?), informing them that there is no 
>> need to do this, and even including a link to a dovecot wiki page 
>> explaining how to disable the 'Save copy to Sent folder' feature in 
>> common MUAs?
>>
>> Then it would be up to individual SysAdmins to keep the wiki updated 
>> with sections for any clients they become aware of that aren't 
>> already on the page.
>>
>> Maybe future enhancements could even (try to) detect the MUA client 
>> (is this possible to do reliably?), and a direct link to the section 
>> of the wiki for that specific client could be provided?
>
> Relying on user action doesn't sound like a very appealing solution to 
> me. :)

Nor me, but the fact is, since MUAs are configured by end users, and 
there is no way dovecot can change an MUAs account settings (to disable 
Save-To-Sent), what choice do we have?

That is why I suggested some way to automatically inform users about this.

Another (maybe better) option would be the SysAdmin could define a 
specific email address to handle these notifications, and it would be on 
them to get their users' MUAs configured correctly.

I'd still like to see the option to inform users directly though - 
again, if this is even possible.

>> Another thing that I know that google is really good at is 
>> automatically filtering (I guess they're deleting?) any and all 
>> duplicate emails. I have noticed this when copying a message store 
>> from one IMAP server to a gmail account. I had cases where the number 
>> of messages in certain folders wasn't the same, and upon 
>> investigation, noticed that the original/source in fact had some 
>> duplicate messages in certain folders.
>
> That is entirely possible.
>
>> So, maybe you could 'kill two birds with one stone' so to speak. and 
>> whatever is done to address the duplicate Sent messages could also be 
>> leveraged to address duplicate messages in general? Although I guess 
>> it is not the same problem, so maybe not...
>
> You mean something like this?
>
> http://hg.rename-it.nl/dovecot-2.2-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt

Lol! I see you're way ahead of me... ;)

Thanks again Stephan.

-- 

Best regards,

Charles