ietf-mxcomp
[Top] [All Lists]

Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd)

2004-09-16 17:10:09

Murray S. Kucherawy wrote:

sender-id, SPF and DomainKeys are only done at the border
inbound but an internal message was injected for which the
client authenticated using SMTP AUTH, I felt that fact
should be relayed should the MUA or LDA wish to make a
decision based on it.

Sure, I was only confused because in your example the very
same host did both (MSA auth stuff + MX SPF tests).  Maybe
split it in two headers.  That would also demonstrate cases
where spammers could send forged Authentication-Results.

Out of curiosity, I use an MSA enforcing a valid MAIL FROM.
This MSA uses SMTP-after-POP (and before you laugh, that's
not much worse than insecure PLAIN or LOGIN).  What are the
corresponding Authentication-Results ?  Here's my guess:

| Authentication-Results: mail2.hamburg.example
|   return-path=m-e(_at_)hamburg(_dot_)example; auth=pass (pop3)

Is that the idea ?  Or should the MSA match the POP3 mechanism
to a corresponding SMTP AUTH, (login) in my example.  But IIRC
"login" isn't documented in any RfC.  And officially "plain"
isn't allowed without TLS.  SMTP-after-APOP would be better
than "login" or "plain", so maybe you need some additional
keywords like "tls", "login" or "apop" for auth.

Actually you don't need the "pass" for auth, let alone any
other weird SPF results, auth=apop or auth=cram-md5 should
be good enough.

For SPF the tested header at the moment implicitly defines
the tested scope.  Return-path is always spf2.0/mailfrom,
helo is always spf2.0/helo.  Anything else (from, sender,
resent-*) is always spf2.0/pra.

Therefore you could simply use header=mailbox spf=result
for spf2.0/helo, spf2.0/mailfrom, and spf2.0/pra.  "Helo"
is no header, but it fits in your "headerspec" syntax, if
you define "headerspec" in the next draft ;-)

This simplification won't work for Wayne's spf2.0/from,
because then a tested "from" either corresponds to a PRA
or to Wayne's draft.

IMHO you don't need a list of SPF results, that's defined
in protocol-03, and rather useless for "auth".  You could
add a section how MUAs can try to auto-detect the support
of this header by their MDAs (Outlook uses test messages
for similar purposes).
                        Bye, Frank