Re: smtpserver router subdaemon

[Matti Aarnio <mea@nic.funet.fi>]

On Tue, Apr 13, 2004 at 05:55:34PM +0400, Eugene Crosser wrote:
> > > --- smtpserver/policytest.c     12 Apr 2004 12:13:11 -0000      1.89
> > > +++ smtpserver/policytest.c     13 Apr 2004 10:19:58 -0000
> > > @@ -1704,7 +1704,9 @@      if (state->always_freeze)
> > >         return 1;
> > >      if (state->full_trust || state->authuser)
> > > -      return 0;
> > > +       return 0;
> > > +    if (state->always_accept)
> > > +       return 0;
> > >      if (len > 0) { /* Non-box address.. */
> > 
> > The story here is somewhat more complicated.
> > For the "ratelimitmsgs" to work, the "always_accept" flag testing
> > must be moved onwards - a lot.
> > 
> > Reading the code again, the "always_accept" has been demoted into
> > "accept if various tests don't reject" state, while "full_trust" is
> > literally that.
> 
> Then probably SMTP AUTH and WHOSON sould be changed to raise full_trust
> rather than always_accept, right?

No, not quite.  Or rather, it should be configurable (without
your favourite $EDITOR and $CC ...)

Those "various tests" include:
   "is the MAIL FROM domain something we can find in the DNS ?"
   "is the RCPT TO domain something we can find in the DNS ?"
(if either get NXDOMAIN, or lack of MX & A (& AAAA in IPv6 talker),
then it is mid-finger time..)

They also include a number of "domain only", and full address
lookups from manual spam address tables.

Perhaps WHOSON should behave like AUTH stuff does, although
it isn't quite exactly equally knowing verifier of remote
identity ?  (E.g. a number of users behind single-IP NAT...)

The AUTH is exactly equal of full_trust.
(Well, not quite, but as nearly as it matters; both in MAIL FROM
and in RCPT TO.)  The settings come from different sources,
of course, and therefore are separate.

With AUTH (and full_trust,) there are no DNS verifications of
MAIL FROM and RCPT TO domains, or rate-limitations.
With WHOSON, and accept_all there are.

Hmm..  No, apparently the WHOSON can have itself applied only
at MAIL FROM and RCPT TO, if   _default_ip   and/or  _full_rights
macroes don't have "trust-whoson +" attibute pair, while
"." a.k.a. _default_dot has it.

Is that intentional ?  Perhaps its original author can enlighten
us about that tidbit ?


Oh yes, the entire smtp-policy.db key structure is somewhat clumsy.
Right now there are IP-address labels, and there are domain labels,
and user@domain labels ( + macroes, but that is beside the point )
Sometimes I think that there should be:
- IP labels
- domain labels for all but MAIL FROM, RCPT TO
- domain labels for MAIL FROM
- domain labels for RCPT TO
- same triplet for user@domain forms

Which would also necessitate (allow!) 3 different world-views of
"_default_dot" ...

Our manual SPAM list is a mixture of IP labels, domain labels, and
user@domain labels.


Oh yes..   my long-standing "things are broken" consideration is,
that there really should be a way to delay rejections of HELO/EHLO/MAIL, 
until RCPT address entry.  That way the "always be possible to send
email to system postmaster" could be made to hold true.


> > What I say above is true for MAIL FROM policy processing.
> > The RCPT TO policy processing needs similar forward movement.
> >  .. which is there already
> > just unplugging the unnecessarily early test.
> 
> Eugene

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi