Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an E-card se

> > There's only one mail per malicious subscription.  There's more than one
> > bounce if that same person can send ten e-cards.
> Not true.  The mean person can *attempt* to register ten times.
> Each attempt sends you the confirmation email.
I agree with that.

I would like to clarify several things against the claims of Alex:

1. It is not true that we do not handle the bounces. The script I provided 
on SPF, which is the one we are talking about, _does_ handles bouncing 
e-mails, and it just works wonderfully. It is not true that we can use this 
script to send bounces to anyone. This bounce script checks the X-msgid 
filed generated with the ecard, which contains the ID of the ecard 
(uniqueID), and it is checked against the database entered ecard ID. Already 
here it is almost impossible to guess the proper ecard ID, as it has 16 
chars scrambled random number and letters.
On top of this, the received bouncing email is checked against any recipient 
e-mail address which is in it. It must match the recipient that the 
corresponding ecard sender has put. This makes NO chances at all to use this 
script as a forwarder to bomb an e-mail address, unless someone can prove it 
to me, and Alex didn't. If these two conditions are not met, the e-mail is 
not returned and it is just dropped down.
2. The claim of Alex is more true about our ecard system without the bounce. 
In this case, it is true that people can just enter a fake sender address, 
and send to fake recipients. The bounce script will receive the e-mails 
back, and send an e-mail to the supposed sender, saying that his ecard could 
not be delivered to the displayed address.
However, as stated by Stuart, this 'bombing' capability is exactly the same 
than the proposal of Alex to put cookies, because even with all this system, 
any attempt to subscribe _will_ generate an e-mail back, and I believe even 
that most of those systems do not limit the number of attempts per IP 
address, check for spamlists, unlike our system at edenpics.com!
Therefore, our system is probably even more reliable than Alex's suggestion, 
and at least as good as his.
3. We have plenty of other tests before sending each e-card, almost 10 
checks! We test that the sender's IP address is not part of two spam 
blacklists before each sending. We have the number of ecard limited by IP. 
We have a minimum time delay check between each sent ecard, and several 
other things..
4. We have never had any problem reported in 5 months of work, and I don't 
believe that we should be put on a spamlist, unlike suggested by Alex to all 
the others on this list, I think that this is rather unfair than anything 
else. In this case, Scott (SPF webmaster) should also remove my code sample 
I provided freely for you SPF guys.. and this kindness is rewarded with 
curses! Not good at all!
5. If all this is not enough, we can still add a captcha (random number 
displayed on a gif as verification), which would be much safer than anything 
else and the cookies solution, as nothing at all is sent if the captcha is 
wrong. The spammers would really have to go through the webpage, and they 
would never be able to automate any single e-mail. However, currently I 
believe that our system is safe enough, and if we see some abuses, then we 
will introduce this limitation, which would this time be the ultimate 
solution, and which is the one I suggest for anyone having ecard abuse 
problems with their system.
In conclusion, our system is very safe and cannot be seen as having flaws in 
it and thus Alex' claims are refuted.
I hope this script will make some others happy!

Regards,
Daniel



-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com