#4 external authorizations via SMTP-AUTH, DRACd, TLS...
RFE: Add provisions for various external client
authorization to override the spf checks done on roaming
users. For example:
SMTP-AUTH: authorized by the sender's password, and
the suggested method for a roaming user to relay
through the "home/isp" machine.
DRACd/popauth: Pop-before-SMTP while less reliable has
a greater that 80% chance of being an authorized user
on the machine. This method requires the least work by
the clueless user base.
TLS: accept mail from my customer's keys.
Access.db: Two cases:
From:myuser@mydomain.com RELAY
Milter-sid-From:myuser@mydomain.com OK
The broken user who cannot get anything above
working, but is a legitimate client and takes
responsibility for his single address being spoofed. Yes,
I have seen/needed this on occasion. This
"authentification" is by sysadmin choice for a specific
user, which can be very different that the whole
domain's default actions.
2nd case:
To:abuse@mydomain.com OK
Milter-sid-To:abuse@mydomain.com OK
To:postmaster@mydomain.com OK
To:user_who_wants_no_filters@mydomain.com OK
If the delivery is local, check the access.db to see if the
receiving user wants to override the filter, and accept
the mail when it would normally be denied. Milter-sid-
To: overrides To: in order to allow more fine controls of
what is allowed. See milter-gris by Anthony Howe for
details of a good implementation.
My continued suggestion in the second email to the list
was to use "external" as a flag to show a check was
overridden by one of the stronger authentification
systems. And, add the IP address in question to the
status line in syslog and the email header.
For a roaming user, the differences would show as the
following:
Old: Authentication-Results: recipient-isp.com sender-
id=pass; spf=pass
Authentication-Results: sender-isp.com sender-
id=fail (NotPermitted); spf=fail (NotPermitted)
New: Authentication-Results: recipient-isp.com
from=myclient@sender-isp.com; sender-id=pass;
spf=pass; ip=e.f.g.h
Authentication-Results: sender-isp.com
from=myclient@sender-isp.com; sender-id=external;
spf=external; auth=pass (cram-md5); ip=a.b.c.d
Logged In: YES
user_id=1048957
I don't believe the filter should change its results based
on other authentication schemes. Ideally, some other filter
(or maybe the MTA itself) would add Authentication-Results:
headers to indicate the results of TLS and SMTP AUTH checks,
etc.
The delivery decision should be made by an LDA based on the
collected Authentication-Results: headers. It follows then
that whether or not TLS, POPAUTH, SMTP AUTH, etc. passed or
failed is not relevant to the SPF and Sender-ID checks. For
example, even if SPF and Sender-ID failed, if SMTP AUTH or
POPAUTH passed, you should accept the message.
Logged In: YES
user_id=1146959
The issue is not wether the sending ISP accepts the message,
it is what header lines are there after both the sending and
receiving ISP has marked it up and the LDA is handed the
message.
LDA=mail.local;
processing=none
LDA=procmail;
:0H
^Authentication-Results:.*sender-id=fail (NotPermitted);
spf=fail (NotPermitted)
/dev/null
This case would toss out the email no matter how many other
lines had pass results.
LDA=SpamAssassin;
indeterminate. Since many spammers are publishing SPF
rules, SpamAssassin is not going to add a large negative
value to a pass result, but will put a large positive value on a
fail result. So, it will take at least two passes to override a fail
in a chain of Authentication-Results: headers.
Those users who are outside the SPF defined IP addresses and
need to send mail are told they are required to use an
authentication system of POPAUTH, SMTP-AUTH, or TLS. If
their email is marked with a "fail" condition as it leaves their
own ISP, it will have very little chance of getting through
*anybodys* filters. Marking the mail as external gives it a
chance that it will make it through SpamAssassin or Procmail
filtering.
Case: Sending ISP marks message as fail as you suggest.
Receiving ISP has SpamAssassin which has (it will eventually
in some newer version) default values for SPF header checks.
The receiving ISP does not do Sender-ID/SPF checks and so
the only record in the header is a fail condition.
Results=discard.
I'm just warning you to not mark the mail as bad when you
have enough information to know for certain that the mail is
actually good. I personally have went with someone else's
implementation that I could incorporate these changes into
easily and have running immediately.
Logged In: YES
user_id=185025
The fact that sid-milter cannot be configured to skip messages that have
authentication is a problem when you run it on your own mail server with -r 2.
Despite the fact that you've authenticated, you cannot send mail at all because
you're coming from another IP. There should be an option to treat authenticated
connections the same as if the incoming address had matched the -a list.