Example of "I send no email"
I want to provide signing to 3rd parties. I will set up a signing.com
domain. signing.com will never send/initiate email and the owner of
signing.com wont have SPF in the house. So a receiver getting a message
purporting to be from signing.com can cheerfully drop the message
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of wayne
Sent: Tuesday, November 07, 2006 11:46 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements
In
<60A9EDD76DBBFE48ABE4FE35324BBB8201B51798(_at_)dooku(_dot_)ironportsystems(_dot_)com>
"Patrick Peterson" <ppeterson(_at_)ironport(_dot_)com> writes:
3 months and 1300 mailing list posts ago, I wrote that I was going to
survey some senders on SSP use cases and report results back to the
list. At long last, here are the results.
Thanks for taking the time to do this. I, for one, appreciate it.
It would also be useful to get similar insight from receivers.
[ ... ] while the challenge of SSP is primarily to
determine
what senders want to communicate to receivers and what receivers want
to
know about senders policies/practices. SSP should provide a vocabulary
to senders that meets their needs and is useful to receivers -- this
is
the most important requirement imho.
I completely agree with this. SSP has to be useful for both senders
and receivers and it is all about communication. You can't dictate
what receivers do, but many receivers *are* interested in hearing what
senders have to say and will take appropriate actions if what the
senders say will benefit them.
Another way to state this requirement is that there is a difference
between,
- I sign all email, and
- I sign all email, treat unsigned or invalid signature with
suspicion,
and,
Can you please explain the difference between the above two? Are you
saying the first one is really "I sign all email, but don't treat DKIM
failures as suspicious"? Or, maybe the question is better phrased,
what is the difference between that and just an "I sign some email"?
- I sign all email AND have enough confidence in the reliability of
signatures AND the risk of allowing spoofed email is high enough that
I
choose to accept the risk and therefore state that receivers should
drop
unsigned/invalid signature email.
OK, as a receiver, can I blame the sender for any problems with
legitimate email being rejected due to DKIM failures? If a receiver
can't transfer the blame to the sender, why should the receiver treat
this any different than just being suspicious?
Mind you, I've argued for this option as being potentially useful. A
sender that discovers that someone is munging their email has options
such as sending with a different subdomain that just says "I sign
some", or working with the receiver to fix the problems, or telling
the receiver they have to change email addresses, etc.
Requirement #2. I send no email.
Many senders have a large number of domains that are never used in
email. They want to be able to state this unambiguously. To the
senders
I surveyed, the 'I send no email' policy is a unique case from the
other
cases. I asked if they wanted this in addition to the SPF/SIDF '-all'
policy and they universally said yes.
Can you explain more about why people want an SSP which says "I send
no email" rather than just having an SPF record of "v=spf1 -all"?
A while back, I changed my opinion on this and I now think that both
are useful. The SPF record covers the 2821.HELO and 2821.MAILFROM,
while SSP covers the 2821.From:. These are all different and there
are cases where a domain can end up in the 2821 identities, but should
never show up in the 2822 identities and vice versa.
-wayne
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html