Mailing List Archive: Authentication-Results

Authentication-Results

Nov 22, 2007, 12:40 AM

Post #1 of 3 (2889 views)

Hi, the Internet Draft specifying a new header field
Authentication-Results is almost ready. Some of us
likely regret that three years too late is really too
late, but we could still decide to support it as good
idea.

AFAIK the author intends to fix his "results" table:
Sender ID will get the same "smtp.helo" row as SPF,
and there won't be a separate "smtp.ehlo" row for SPF.

Actually there is no difference between Sender ID and
SPF wrt "smtp.mfrom" and "smtp.helo" results, the
draft could unify these rows. Sender ID RFC 4406 got
a normative reference to SPF RFC 4408 about this.

IMO the "security considerations" have to state that
noting "hardfail" results instead of simply rejecting
"hardfail" will cause the loss of legit mails in some
arguably broken scenarios.

Assuming the author fixes this, can we "officially"
support his draft, on behalf of th SPF project ? The
"iprev" check in this draft is quite interesting, and
the draft might also help the SSP-folks ("SSP" is the
keystone of DKIM).

Frank

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Re: Authentication-Results [ In reply to ]

julian at mehnle

Nov 28, 2007, 3:54 PM

Post #2 of 3 (2657 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Hi, the Internet Draft specifying a new header field Authentication-
> Results is almost ready.

Well, good to know!

> AFAIK the author intends to fix his "results" table:
> Sender ID will get the same "smtp.helo" row as SPF, and there won't be a
> separate "smtp.ehlo" row for SPF.

Good. The current table in draft-kucherawy-sender-auth-header-09 seems
weird in those regards.

> Actually there is no difference between Sender ID and SPF wrt
> "smtp.mfrom" and "smtp.helo" results, the draft could unify these rows.
> Sender ID RFC 4406 got a normative reference to SPF RFC 4408 about this.

Agreed.

> IMO the "security considerations" have to state that noting "hardfail"
> results instead of simply rejecting "hardfail" will cause the loss of
> legit mails in some arguably broken scenarios.

You mean "loss" as opposed to "no delivery, but sender gets a bounce"?

> Assuming the author fixes this, can we "officially" support his draft,
> on behalf of th SPF project ? The "iprev" check in this draft is quite
> interesting, and the draft might also help the SSP-folks ("SSP" is the
> keystone of DKIM).

I'm all for it. Have been since day 1. This unified header field is the
way to go.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHTf+cwL7PKlBZWjsRAmT9AKDOUynb5rc1+owjLAAAjUONndDhdACfe5R1
Ev80kjSNBGklDzdhdnLdP9U=
=XdjH
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=69941637-129d9c
Powered by Listbox: http://www.listbox.com

Re: Authentication-Results [ In reply to ]

nobody at xyzzy

Nov 28, 2007, 6:12 PM

Post #3 of 3 (2689 views)

Permalink

Julian Mehnle wrote:

>> IMO the "security considerations" have to state that noting "hardfail"
>> results instead of simply rejecting "hardfail" will cause the loss of
>> legit mails in some arguably broken scenarios.

> You mean "loss" as opposed to "no delivery, but sender gets a bounce"?

I mean moving a mail with "hardfile" annotation into a never checked
(i.e. apparently working) spam folder, from where it's automatically
erased after a month (or similar scenarios). Such FAILs might be the
problem of the receiver, but senders likely prefer a clean reject for
FAIL, instead of a forwarder - receiver - 3rd party Bermuda Triangle.

>> Assuming the author fixes this, can we "officially" support his draft,
>> on behalf of th SPF project ? The "iprev" check in this draft is quite
>> interesting, and the draft might also help the SSP-folks ("SSP" is the
>> keystone of DKIM).

> I'm all for it. Have been since day 1. This unified header field is
> the way to go.

Great, please add it to the Council agenda. I just managed to start a
Jabber client again on the W2K side of a box under my control also on
weekends, but I think we could decide "Council" issues also by mail
(on any SPF list with a public archive, need some URLs as evidence ;-)

The old "other IETF lists" issue also needs a decision, I posted our
questions twice on the IETF IPR list, the answers roughly confirmed
what we thought, if that's still not enough folks have to ask their
lawyer.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=69966466-ed1944
Powered by Listbox: http://www.listbox.com