Re: [exim] Delting HTML attachments

Hello,

> Shudder. This and similar questions, eg how to automatically add
> disclaimers, come up at infrequent intervals.
>
> It isn't exim's job to do this. Exim is an MTA. Exim's job is
> deliver all the (crap) email in all its glory and help convince
> the humanoid reading the email that evolution has started going
> backwards :-)

Erm, no. Exim's job, as MTA, is to do whatever is needed to do with the
message. Exim does not dictate users' needs and various aspects of good
message handling. Users' needs and various aspects such as usability,
utility, security, etc. dictate what MTA should do.

I'm not even sure where this sort of bad philosophy in vein "you should
not want to do that" comes from, because in architectural terms, a
messaging server is precisely the right place to mess with the message:
you can't rely on clients to do heavy lifting (if only for potential
lack of resources), you can't rely on them to "tell the truth" (e.g. re
if the message were actually read), you can't rely on them to do
security scanning, you can't rely on them to properly process the
messages, and last but not least you can't rely on them re doing
anything more advanced than probably, maybe, displaying a message in
some broken way.

One could just as well argue that for some unclear reason in vein of "we
have always done it this way so we should continue forever even though
the technical justification is thin rationalization of the past at
best", like "an MTA should deliver message with viruses right to user's
mailbox and it's the email client's job only to do virus scanning,
because after all centralized security is not the job of the central
MTA, its job is to deliver all the (infected) email right to user's
emailbox and beat the crap out of him if he does not have good
antivirus, tee hee".

It's precisely backwards of course: not having centralized security is
just as silly as not centralizing other aspects of message handling. For
instance, meetings, calendars, business card exchange, online presence
signaling, fast & reliable delivery confirmation, reliable reading
confirmation etc: till this day we do not have such *workable* features
in email operating reliably because it varies from MUA to MUA so much
that it can't be relied upon, and since servers do not implement them,
read: enforce them in standardized ways, nobody does.

In snail mail post office you can get 100% certain confirmation that
your mail has been delivered to destination, and it's been done even
though operating cost of such a procedure is much higher and handling it
is much more cumbersome than it would be on the net. In email you can't
get that, even though costs of implementing it would be trivial compared
to physical post office.

Not handling such issues in servers -- centralized message handling
place -- is precisely violation of DRY principle: do not repeat
yourself. (yes it comes from programming but it applies equally here).
Repeating such logic in every MUA is unreliable and wasteful, and so it
should be done server-side, not agent-side. MUAs as they are implemented
today are fat clients, and that's a bad thing, not good one.

I wonder how far the web would go if web's server side refused to handle
content: data, security, app state, business logic, etc. After all,
along such line of thinking it's fat client web browser's job to handle
it all, all the infrastructure on server side of web is only there to
throw big bags of bytes around from one end to another end, and browsers
were expected to do everything with the data they get, from SQL querying
to business logic to security to formatting and displaying.
Architecture-wise, web browsers are thin clients, and were it not for
that, web would not get far -- HTML and Javascript compatibility across
browsers is hard enough as it is, and were it any harder, getting
anything advanced logic working on the web (FB, twitter, google) would
be simply uneconomic and web would be simply stale and would not develop
further, just like email is essentially in state of arrested development.


And is there something sacred in basic Web design or mail design? Both
are highly arbitrary, we just got used to this state of things and now
invent shallow and specious rationalizations why things should be this
way, but in reality it's just been this way for a long time and there's
nothing out there that is a good reason for mistakes of the past.


Regards,
Marcin Krol