Stefano Mazzocchi wrote:
> > I'm guessing you have equated URL's and recipients as comparable, which
> > is why you suggested <process address="[EMAIL PROTECTED]">.
>
> Yes.
I really don't agree with this, but I'll probably just have to come up
with better examples to convince you otherwise. One of the most
important routing checks a mail server has to do is determine whether an
email is 1) incoming email (a mail intended for a valid user), 2)
outgoing email (a mail sent by a valid user), or 3) some (*&(ing spammer
trying to use us as a relay. To do these checks, you rely on 1)
recipients (yes, ok, we have to check that), 2) sender, and 3) ip
address of remote connection, and possibly other checks, but more than
likely just these three. If you're then a mail server that's support
multiple domains, this process becomes unworkable IMHO using <process
address=>.
> > However, many matches will not use recipient info, and few will have
> > "condition" parameters.
>
> I disagree. The parallel to me is evident: just like you use an HTTP URI
> to indicate your browser where to go and what to do, you tell your
> mailer with the recipient list.
I just don't think this will work. I can't configure my mail server in
this fashion... I'll have more examples later in this week once I create
a conf file for our external mail server (and write an anti-spam servlet
or match class or two).
> <process address="stefano@localhost">
> <...>
> </process>
>
> <process address="stefano@localhost">
> <match type="timestampBroken"/>
> </process>
>
> <process address="*@localhost">
> <...>
> </process>
And with multiple domains you get,
<process
address="*@lokitech.com,*@collegeparkracing.com,*@rumorofsurf.com">
<...>
</process>
> <process
>
>match="(recipientIs=stefano@localhost)and((timestamp!=currenttime())or(x-mailer!=regexp(.x./.)))">
> ...
> </process>
> [stuff deleted]
> There is another issue: XML validation. It's easy to come up with a
> schema for this sitemap if we use the matching element, it's almost
> impossible if we create a matching logic encoded in the attribute value.
I realize a key difference... how to explain it. If I understand your
approach, you're putting logic into the JAMES conf file (or at least
afraid we will). The way it is now, the Match class approach pushes any
complex logic into individual Match classes. RecipientIs is a Match
class and it has an optional condition [EMAIL PROTECTED] You
would have TimestampMatch, not timestamp!=currenttime(), and
MailerSoftwareMatch, not x-mailer!=regexp(.x./.). If you wanted the
logic you described/feared, you'd have to make a new Match class. Right
now you can pass 0 or 1 conditions to a Match class, but that's more
just a function of beta quality code that needs to be fixed, not a
design decision, and right now you write MatchClassName=condition. I
agree we don't want to fall down a slippery regular expression slope,
but I'm not sure if <process address=> makes things any better.
Anyway... I'm not sure if this is just wishful thinking that everyone
will write a new Match class if they have some complex logic... that's
probably too much to ask. Nonetheless, I'd rather not sacrifice that
ability as I think it's important (your match class could connect to
your Notes database and valid accounts that way, etc...)
One idea... we already have some well used flags defined in the Mail
object... perhaps we add VALIDATED_LOCAL_SENDER,
VALIDATED_LOCAL_RECIPIENT, SPAM. We could then have simple
Match/servlet combinations that check against user lists, LDAP accounts,
whatever and set these flags as appropriate. For instance, I might
write 8 different Match/servlets that check whether an email is a piece
of SPAM. Later on I can use a prebuilt match class IsSpam, which will
check for the SPAM flag in the Mail object. Sounds good?
One thing not mentioned that the architecture offers right now is full
xml parameters for your servlet. For instance I can have
<servlet ..(matching stuff)... class="MiniListserv">
<membersonly>true</membersonly>
<members>
<member>[EMAIL PROTECTED]</member>
<member>[EMAIL PROTECTED]</member>
</members>
</servlet>
I like this extra configuration options for servlets. ;) (I believe you
were suggesting just name=value for servlets)
I'll send my conf file later in the week once I get the antispam servlet
written... maybe I'll get some better ideas then and come around to the
sitemap approach. ;)
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
