Martynas Bendorius wrote:

"Messages will NOT be sent to the recipients. A copy of the composed mail will be stored in the Sent folder." isn't translated (there is no such sentence in language files).

This is hard coded for the demo. It has nothing to do with the real application and I don't see any reason to bother the translators with it.

~Thomas

On Tue, 08 May 2007 16:16:56 +0300, Zdravko Stoychev zdravko@5group.com wrote:

Hi all! Are there any plans to implement SPF-checks in RC? http://www.openspf.org/

Shouldn't this be a MTA task? Or possibly whatever anti-spam solution used.

At least this is the way I use SPF on my servers. I can see how it can be beneficial at the MUA level to a degree, but it could generate a lot of DNS traffic for every message. Caching nightmare either for Roundcube, or the requirement for a local caching name server.

Not something I would like, but perhaps that's just me.

Perhaps suitable as a plugin, once the plugin API is finished?

Could be quite simple to implement using libspf2.so and just one function call. http://www.libspf2.org/

Or just check for Header Fields related to it as "Received-SPF:") in order to notify mail reader about "MAIL FROM:" forgery? Or at least, option to mark messages as spam if SPF: FAIL is detected in the Header. Most of the biggest mail providers as Hotmail, Google etc. and lot of Enterprise/personal mail servers have SPF implemented, including mail servers as Sendmail, MS Exchange, Qmail, Exim, so this is really good thing to have. Microsoft have added support for it with their own RFC http://www.microsoft.com/senderid

Could be handy if it was working with the headers. That would add very little overhead. Once again, a lot of this could be dealt with at the MTA level.

Please note that while MS' SenderID is loosely base on SPF, it is not the same.

See also: http://www.ietf.org/rfc/rfc4408.txt

Regards! Dako

Yes, sure, but _just because_ it is so simple to be implemented (only one func call to libspf2.so providing MAIL FROM and sender's IP address) and because some of the Mail Servers do not implement such support, RC could offer as _an option_ this check by itself. By default this might be disabled, even at compile time (one have to use --with-spf to enable it).

Moreover, the headers check still could be implemented, so if the MTA supports SFP, then RC could show this important analysis information to end-users. Same could be done with SpamAssassin headers too (again as an option in user preferences).

p.s. Hm Sorry I've started new thread under martynas's one.

I agree it is no the mail clients job to do SPF checking even by checking the headers. All major MTAs have abilities to handle spf checking along with spamassassin.

-Chris

Craig Whitmore wrote:

...

Hi all! Are there any plans to implement SPF-checks in RC? http://www.openspf.org/

SPF should only be checked at the MTA, not the mail reader.

Thanks

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete this material from any computer.

In accordance with industry regulations, all messages are retained and are subject to monitoring.

This message has been scanned for viruses and dangerous content and is believed to be clean.

Securities offered through Cantella & Co., Inc., Member NASD/SIPC. Home Office: 2 Oliver Street, 11th Floor, Boston, MA 02109 Telephone: (617)521-8630