Marc Haber wrote:
> On Fri, 18 Nov 2005 10:04:56 +0100, Jeremiah Foster
> <jeremiah.foster@???> wrote:
>
>>This is a good idea. I think even Marc Haber (debian package maintainer)
>>said that what exim lacks is a good
>>tutorial with examples. I would help with this if work needs doing, I think
>>this would really help.
>
Agreed. Seconded.
>
> Philip's book is an excellent tutorial. What is missing, IMO, is a
> tutorial like "E-Mail's technical basics in 21 steps", but people
> won't read it because theoretical knowledge does not have any value to
> them because they cannot click on it.
Wish it were otherwise, but am afraid that is a fact of life these days.
May be driven by 'instant gratification' attitude, or simply lack of
time, but it
is a reality that needs to be acknowledged and managed.
>
> And I am quite opposed to giving HOWTO-type examples because people
> will blindly cut&paste them without understand what they do.
>
> Greetings
> Marc
>
That they will do anyway - from this list and several web-pages and wiki
posts of practitioners, if nowhere else.
Unless they are given an easier way.
A desirable goal then might be to have a collection of *integrated*
examples - configurations that are fully complete and need no patching,
cut 'n paste, or other alteration, including:
1) - a 'testing' configure designed to minimize the possibility of rude
behaviour, open-relaying, or generating collateral damage.
Exim has perhaps the best debug and test tools of any available MTA, but
they are not used as often as they should be, nor can they simulate 100%
of all possible scenarios. An initial configure that is purpose-built
to allow testing basic functionality, perhaps without even need of an
external IP, could be a valuable post-install step.
2) - a 'basic' configure that itself obeys all the applicable RFC's, but
is more forgiving of incoming behaviour.
i.e - NOT (yet) rejecting on mal-formed headers, mismatches in EHLO/HLO,
failed rDNS, lookups or verification, and without SA or ClamAV.
Not greatly different from the configure.default - and YES this will
accept copious spam.
Consider it 'free test' traffic for learning purposes, and manage it in
the MUA or a catch-all for the short term.
A review of it will help identify what filtering a particular
<domain>.<tld> needs to get the most payback first.
3) - a succession of fully-integrated configure files of progressively
more stringent vetting and filtering by means of acl tests.
- still without SA / ClamAV.
This could begin with most acl's fitted with 'warn' verbs and
'fake_reject' that might later be changed to a hard 'deny'.
We can also capture an quarantine questionable traffic so it can be
reviewed and onpassed, rules reviewed.
This is the level at which it is easy to generate false-positives, so
somewhat more verbose logging should be switched-on.
- But if we 'get it right' we can also eliminate from 70% to 95%+ of
mal-traffic before we even need to call upon external spam and virus
checking tools.
Basic local whitelisting/ blacklisting should be covered, as there will
inevitably be certain badly-configured correspondents we must accept,
and other properly-configured ones we wish to always deny. Connectivity
ISP advertising, for example.
4) - a drop-in module for SA and ClamAV that is comfortable with the
default configurations of those worthies, along with tests that will vet
their functionality. Both IP and socket use shown.
5) - Examples of 'DB-ification' for LDAP, MySQL, PostgreSQL, and the
Berkeley & GDB tools. Along with why we might not want to make such
relatively resource-intensive calls. I use PostgreSQL, but do not
recommend an RDB engine as the best all-around tool for the general MTA
case.
6) - Examples of SSL & TLS cert & authentication do's, dont's,
troubleshooting, and 'what works with what' w/r certain well-known MUA
foibles.
To give the Debian team their due, it appears that some of their unusual
configuration control methodology is driven by similar considerations.
Unfortunately, is doesn't 'port' well to Unix/other Linux = the more
general Exim environment.
That doesn't mean the general case could not follow a defined progression:
- Start with the simple case. Test thoroughly. 'configure.test'
- Move up in incremental steps. Test thoroughly. 'configure.basic',
'configure.strict1'....'configure.strict(n)'
(all these installed where configure.default lives, not hidden away in
the build environment.)
- Become clever and inventive only after seeing and understanding the
effects of various tools. Test even more thoroughly!
*Then* turn some of the 'warn' verbs into 'deny', continue to monitor
results and logs.
Finally reduce the 'extra' verbosity level of logs.
An expert user may make this trip faster than a novice, but even
'jumping ahead' and never bothering to learn the how and why only
results in use of a tested configuration that is know to work well, but
has not been optimized for local considerations.
We already have all the piece-parts. Somewhere. *Several* somewheres.
We may need organizing and editing more than invention.
'First, do no harm'
JMO,
Bill Hacker
