On Thu, 25 Apr 2002, Scott Lamb wrote:
> Scott M Likens wrote:
>
> > This is quite Sickening, RBL is a MTA implementation not needed to
> > be done via Sieve, and as for spamassasin you can always write
> > decent header checks and body checks for postfix to use. I am
> > sure there is the same option in sendmail.
>
> If you have some idea how I could accomplish my stated goals on the
> MTA side, please share.
For recent versions of sendmail, you can use the spamfriend/spamhater
hooks in the accessdb to implement either one of these policies:
1. Incoming mail from RBL-listed sites is rejected, except for
spamfriend users.
2. Incoming mail from RBL-listed sites is rejected only for
spamhater users.
You'll need to design a method for users to indicate their choice,
though.
Solutions probably exist for other versions of sendmail, and other
MTAs.
> I've given my reasons for this approach. Why do you feel so
> strongly that this belongs in the MTA?
I'm not the person to whom you addressed this question, but I'll
answer it anyway:
Because the receiving MTA is the only entity which knows the IP
address of the relay. Once the receiving MTA hands off the message to
another MTA, that information is lost.
Trying to determine the IP address of the relay by screen-scraping the
receiving MTA's Received headers is an ugly, disgusting, error-prone,
shameful hack. It does not belong in Sieve; it does not belong in
anything.
If you want to accept/block mail based on the relay it comes from, do
it at the MTA. Don't tag at the MTA. Don't file at the MTA. Either
accept or reject, period. Provide a way for individual users to
control the accept/reject behavior for mail destined to them.
If you want to filter mail based on content, do it at the local
(final) delivery agent. Tag or file based on the content, but don't
reject it. Provide a way for individual users to customize the
filters and their actions.
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
