On Sat, Apr 28, 2007 at 06:35:32PM +0200, dan1 wrote:
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.
True. Please note that I was talking about bounces occuring because
of messages -sent by your ecard service- that could not be delivered.
These will have a proper X-msgid, so your script will see them as valid.
Already here it is almost impossible to guess the proper ecard ID, as it
has 16 chars scrambled random number and letters.
No guessing necessary. You have generated a proper ID.
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.
Did I claim your service could be used to bomb an email address in
the way you just described? I think I didn't.
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.
Yes. And this, nothing more, was my claim. You are sending a bounce
to (for instance) me, but I did not request the ecard to be sent.
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.
Each attempt to subscribe would result in one message generated by
your site, and the message would/should contain a brief statement
like
"someone at 192.0.2.1 requested that email address user(_at_)example(_dot_)org
is subscribed to our service. Please acknowledge that you want to
... etc. yada yada".
Ecards can be sent to more than one email address. Each address could
result in a bounce. One card sent, multiple bounces.
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..
And I was not saying you weren't "a good guy". I just expressed my
feeling about a fundamental way of thinking related to SPF:
Sender address forgery should be banned.
I still say your site makes it easy, not hard, to generate backscatter.
That doesn't mean that you aren't doing much good work. It just means
that there's still more work to do. And that is what I said earlier.
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
?!?!?!? When ? Where ?
You feel offended by my remark, that's clear. Please put your emotions
aside and *read* my message. Do not read inbetween the lines, as that
is just whitespace.
Please do not put words in my mouth again. I have done nothing bad, and
I have certainly not done the things you claim I did.
Alex
-------------------------------------------
-----------------------------------------------------------------------
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