On 11/7/06, Patrick Peterson <ppeterson(_at_)ironport(_dot_)com> wrote:
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.
<snip>
I apologize for the late post.
(Side note: This email is coming from my gmail address.
However, I am writing this email in my role as compliance /
abuse manager for an e-messaging application service
provider (ESP) known as BigHip.com.)
BigHip has seen its domain both phished and forged.
We perceive that being able to publish an SSP is important.
Hence this post.
Why? BigHip publishes an RFC 2822 sender header to identify
that all email is being sent from its network.
(Side note: This is consistent with best practices for
e-marketers as found in the Canadian Spam Task Force
Report.)
In turn, BigHip signs its mail (presently using DK)
verifying the sender header.
(Side note: we use the domain bighip.com in our RFC 2821
and RFC 2822 headers, except for the RFC 2822 From header.
The client provides the domain for use in the RFC 2822 from
header.)
This approach allows for compliance with best practice,
while making it easy to implement various authentication
technologies, including DKIM, but ....
Only if receivers allow for verification of the sender
header.
As the responsible sender, (even though we are an ESP, the
mail is coming from our network), we can not tell receivers
what to do. It is their network.
But, through the use of an SSP, we can make certain
statements about our policies.
In turn, receivers can, if they wish, take these
statements into account when making decisions about how to
treat mail coming from our network.
Possible SSP statement: -
We sign all mail, verifying the RFC 2822 sender header. No
signature or invalid signature, providing receiver checks
and verifies RFC 2822 sender header and not just RFC 2822
from header, reject with appropriate non delivery receipt
sent at SMTP time. Bad signature, defer with appropriate
non deliver receipt sent at SMTP time, allow for re-send
and delivery.
Accordingly, I am asking that:
* The working group pushes forward with its work on SSP.
* When writing the SSP, the working group takes into
account that there is a group of senders (who mail on
behalf of others) that follow recommended practices by
publishing a sender header, who would like to sign the
sender header, have this signature verified and want to
protect the domain in the sender header from phishing and
forgery attacks.
Thanks,
John
John Glube
Bighip - Compliance / Abuse officer
http://www.bighip.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html