It all started when we got a call from the customer saying that they were unable to add additional e-mail addresses to the list of blocked addresses in their shared inbox. Thinking that it had to be a mistake I took a look but they were right. Upon calling the "Tools\Block Mail from Sender"-action they would get the following message: "Limit for Blocked Addressses reached. Please delete addressses before adding more."
The message had me stumped. Why would the developers of the mail template want to limit the number of addresses an user may block? And of all things spam senders are not the thing you want to limit. Anyways I opened the mail template in Domino Designer and took a look at the source code (the customer is running a standard Notes 7 mail template).
The action calls into the BlockUserRules script library where the below snippet code is copy/pasted from. The offending line is 102 in the Declaration section (in bold):
Function run() As Integer <snip /> '// Prevent list to exceed formula total size of 32K '// Mostly because Manage List display issues. If Not ((Len(Me.m_CalJunkNames.Text)) >= 30000) Then ... End If <snip /> End Function
The reason for the message
A reference is made in the comment above the If-statement to the 32K limit we all know and love and to a display/UI issue. If those are really the reasons I'm a bit disappointed. Lets look at each stated reason in turn.
The 32K limit
As to the 32K limit there are ways around that. Especially for a functionality where there really shouldn't be an upper limit. If you are unfamiliar with how the functionality is implemented you can learn a lot by using NotesPeek and looking at the CalendarProfile profile document in a mail database with this feature enabled.
When you add addresses to the list of blocked addresses a long list is stored in a field called $Filter_BlockAddressList with summary info (hence the 32K limit) and then compiled into a @Formula mail rule (see the $FilterFormula_XX fields where XX is a zero based integer index value). The values are imploded with \xdd as separator (screenshot).
Why not simply let the list of blocked addresses overflow into multiple fields and hence mail rules. I agree that it is more complicated but wrapping this functionality in a class isn't too complicated. Another option is turning off summary information for the fields since it isn't shown in any view. There might be a technical reason for not taking the latter approach since I admit that I don't know how the router reads the mail rules and whether the summary information is required.
The display/UI issue
This is also a bit disappointing. Lotus have to admit that the UI for managing a large list of blocked addresses is hardly excellent as it is (questionable sorting, no way to search for addresses, what does @example.com mean?) but then why not do something about it instead of simply letting it dictate your functionality? None of our customers would let us get away with reasoning like that.
To sum up...
Anyways - we have a customer that unfortunately cannot use the junk mail functionality anymore as it is supplied out of the box. Either they have to pay for custom development or somehow try to cope in other ways that is move part of the list to the server.
The conclusion - they're not happy...
To not come off as totally negative I thought I would make a couple of suggestions. If nothing else to get them out there as I think it is a great place for an open source initiative.
I would think that the junk mail feature should have the following features:
- There shouldn't be a limit to the number of e-mail adresses, domains or hosts you can add to the list.
- Correct alphabetically sorting of the list of addresses.
- The list of blocked domains should be separated from the list of blocked addresses for easier management.
- Users should only be able to add valid addresses to the list.
- Users should not be able to add an e-mail address where the entire domain is already blocked.
- The possibility to search for an address or all addrsses with a particular domain name.
P.S.: Did you spot the spelling mistake in the message in the first paragraph? I doubt that addresses is spelled as shown - too many S'es... :-)