need organizational hint

[Phil Howard]

On Sat, Apr 12, 2003 at 09:49:47AM -0400, Ken Murchison wrote:

| 
| 
| Phil Howard wrote:
| > 
| > Looks like I'll have to take a look at doing some sort of direct method
| > of SMTP-to-Cyrus.  One option is an SMTP-to-LMTP front-end daemon that
| > would include some filtering (perhaps just whatever Sieve doesn't do).
| > The other would be modifying Cyrus to actually include SMTP capability.
| > That would depend on how simply the LMTP daemon part is, either in how
| > succintly it deals with mail storing details, or how well it encapsulates
| > so those details are immaterial.  I won't know until I get the time to
| > study the source code more fully.
| 
| LMTP and [E]SMTP are indentical except for the hello commands, so making
| lmtpd handle [E]SMTP is trivial, but I don't see the point.  Cyrus is
| not designed to be an MTA, and I don't think you want to spend the time
| doing so.

I'm not actually considering this role to be that of at MTA.  Rather, it
is the role of a final destination mail store that will generally be the
only MX host for its served domains ... that will talk SMTP in that role.

There are certain fundamental problems with having the email service split
between a mail store and an MTA.  One of those is that there ends up having
to be a lot of mail store functionality duplicated in the MTA, which the
mail store could just as well do if it had the info, and was in control
at the proper time.  In order to have a complete scope of spam control,
whatever component is conducting the receiving end of an SMTP session has
to have an understanding of end user wishes.

And this is a special case of MTA where 100% of the inbound mail is only
for delivery to the mail store.  Outbound mail won't be handled at this
IP address and thus won't need to be handled by this MTA.  For outbound
mail, I will be running a separate MTA which won't have any need to feed
the mail store except for mail specifically addressed to a domain served
by that mail store in which case it can send it by SMTP like any other MTA.

Current MTAs lack the full ability to perform flexible spam controls as
specified by the end user.  Either way I have to add something to some
part of the whole mail server.  Adding all the spam controls to the MTA
looks like a lot more work, given that it only queues mail, rather than
do an SMTO to LMTP session pass through.  That means implementing not only
full user awareness in the MTA, but also all the Sieve mechanism for those
cases where the content is to be scanned by that method when the user wants
that to be done for direct rejection.


| > I take it no one else has any spam filtering going on that is both based
| > on SMTP envelope, and is customized per user.
| 
| Sieve does get the envelope, but it has no facilities for checking IP. 
| You might want to consider having your MTA do this type of SPAM checking
| globally and adding an X-SPAM header which can then be filtered by
| individual users via Sieve.

Sending an X-SPAM header only works if the MTA has elected to accept the
data being sent in the SMTP session.  The objective is to reject as much
of the email as possible during the SMTP session by means of a 5XX response
code, and avoid even the transmission of the data stream where that decision
is final based on the 

Not all users want, or do anything with, a separate spam folder.  That
just adds to the workload.  And in cases where legitimate mail goes into
that folder, either the user has to spend all the same wasted time to
look for it in there, or else the user ignores the spam folder.  In the
latter case, you end up with legitimate mail not reaching the user but
the sender thinking that since there is nothing bounced back, it has
reached the user.  Ultimately, I think the user should make that decision
and I believe many users will prefer to decide to refuse spam mail so
that the sender gets a notification.  Users who have no intent to read
their spam folder would be well advised to do it that way, and I want to
given them that option.  I know that will be my own selection.

User decisions end up having to be made at SMTP session time.  Having two
software components involved is redundant.  Having duplicate user knowledge
in an MTA is redundant.  By adding an SMTP capability to Cyrus, with the
addition of user specified spam controls, redundancy is reduced.  Whether
this kind of spam control can be added to Sieve or not I don't know.  It
would be nice if it were, but it looks like the standard language does not
provide for that.  The best course I can see is a combination of controls
where one set of specifications for SMTP metadata is used, and another set
for content scanning is used, and the latter would have to be applied while
the SMTP session is still working so the final response applies to the SMTP
DATA command.  If Sieve can be made to do it at this time, that's certainly
much better as it looks like an excellent way to specify content based
controls.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------