BlackMail TODO listing
======================

Note: This TODO listing is rather disorganised!
More up to date plans will become available on one of the blackmail websites.

Older ideas, not in any particular order:
----------------------------------------
o) Smarter "received" header filtering and parsing (impossible?)
   Many messages are obviously faked when you read the headers - we need to
   do this checking in code.
o) Message body parsing - just HTML so far
o) Alias lookups for virtual domains (using wildcards as VMAIL does)
o) Logging of session information to a separate logfile (with locking)
o) Possibly make BlackMail its own mailer daemon (non-forking, single
   process with multiple connects available)
o) Possibly make a per-user filter
o) Possibly make BlackMail query the connecting site (via libresolv) to
   get a listing of MXes and relay-sites; if none match, it is rejected.
o) Possibly write a POP3 mail proxy filter
o) Possibly add message size checking
o) improve SPAMEXIT or DONTEXIT option such that the connection can be kept
   open after spam is rejected and other mails from that relay can be
   processed. Needs re-implementing, but the sender SMTP needs to co-operate
   too and it seems some don't do what is expected.
o) document which platforms Blackmail will run under
o) security review of blackmail - are there any potential holes?
   Mike Ireton suggests dropping special priviledges after startup.
o) possibly reverse DNS on IPs and recheck against banned list.

o) An idea that  dr@ripco.com (David Richards)  mentioned on Usenet:
 >It wouldn't be totally unreasonable for an ISP to refuse to send out mail
 >coming from an internal host, but with a 'SMTP From' address of a domain that
 >the ISP isn't a nameserver for.

o) Review/reorganise documentation


Ideas / suggestions for future releases:
---------------------------------------
o) Why RBL check private address space? e.g. 192.168.x.y
   e.g. add a NOT_RBL section to the config
o) Continue reviewing/streamlining code, targetting areas of maximum benefit
  e.g. look for any potential speedups in modules/data.c 

Next seven from Jonathan Bradshaw <jonathan@NrgUp.Com>

o) I would like to see a section to include "ALWAYS_ALLOW", eg "abuse" and
"postmaster" that would always allow mail addressed to those even if the site
is blocked.
o) Use regexp instead of wildmat or as a compile time option.
   'it would then be possible to create a rule to match those 12345@aol.com
    type addresses without catching compuserve etc (ala procmail!)'
o) A GDBM type DB for the list of rejected hosts.
	Jonathon says,  "My 'bad mail from' file is over 6,000 entries and
	updates every 12 hours. A little over the 1,000 limit ;-)"
o) Allow matching for "LOCALHOST" based on DNS name (*.mydomain.com)
o) Allow for pattern matching exceptions to allow me to say:
        patterns such as: postmaster* and abuse* 
    should always be accepted.
o) Allow section to override RBL in case they block NETCOM again ;-)
o) Configurable SYSLOG levels and priorities.

Miguel Cruz <mnc@diana.law.yale.edu> suggested:

  Reminds me, has there been any thought of adding teergrube powers to
  Blackmail?

  (for the uninitiated, that would have it slow the session down when it
  detects incoming spam. Each line of response from the SMTP server would
  take an hour or so. This ties up resources on the spamming machine - in
  the case of a single-threaded spew program, it would put an effective halt
  to the whole thing. One person reported keeping a single incoming spam
  connection open for two days using teergrube. If enough people do it,
  then spamming would become much more complicated - either they set
  timeouts so aggressive that they can't deliver to popular, burdened
  sites, or they spin to a halt every time they hit a booby-trapped site).

-
This TODO list needs updating to include the latest ideas from the list (!!)

Last updated 5 Oct 1998
