[itu-sg16] Spam control mechanisms
Folks,
Gary mentioned in his last message that he had trouble sending e-mail due to anti-spam settings. Indeed, I have a few things in place to reduce spam on this mailing list which I hope you can generally appreciate.
One of the mechanisms employed is something called SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework) as specified in RFC 4408. As noted in the RFC, it is experimental and not strongly endorsed by the IETF for one reason (as far as I can tell): you cannot forward mail from one account to another if SPF is used on the receiving server, as it will assume the message is in violation of the SPF rules. Even so, I've observed that industry adoption for SPF is significant.
I thought I would bring this to your attention. If you get SPF rejection messages when sending e-mail to this server, then it means that you are transmitting e-mail from an IP address that is not authorized by your domain owner. Hopefully, this is not an issue for folks, but it might be if you send mail through a server which you do not normally send mail through.
I can disable SPF checking if it presents unavoidable problems for anybody. I would prefer to not do that, because the extensive testing I have done shows that it reduces my own personal spam by 28%. That's substantial considering the quantity of the fine quality product and service offerings I get each day ;-)
Paul
Dear Paul,
The IETF has (finally) published DKIM as RFC 4871. DKIM does not suffer the sorts of problems you mention, with regard to SPF. Furthermore, it is not classed as experimental but as a Proposed Standard. It was co-written by, amongst others, the creator of sendmail and syslog, Eric Allman, and is based on Yahoo! Domain Keys and Cisco's Identified Internet Mail (IIM).
DKIM works through domain-based signatures that are published in the DNS as TXT records, and so is path-independent. It also protects message content, thus preventing hijacking of one's email address for nefarious purposes. I recommend that you consider DKIM in addition to, or as an alternative to, SPF.
Eliot Lear Cisco Systems
Paul E. Jones wrote:
Folks,
Gary mentioned in his last message that he had trouble sending e-mail due to anti-spam settings. Indeed, I have a few things in place to reduce spam on this mailing list which I hope you can generally appreciate.
One of the mechanisms employed is something called SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework) as specified in RFC 4408. As noted in the RFC, it is experimental and not strongly endorsed by the IETF for one reason (as far as I can tell): you cannot forward mail from one account to another if SPF is used on the receiving server, as it will assume the message is in violation of the SPF rules. Even so, I’ve observed that industry adoption for SPF is significant.
I thought I would bring this to your attention. If you get SPF rejection messages when sending e-mail to this server, then it means that you are transmitting e-mail from an IP address that is not authorized by your domain owner. Hopefully, this is not an issue for folks, but it might be if you send mail through a server which you do not normally send mail through.
I can disable SPF checking if it presents unavoidable problems for anybody. I would prefer to not do that, because the extensive testing I have done shows that it reduces my own personal spam by 28%. That’s substantial considering the quantity of the fine quality product and service offerings I get each day ;-)
Paul
Eliot,
Thanks for the heads up. I knew it was coming, but didn't know the RFC was published; it is extremely recent. It has been a while since I initiated use of SPF and I've not been following the progress of DKIM.
I can see that Sendmail has published a milter to support it, which is encouraging. When I get a spare moment, I'll definitely look into it.
Paul
-----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Saturday, May 26, 2007 9:53 AM To: Paul E. Jones Cc: itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Spam control mechanisms
Dear Paul,
The IETF has (finally) published DKIM as RFC 4871. DKIM does not suffer the sorts of problems you mention, with regard to SPF. Furthermore, it is not classed as experimental but as a Proposed Standard. It was co-written by, amongst others, the creator of sendmail and syslog, Eric Allman, and is based on Yahoo! Domain Keys and Cisco's Identified Internet Mail (IIM).
DKIM works through domain-based signatures that are published in the DNS as TXT records, and so is path-independent. It also protects message content, thus preventing hijacking of one's email address for nefarious purposes. I recommend that you consider DKIM in addition to, or as an alternative to, SPF.
Eliot Lear Cisco Systems
Paul E. Jones wrote:
Folks,
Gary mentioned in his last message that he had trouble sending e-mail due to anti-spam settings. Indeed, I have a few things in place to reduce spam on this mailing list which I hope you can generally appreciate.
One of the mechanisms employed is something called SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework) as specified
in
RFC 4408. As noted in the RFC, it is experimental and not strongly endorsed by the IETF for one reason (as far as I can tell): you
cannot
forward mail from one account to another if SPF is used on the receiving server, as it will assume the message is in violation of
the
SPF rules. Even so, I've observed that industry adoption for SPF is significant.
I thought I would bring this to your attention. If you get SPF rejection messages when sending e-mail to this server, then it means that you are transmitting e-mail from an IP address that is not authorized by your domain owner. Hopefully, this is not an issue for folks, but it might be if you send mail through a server which you do not normally send mail through.
I can disable SPF checking if it presents unavoidable problems for anybody. I would prefer to not do that, because the extensive testing I have done shows that it reduces my own personal spam by 28%. That's substantial considering the quantity of the fine quality product and service offerings I get each day ;-)
Paul
participants (2)
-
Eliot Lear -
Paul E. Jones