On Wed, 2004-04-14 at 02:01, Matti Aarnio wrote: > 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..) Those two, I think, could be safely dropped as long as addresses are checked with interactive router. More authoritative, and no duplication of effort. > 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 ? That was unintentional, I'm afraid... > 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 Oh, this would make the whole thing much clearer! There possibly could be five sections: 1. connection 2. helo check (not really useful, but for completeness) 3. mail from check 4. rcpt to check 5. content check in each section, "disposition" tristate could be initialized or changed, and optionally a flag set to short circuit any subsequent checks. e.g., bad "mail from" could set disposition to "fail" at section 3, but later on "rcpt to:<postmaster@...>" would change it back to "accept", and say that content filter should not be run on this message. Another example: connection from an absolutely unwanted network could set "fail" and terminate session immediately Then, connection from a local network could set "accept" and short circuit any further checks. > 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. The above approach would allow that. OTOH there might be necessary to have more flags than just "disposition" and "short_circuit"... BTW there may be a problem: what to do with a message addressed to multiple recipients including postmaster, and content-filter says that the message is bad? Eugene
This is a digitally signed message part