B# .NET Blog

Hi Robin,

Thank you so much for your comments on this beta release. I'll certainly check out a lot of your suggestions, once I have recovered the source code from the backup (which I need to find first :-)).

Some first answers:

1. Bugs

* Currently it's not possible for a user to delete a connector indeed. He/she can only disable a connector.
* There is no way to specify as an admin the maximum allowed number of connectors or a notion of quota. Maybe this will be added in a further release too (maybe stored inside AD itself, but I rather don't want to do schema extensions).
* Exchange is (and will be) required. This behavior is by design although the service itself can cope with any POP3 and SMTP server. So, nowadays it's perfectly possible to specify a non-Exchange SMTP if the receiver mail address composition is <username>@<AD domain name>. As I have mentioned in the docs, the target e-mail address might be gathered from the user's e-mail address field in AD.
* The change of the delivery time/date to the time when the mail was forwarded is by design, as the SMTP protocol uses the queue time as the mail sent time, although the mail itself can contain additional fields which hold dates/times. I'll check this a little further as I'm not 100% sure about this right now.

2. Questions

* If I do understand your question correctly, the answer is that every connector opens a separate connection to the target POP3 server, even if a lot of users connect to the same server. However, the session-oriented nature of the POP3 protocol makes it nearly infeasible to have another way to retrieve mail other than having a separate connection per connector. Nevertheless, I consider to change the architecture towards a plug-in based model, so that you can developer your own mail retrieval component (e.g. IMAP4, POP3) in order to change the default behavior if you'd want to do so.

3. Missing

* Distribution groups are not known by the connector at the time speaking. The basic problem is the fact that connectors are user-based and depend on the user authentication. A general management view would solve the problem, as we can list the distribution group e-mail addresses over there and add connectors for these. Ideally, there'd be a concept of ownership for distribution groups so that we can offload the task of managing connectors for a distribution group to the owner of the distribution group.
* As you mention, the identity of a user is bound in a 1-on-1 relationship to the target mailbox. Therefore authentication is needed in order to manage the associated connectors. There is no such thing as a "god connectors administrator" for the moment. However, you can go to the SQL Server database and add/remove connectors over there, but you'll have to trick the encrypted password by entering that password through the administration website and copying it to the field of the newly added connector in its encrypted format.
* Multiple delivery domains are not supported nowadays, but this can be solved in a future release by using the e-mail address field in AD. Further brainstorming has to be done.
* Admin connectors would be a possiblity too. I have to consider this, based on security requirements etc.

4. Suggestions

* Using the Exchange OWA login methodology has to be investigated.
* Authentication for the SMTP server has to be checked in the RFC, because the implementation of the SMTP client in the software is completely self-written based on the SMTP server RFC document and the authentication portion was not implemented yet.
* Scheduling on a per-connector basis would be great but will complicate the service code significantly. I have to think about this too, but I'm seriously considering to implement this.

5. Architecture

* Some threading optimizations have to be considered too.


Once I have an updated version (can take a while) I'll post it on my blog and let you know about it.


Kind regards,

Bart De Smet