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

> > 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.
Yes, this way you can bomb an e-mail adress that you enter yourself as a 
fake sender, but again this would be only for a few e-mails, before our 
service would block your next ecards due to the IP based number limitation. 
Thus, any automated bombing isn't possible, which is really the worst think. 
Yet a personnal bombing of a few emails is possible, but wouldn't offend the 
victim so much. Seen from that point of view, this system is not more 
dangerous than a mailing list service which sends confirmation messages to 
anyone who is just asking for, even if the address is a wrong one. If this 
is blamable, then you must also blame all other mailing list subscription 
systems for providing the same flaw, and even probably in an automated 
manner, and yet nobody never complains about this neither, so this is why we 
should lower this 'problem' potential to my opinion.
> > 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.
I was triying to know, but you were not willing to "clean my mess", so it 
was difficult to know, but it seemed to. I asked you to clarify but you 
didn't want.
You said that there would be more work to do to. This is true for the way 
people are allowed to send an ecard, but not as for the script itself, this 
was probably a bit confusing.

> > 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".
This is one thing you probably didn't get right: an e-mail is still sent 
with your solution, and therefore you can still bomb an e-mail address your 
way almost as it would be with my system, except that you would have less 
returns than I would if several addresses are wrong. However this last 
problem could also be solved by marking each wrong email address and then 
return only one bounce email to the user with all failures. I think that it 
is not necessary as for now, but could be something to improve if really 
needed.

> Ecards can be sent to more than one email address.  Each address could
> result in a bounce.  One card sent, multiple bounces.
Yes, this is true, please see the last comment.

> > 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.
This is interesting, because the SPF technical web page with the best 
practices suggests to do exactly the way I did, so I am surprised that you 
say it is fundamental to SPF that the sender address forgery is banned. 
Please read again this page which encourages to do so, yet by specifying 
exactly what server DID the forgery, so that we can return to them in case 
of address errors or problems:
http://www.openspf.org/Best_Practices/Webgenerated

This is probably where we conflict: I think to have done things as suggested 
on this page, but you seem to be blaming me for having done things this way, 
generally speaking. Of course I could understand your point of view, but in 
this case it should be discussed further with other SPF people.

> 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.
Yes, I can agree with it, yet the more work to do is, I think you agree, 
only for the way people are allowed to send an ecard, and not for the script 
I provided. This is what I would like to emphasis. The way people allow 
others to send an e-card is not covered in the SPF best practices, so we 
should speak about this in another context, and rise up more discussions. I 
am trying to separate what is related to the script which first seemed to be 
blamable, and the way we accept people to send ecards and I think it is 
important to make the difference.

> > 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 ?
04.28:
"I can, using your ecard service, send bounces to anyone.  If you think
this is appropriate, then please think again. I, and I hope others, will 
report such bounces to spamcop."
Reporting the service bounces to spamcop does certainly push them to mark my 
server as a spammer box. Maybe it was not your intent to say this, but it 
can really be interpreted like 'I wish your server is placed as a spam 
server'.
And again, I think you would be right if you could automate this bombing, 
yet you could only do several bounces and would be limited, and this makes 
the whole difference.
> 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.
I asked you for constructiveness, and you answered harsh. It's sad you 
cannot recognise it. If some things I said were not right about your claim, 
then I believe that the precisions I asked you for would have avoided to be 
mislead, if it is really the case.
Anyway, thanks for trying to warn about a potential problem there might be 
with mail forgery and yet this is maybe something to talk more about with 
the community instead of with me, even if I know it was just a suggestion at 
first.
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