Suggestion for feature (Spam-related)
D. Stussy
defined as invocable via the M4 macro language). However, I can think of two
reasons to have a class of [local] mailbox/user names that are exempt from the
milters:
1) Special mailboxes for "postmaster" or "abuse" might want to bypass them; at
least the ones which are spam filters.
2) Special mailboxes which are "spam traps" (i.e. that feed the spam detection
milters) probably NEED to bypass them, depending on the exact learning algorithm
they use. [If there are multiple traps, then they should alias to a unique
mailbox.] This would be true of a "this-is-not-spam" type mailbox, especially
since it would receive mail misclassifed as spam per the milters that were
already applied as it was delivered to the local user that's forwarding it.
Of course, due to milter design, there would still be some calls
(initialization, the "MAIL FROM" call, and the closing call, plus the regular
milter calls if there were any non-spam-excluded recipients). However,
including as a recipient a non-excluded mailbox should naturally "deactivate"
the bypass anyway, so that would be a feature, not a design bug.
I'm thinking of this as a special class, like "trusted users" or the "masquerade
except" users. Should milters then have another data item (flag) indicating
whether or not they are bypassable or mandatory for all users?
Comments?
David F. Skoll
> As I understand sendmail, milters are not generally bypassable (when
> properly
> defined as invocable via the M4 macro language). However, I can think of
> two reasons to have a class of [local] mailbox/user names that are exempt
> from the milters:
[...]
All of that logic can easily be implemented in the milter itself.
Regards,
David.
Mark Tranchant
> D. Stussy wrote:
>>As I understand sendmail, milters are not generally bypassable (when
>>properly
>>defined as invocable via the M4 macro language). However, I can think of
>>two reasons to have a class of [local] mailbox/user names that are exempt
>>from the milters: <snip>
> All of that logic can easily be implemented in the milter itself.
Agreed, but it would be nice to implement it once in sendmail rather than
multiple times in different ways in the milters. For example, milter-sender
reads the access database, MIMEDefang needs specific Perl code written, etc
etc.
--
Mark.
http://tranchant.plus.com/
David F. Skoll
> Agreed, but it would be nice to implement it once in sendmail rather than
> multiple times in different ways in the milters.
No, it's nightmarish to implement it in a sane way using Sendmail .cf
directives. Different behavior for different recipients, you say?
And what if mail comes in for more than one recipient?
I have first-hand experience with the weird and wonderful rules people
use to change milter behavior. They're ugly enough in Perl; I'd hate
to see someone try to implement them in Sendmail .cf language :-)
Also, I'm of the "one-milter-that-does-everything" persuasion, rather
than the "many-little-milters" persuasion. So it's not a big deal for
me to code that logic up in my single milter.
Regards,
David.
D. Stussy
True, but EACH milter would have to be configured to have such a bypass for the
SAME local mailbox list (or class variable). It's more efficient not to even
make the milter call(s) in the first place and the condition need only be
checked once. With the milters checking, each must be called and each must
perform the check. I made the suggestion because I want to avoid that overhead.
D. Stussy
> > Agreed, but it would be nice to implement it once in sendmail rather than
> > multiple times in different ways in the milters.
>
> No, it's nightmarish to implement it in a sane way using Sendmail .cf
> directives. Different behavior for different recipients, you say?
> And what if mail comes in for more than one recipient?
It is obvious that one would not be doing more than defining the class of the
local mailboxes in the .cf file. The rest would be implemented as changes to
the PROGRAM. Think about it: Although milters are defined in the .cf file,
there is no ruleset that calls them.
It is also obvious that you didn't read the initial suggestion carefully. It
included what happens if there are multiple recipients, specifically, if there
is ANY recipient that is not of the "bypass class."
David F. Skoll
> It is obvious that one would not be doing more than defining the
> class of the local mailboxes in the .cf file.
In this case, you can do it fairly easily now. Have a ruleset set a
macro and pass this in to the milter, which can skip the tests.
All of the important logic is done by Sendmail; the changes to the
milter are minimal (just return SMFIS_CONTINUE if the macro has
the prescribed value.)
--
David.