Serge Knystautas wrote:
>
> 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.
I totally admit my lack of experience with mailing systems so you might
be totally right on this. I base my logic on symmetry and assumptions...
but it could easily be a very bad reasoning paradigm.
> 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.
Ok. For web this would be
1) local URL
2) proxied URL
3) illegal URL
> 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.
Good, first difference. Normally you only need the URL to start in a web
serving environment.
> If you're then a mail server that's support
> multiple domains, this process becomes unworkable IMHO using <process
> address=>.
what about
<process address="..." sender="..." sender-ip="..."/>
might be totally stupid... just asking (since Federico didn't include
that anyway)
> > > 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>
right
> > <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.
Granted.
> 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...)
I don't sacrifice anything. It's just another XML schema that could be
validated instead of placing everything into a matching string that
cannot be validated (so wrote with XML tools).
> 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?
Sure, why not.
> 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>
You touched the nerve.
I'm concerned about that "...(matching stuff)..." that you left blank.
Federico wants to do matching string of the form
(function)([and|or](function))*
where
fuction :== something that exposes some "boolean returning java logic"
for example
match="(recipientIs(*@apache.org))and(isNotSpam())and(not(recipientIs([EMAIL PROTECTED])))"
my humble suggestion is to do something like this instead
<servlet class="....">
<matching>
<and>
<matcher id="recipientIs" value="*@apache.org"/>
<matcher id="isNotSpam"/>
<not>
<matcher id="recipientIs" value="[EMAIL PROTECTED]"/>
</not>
</and>
</match>
<parameters>
<any-servlet-parameters/>
</parameters>
</servlet>
Please, don't take verbosity into account, but consider readability,
transformation capabilities and GUI authoring.
> I like this extra configuration options for servlets. ;) (I believe you
> were suggesting just name=value for servlets)
The above is my complete suggestion.
> 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. ;)
Great.
Consider playing around with my simple schema...
...admittely, I don't like the <and>,<or>,<not> tags, I'm wide open to
any suggestions... as long as we keep the structure schema-validable,
which means: out of regexp-like matching strings!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
