Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Thu 26 Mar 2020

Nitty-gritty details: Salesforce data to Notes example



Wed 25 Mar 2020

From REST to Notes db in two seconds



Thu 19 Mar 2020

Mind the Gap - A mid-level development manifesto


April, 2020
SMTWTFS
   01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Search the weblog





























Genii Weblog

Disclaimers

Mon 7 Jun 2004, 10:50 PM



by Ben Langhinrichs
No, I'm not talking more about Non-disclaiming disclaimers again, nor am I talking about silly disclaimers such as those found here
This e-mail and any files transmitted with it are confidential and intended solely for the use of the named recipients only. If you have received this e-mail in error do not open or copy it but return it to us. We cannot accept liability for any loss or damage sustained as a result of software viruses.
Sure would like to know how you read the disclaimer without opening that one.

No, I am talking about the erudite, polished and eminently legalistic disclaimers which people in corporations often want to add to their e-mails.  And don't tell me to "get Notes 6", because many of the issues people have with disclaimers are every bit as present in Notes 6 or 6.5 as they are in R5 or R4.

So, what are the requirements people have that make this so difficult.  I am not an expert, but I have done a bit of research, and here are some of the more obvious issues, expressed in quotes from the Notes 6 Gold forum and Notes 4&5 Gold forum:
I'm trying to append customised (per person) signatures containing our company logo to outgoing e-mails.
We would like Bob to have the option to choose which email address he sends out with and to attach a different disclaimer depending on the email domain/company chosen.
Is there a way to add a disclaimer to all email, internal Notes mail and external SMTP mail.
I have modified the mail router box design notes, to, include an email disclaimer, but if the email goes back and forth, the disclaimer will continue to append at the bottom, end result being, 4 disclaimers all at the bottom of the email. There is the signature field, but I would rather stay away from appending a disclaimer to each users preferences, where they can undo, change, etc. 
Has anyone solved the issue of adding disclaimers to mail messages when the users are sending external messages in mime format? The disclaimers work fine with Notes Rich Text, unfortunately 70% of my population is using MIME with HTML signatures.
Hi, this article was very interesting for me - what I'm looking for is to add a kind of business card below the body text (same thing you did with the disclaimer) where the infomation like telephone number etc. comes from the NAB using dblookup.

And to counter any suggestion that these are old or stale questions, you don't have to look back further than this afternoon to get: 
Is there any way wherein SMTP can be configured to sent disclaimers and avoid sending disclaimers for mails specific to some mail-in/id?
 
So, what are some of the universal themes and requirements expressed here?
  • Customize for different groups - It should be possible to have different disclaimers for different groups, and perhaps even for the same person when acting as part of different groups of roles.
  • Logos and graphics desired - It should be possible to place a logo or graphic inside the disclaimer text, which there must be either rich text or HTML.
  • Appear before reply history - It should be possible to place the disclaimer at the bottom of the current message, but before all the replied to history.
  • Control over internal and/or external addresses - It should be possible to declare that disclaimers will only go to external addresses, or only to internal addresses, or to both, or even different disclaimers to internal and external addresses.
  • Should work with rich text or SMTP (MIME) messages - It should be possible to define a disclaimer which can be added to any message, whether it is in rich text format or MIME format, without losing the format.
  • Variable content inside disclaimer - It should be possible to define a variable, such as $(Name) or $(PhoneNumber), which is instantiated based on the person's person record.
  • Single disclaimer per message - It should be possible to check the existing message to make sure the disclaimer is not already there, and avoid repeated disclaimers.  It should also be possible to check that the repeated disclaimer is not buried inside a reply to history before determining whether to add it again.
  • No mailbox changes - It should be possible to add disclaimers without modifying the mailbox template.
  • Not modifiable by end users - It should be possible to enforce disclaimer placement without allowing manipulation by end users (e.g., signatures can be altered).

OK, that is a pretty long list.  What if you could get a product like that?  Would you be interested?  What if you could participate in a beta for a product like that?  Would you be interested in that?  Send an e-mail to .

Copyright 2004 Genii Software Ltd.

What has been said:


167.1. Oliver Regelmann
(06/08/2004 11:50 AM)

HTML mails are evil. The idea of including logos and graphics automatically comes directly from hell. ;-)


167.2. Oliver Regelmann
(06/08/2004 11:57 AM)

Two additional requirements/ideas from me: No mail ntf design changes needed. And interoperability with any virus scanner/mail tool using Extension Manager. Then this could be a great product.


167.3. Ben Langhinrichs
(06/08/2004 11:59 AM)

C'mon, Oliver, tell us how you really feel. Don't hold back.

Seriously, HTML mail is not evil, just the way rich text mail in Notes is not evil, and the way color photographs are not evil, and even velvet paintings of the Seine are not evil. Tacky perhaps, but not evil.

HTML mail is simply a rich way of showing content, just the way HTML web pages are a richer way of showing content than plain text pages. What is evil is the use of SPAM to destroy much of the potential benefit of HTML email, but that should not be enough reason to avoid it entirely. People should be able to send HTML mail, and better and better SPAM filters are making it more possible. This does not mean every memo should be 600KB with embedded graphics, but there is no more reason to ban HTML newsletters, for example, then HTML web pages.

Aside from that, most people are sending HTML e-mails, whether they are aware of it or not. Whether from Notes or Outlook or Yahoo or gMail, most email is HTML/MIME based, and the real issue is how complex it is. If somebody wants their disclaimer to have a small, tasteful graphic logo, they should be able to, in my opinion.

Oh, and as to your second post, I think I already mentioned that it should (would) not require any mail NTF changes, and of course it should (would) interact nicely with anti-virus scanners. Interested?


167.4. Oliver Regelmann
(06/08/2004 02:20 PM)

OK, perhaps we could agree to: HTML mails aren't evil inherently. But the way they're used is in 95% evil, unnecessary and sometimes rude.

There are some occasions where I like e.g. to add an underline to a word or make it bold. But that's very rare.

One of the reasons why I (really) don't like them are clients that can't display HTML. And those are not only any text based linux clients for geeks. I also count Notes as one. It's rendering engine is too bad and I often get newsletters which are displayed completely broken in Notes.

And admins asking for the ability to add a logo into a mail disclaimer surely often wonder the other day, why the mailboxes of their users are hitting the quota limits...

And to the second post: Maybe I misunderstood your "mailbox template" as the design of mail.box (which AFAIR is a way to implement disclaimers).

There are products for disclaimers in the market. But afai know them they aren't able to do all the things you listed above. Might I suggest to not only provide predefined variables for the dynamic content but to make it programmable via @functions?

I'm personally interested, indeed. But I can't promise to be able to do a real extensive beta test.