From: Michael E. <el...@ma...> - 2004-10-27 01:22:42
|
On Mon, Oct 25, 2004 at 03:40:50PM -0700 or thereabouts, Murray S. Kucherawy wrote: > On Fri, 22 Oct 2004, Michael Elliott wrote: > > And now for that can of worms. For the email header, by spec, > > > > Authentication-Results: my.machine.com from=us...@mo...; > > sender-id=fail (NotPermitted); spf=fail (NotPermitted) > > > > is what is supposed to be there. Sid-filter seems to not be putting > > in the from= part of the header. Is this because different headers > > are being checked by the different methods? > > It's because I revised the spec after releasing the current sid-milter > package. Ok. Sounds good to me. > > > I think there needs to be one additional result code added to make > > the processing clear to a reader. In addition to pass, fail, neutral, > > and softfail, I would suggest adding "external". "external" to be > > defined as a not (pass or softfail) condition that was overridden by > > a pass condition in another, stronger authentification system. > > That would mandate the addition of a different header. You could > certainly add: > > Authentication-Results: my.machine.com from=whatever; auth=pass > > ...to indicate that it passed SMTP AUTH, for example. Locally then you > can weigh that higher than all other systems and make a decision based on > that. But, I am not processing it locally. That is the problem. I am sending the mail to someone else that may be processing spf (I hope so). My case is with the current implementation: Roaming user generates email. Sends via SMTP-AUTH to sender-isp.com. Record goes in: Authentication-Results: sender-isp.com from=whatever; sender-id=fail (NotPermitted); spf=fail (NotPermitted) Sender-isp relays the email on to recipient-isp. Authentication-Results: recipient-isp.com from=whatever; sender-id=pass; spf=pass is now added. Mail handed to spamassassin or procmail for processing. It is read by procmail or SpamAssassin. We have 1 pass line, 1 fail line. What is the LDA to do? If it gets past that, it is read by a human. We have 1 pass, 1 fail. Human assume forgery. I am asking that the behaviour be chaanged to: Roaming user generates email. Sends via SMTP-AUTH to sender-isp.com. Record goes in: Authentication-Results: sender-isp.com from=whatever; sender-id=external; spf=external; auth=pass (cram-md5) Sender-isp relays the email on to recipient-isp. Authentication-Results: recipient-isp.com from=whatever; sender-id=pass; spf=pass is now added. Mail handed to spamassassin or procmail for processing. It is read by procmail or SpamAssassin. We have 2 pass lines. The LDA sees a clean message and puts it into the user's mailbox. Human reads headers and sees a clean message. The difference is that the sendmail/milter pair recognizes an authenticated message and does not mark the email with a fail condition in the header. Your suggestion that I put in a seperate Authentication-Results: line only complicates maters. It would present the following: (abreviated to the meaningful pieces) AR: recipient-isp.com from=whatever; sender-id=pass; spf=pass AR: sender-isp: from-whatever; sender-id=fail; spf=fail AR: sender-isp: from=whatever; auth=pass Now, how is procmail going to process this? 3 passes, 2 fails. Sender-isp.com: sendmail 8.13.1+sid-filter Recipient-isp.com: sendmail 8.13.1+sid-filter The sid-filter needs to work both as the injection source and as the final recipient destination. > The draft means only to present a means of relaying sender auth check > results from an MTA to MUA. It doesn't attempt to indicate the value of > the checks, since one installation may put more weight on a particular > method than others. Something between the MTA and MUA (e.g. the LDA), or > the MUA itself, is meant to be the location where delivery decisions are > made, since all the sender auth checks are done by that point. But, we are dealing with MUA->MTA SMTP-AUTH pass + spf fail The SMTP-AUTH check has to be done by the milter and the pass state has to be registered, because that is what the users are told to use when roaming. If you don't check the SMTP-AUTH state, the email is rejected wrongly. MTA->MTA spf pass clean message from sender-isp.com->recipient-isp.com. MTA->LDA looses IP address and other variables that decisions are made upon, and has to rely on what was written in the msg. LDA->mailbox might make decisions Any fail in a perfect world means the mail didn't get here in the first place. To have a fail;fail recorded means that someone upstream did not do their job and reject the message. So, if we see a fail;fail and do not also check recipient-isp.com (localhost) is on the same line, the message is wrongly deleted. mailbox->MUA filtering here may put the message into a spam mailbox or delete automatically. Several steps along the way (procmail, spamassassin, Outlook filters) are capable of wrongly deleting the message if: 1) recipient-isp.com is in mark only mode forcing the LDA or MUA decide 2) the hostname is not checked for each Authentication-Results line. -Mike Elliott |