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=2183229&id_secret=69966672-6545ff
Powered by Listbox: http://www.listbox.com