Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an E-card service server
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
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!
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
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com