Author: Exim Users Date: To: .|MoNK|Cucumber ., exim-users CC: Subject: Re: FW: Re: [exim] Easy Disclaimers with Exim?
".|MoNK|Cucumber ." wrote: >
> The lot of you that choose to argue and insult those that wish to use
> appended disclaimers/footers are merely wasting peoples time.
> The fact of the matter is that companies do use disclaimers/footers, and
> it was a simple question regarding if it was possible with Exim.
> The thread is not a debate on whether or not to use them, just a how-to
> question.
The point that you and many others have missed is that it is not an MTA's
job to modify a messages content, that is the job of the MUA. Only an
MUA can properly (or improperly) create the content of the message,
especially when proper (proper in this case being the sender has thier
own key to sign with, and a global site key is not used) encryption
techniques are used.
Now, for those that like to nit-pick, yes, an MTA can at times be used for
more than just the transfering of messages as the MTA has recieved them,
but nearly (not including any message headers that get added for different
reasons) all of those cases are explicitely designed to enusre that a
message is compatable for the public SMTP infrastucture, and even at that,
the portion of the MTA, or any other 'agent' in between, is not really
acting as an MTA, but at that moment, it is working as a bridge-head to
different messageing topologies.
This is how nearly all 'group-ware' products such as MS exchnage, Lotus
Notes, Novell Groupwise, etc. work. They are not MTA only products.
Exim (for nearly all installations) is just an MTA, it can be used as an
MUA transport to interject email to an MTA, but then again, Exim has
special settings and restrictions that can and should be used for this
purpose.
What you have been getting upset about is you want people to show you
what many have already said is possible, to add a footer/disclaimer, to
a message when Exim is running the message through its routers or
transports, this is not a trivial task, there is no 'easy' way to do this.
Even when it comes to any product that you may want to say does this, it
may be an 'easy' task for you to configure, but inside the program, it is
not an easy task.
As to your wanting to have a specific 'font' for the disclaimer, you seem
to have completely missed the point. SMTP message are ASCII TEXT BASED.
There is no particular 'font' that you can force any recipient of a message
to use. That is what MIME parts with HTML, or RichText are for, but now,
you get into even more complications as you are going to have to
encapsulate a message in MIME when it never had any MIME parts at all, or
add a MIME part to a message that is possibly already very complex in its
MIME structure. Not impossible, but not easy.
Also, doing such things at the transport level rather than the client MUA
level, you must consider what you are going to do with digitally signed
messages. Are you going to force them to be unpacked and then resigned?
Are you going to try and encapsulate the entire signed message within
another message that may or may not be signed? There are other
considerations, but this should be a start.
Whether disclaimers should or should not be used, or to how much legal
gain or loss there may be is rather irrelavent I do agree. The fact of
the matter is that there is no case law that I am currently aware of that
has ever given such things any real sense of being usefull. As long as
you are broadcasting the message content in a non-encrypted form, which
is how the message is going to be sent unless it has been encrypted
directly after creation, then anyone who has a basic network sniffer can
grab the information (legal issues may apply there as to being 'authorized'
or not) but as a point, the message can be posted, or reposted by anyone.
Disclaimers are no more a legal protection for anyone than it would be
in giving a Terms of Service, or EULA AFTER a product has been installed
rather than before it has been installed.
