any plans for spf?

[CTone]

As with SG one can start a mail interchange (i.e., sending "from" an SG disposable, it would be wise to be prepare for spf ...


http://spf.pobox.com/howworks.html


Any hints?

[SysKoll]

I think SPF will break forwarding. In particluar, the address masking feature of sg would stop working. We'd have to switch to remailing, while preserving information about the masked address. I don't know how to do this.

Besides, is it really useful? About 30% of the spam out there now complies with SPF. SPF only helps curbing Joe Jobs (fake "From:")

[CTone]

Perhaps I did understood wrongly ...

From the news part of SG web (I have not seen this told in the faq or whatever):

"After much brainstorming, hand-wringing, [...] we've turned on the feature that allows you to send the first message to someone in a way that substitutes your real email address for one of your disposable addresses. [...] the system will give you one of those address like you see when you have reply address masking turned on. When you send a message to this address, it'll work just like when you reply to a message that was sent to you through reply address masking. [...]

Well, I do not know if this is "forwarding" or "remailing":

From what I understand, forwarding keeps original data from sender (such as domain-machine-name, ip, and "from email address").

I hope that SG performs better (will have to check ...):
at least, any trace of my "from email address" should be dropped, if not also my domain-machine-name and ip.

In this sense, I expect SG to be more like "remailing" (ala mixmaster ...):
My MUA will contact SG SMTP. SG will do its magic, and then SG (same or other) SMTP will "mail" to the recipient´s MTA.

SPF scheme is ideal for ISPs, I foresee it exploding (also with hashcash); In this scenario, SPF related to SG should not break anything ... again if it works as I understood:

I am ISP A.
a) Receive an email from fromuser@ispB for touser@ispA
b) check if ispB has a SPF registered policy
c1) if yes, I check if incomming mail comes from authorized (IP) machines; If ok, then accept email. Otherwise No
c2) if not, ... do what my SLA with user says (perhaps do not accept the mail).

Then, for this to work, ISP B has to have a registered SPF policy.

I believe this might explode as it is not only avoiding "from fakes" but also any spam comming from any open relay or the like.

So, what I mean that other sites might stop spamgourmet outgoing mails if spamgourmet is not SPF "compliant" (that is, a declaration saying that SG mails
[that is, whateveritis.number.user@spamgourmet.com] will only come from a MTA with IP numbers this and that)

I am not saying that Spamgourmet should implement SPF restriction for its users outgoing mails. This would be catastrophic.

I am not even suggesting that Spamgourmet blocks incomming mails if they are not SPF compliant, but could be interesting if this eliminates 30% of spam ...

According to SPF faq at http://spf.pobox.com/faq.html#allsmtp it is *NOT* based on faked froms detection, what it makes:

===============

"SPF was designed to protect the envelope sender. That means the return-path that shows up in "MAIL FROM", and to a lesser extent the HELO argument that is supposed to be an FQDN.

The vast majority of SPF implementations today use the return-path as the subject of authentication and do not get involved with the header "From:".

Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys.

If you want to use the "From:" header as the subject of authentication with SPF, you need to be familiar with the following:

mailing lists
/etc/aliases-style forwarding
MUA "resend this message to"
web-generated email
the Sender header
the Resent-Sender and Resent-From headers"

==========================

Also important is (from faq)

==========================
Does SPF break email forwarding?

Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also."
==========================

Please note that they call forwarding to what I call forwarding ...

Finally, for something completely different it would be also a nicety if SG could also interoperate with hashcash (http://www.hashcash.org/)

Hashcash is an idea add "payed stamps" to emails, so spammers economy is broken. The "pay schema" is not based in money but in ith CPU time: the sender of an email has to perform some CPU time consuming operations based on the receiver email address and the time of sending and same salt. The receiver easily checks if the "stamp" is valid. If not, might choose to kill the mail.

The stamp is added in an X-hashcash header.

The paradigm has also (as SPF) been embraced by SpamAssassin.


How it could work with SG?

Incoming mails

Well, it could check incoming mails "stamps". And according to users "settings", for example: accept valid incomming mails if stamp is ok even if inbox has 0 incomming messages allowed ... or to make it work as a trusted /allowed sender ... If invalid stamp ... spam! If no stamp ... business as usual now.

More important:

Outgoing mails from SG: compute the stamp (this will be rather complex for the SG user, the sender, as he will be using masking ..., lack of tools, complexity of adding the x-hashcash header ...


Well, all the best for SG future ...


Thanks again ...