BlackMail Flowchart Details of Command Pathways

This is a small flowchart, in non-technical terms, of how each SMTP command
is executed through BlackMail.  (This file is slightly out-dated/incomplete.)

Internet RFC documents RFC821 and RFC822 are useful reference if you wish
to understand email in more detail. They are available by ftp from
ds1.internic.net in /rfc as rfc821.txt and rfc822.txt.

---

"HELO" and "EHLO"
	These commands must match the format layed out in RFC821
	This is checked against the REJECTED_ADDRESSES to make sure the
	address given does not match an entry.  If it doesn't match an entry,
	it is then checked to make sure the domain is a valid one either
	by DNS or against the built-in list of 'top level domains' (TLDs)
	If these are correct, the command is passed through.

"MAIL from:"
	This command is also RFC821-challenged.  It checks the mail
	address to make sure that it contains a valid top-level domain
	and is checked using DNS. Then, it checks to make sure a username
	is specified in the address (ie "user@site" instead of (spam)
	"@site".)  It then checks to make sure that site is not in the
	spamsites list.
	If none of these are matched, the command is passed through.
	
"RCPT to:"
	Very few checks are performed here.  The first check makes sure
	the mail that is being sent to the proper recipient within your
	domain.  If the recipient doesn't match an address in your domain,
	the mail is rejected with a bogus error to the server that sent
	it.  (This is where most mail is forged is at this line.)
	These checks also prevent unauthorised mail relaying.
	DNS checks as above.

"EXPN" and "VRFY"
	These commands are HUMONGOUS security holes.  They have been
	removed from processing or passing through, and return an error
	code by default.
	VRFY can be explicitly enabled through the conf file as this is
	an RFC1123 requirement.

"DATA" and "QUIT"
	These commands are not checked, and are passed through.  If DATA
	is sent after all MAIL from: and RCPT to: commands were given,
	it enables "header mode" on Blackmail, where BlackMail begins
	checking headers.

---

HEADER CHECKS:

	During header checks, the following headers are checked by
	default:

	X-Distribution:
	From, X-Apparently-From, X-From, Reply-From, From:
	Received:
	Reply-To:, To:, X-To:, X-Apparently-To:, To:
	Message-ID:
	Comments:

	All headers are checked against the HEADERS section.

	X-Distribution: is a marker that is sent by many mailers that
	signifies (politely) what type of message was sent.  By
	default, BlackMail rejects mail matching "Spam" or "Bulk"
	distributions.  (Thank GOD for Pegasus Mail doing this.)

	From: and To: headers are checked using the DNS or top-level domain
	check, using REJECTED_ADDRESSES and are checked for correct formation.

	If the TO_FROM checking is enabled, then mail will be rejected
	when the To: and From: address are the same remote address. This
	seems to be a common spam signature and should not occur on normal
	mail. Mailing lists should not fall foul of this check if they are
	configured correctly.

	Comments: header is checked for the string 'Authenticated Sender is'
	and if found then the following email address is checked for
	correct formation, valid domain and spamsites.

	Message-ID: header is checked for correct formation, it
	is checked for '<someid@somewhere>' and rejected if this is not
	found. 

	X-Advertisement: and X-PMFLAGS: are pointers to spam and are
	included in the HEADERS section of the default blackmail.conf.

	Received: is checked against the HEADERS section. There is a
	potential to trap fake mail here but correctly identifying valid
	and invalid mail paths is complex and not implemented yet.
