Hello, Alex.
Now I understand what you did.
I really received the ecard back, but yet it was not due to a bounce. It was
because you chose to send yourself a copy of the ecard (which is an option
on our site). This option just sends the ecard to the sender, as it does it
for the receiver.
As you have put my email address, it is normal that it comes to me, but yet
the bounce script did detect the bounce and handle it properly. I have
received another email from my script saying that the recipient
'doesnotexist(_at_)office(_dot_)vandenbogaerdt(_dot_)nl' was wrong, so it seems to be working
the right way to my opinion.
Else, as already said, I believe that this isn't a real threat, as there is
an IP limitation in our ecard generating script, and also because the
spammers couldn't really use the canvas of the ecards to have the impact
they are seeking. They could just abuse any other ecard service the same
way.
Could you please still tell me if you think that there is something
suspicious with the log lines that you have seen on your server?
Please have a look to the sample code I used in itself here at the bottom:
http://www.openspf.org/Best_Practices/Webgenerated
Thanks for your input,
Daniel
----- Original Message -----
From: "Alex van den Bogaerdt" <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, April 27, 2007 10:26 PM
Subject: Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an
E-card service server
On Fri, Apr 27, 2007 at 09:10:14PM +0200, dan1 wrote:
Hello, all.
Thanks to your suggestions, I have now been able to rewrite our E-card
service so that it is compliant with SPF.
It seems to be going through the SPF as stated by one of our complaining
customer.
If you would be willing to add it to the SPF-compliant E-card services, I
would be pleased.. the link is www.edenpics.com, and there is no banner,
spam lists, spies or anything..
It was quite combersome, because I had to handle the bounces back, which
is all that is difficult when we change the sender address. This is very
important, else people won't know that their e-card was not received. I
had to scratch my head some hours to be able to make it work the right
way, but using sendmail and smrsh I finally got it with a php script.
I'm afraid you have a little more to do.
You are _not_ handling bounces. You are offloading that job to some
random user whose email address was selected by the person abusing your
service.
For educational purposes I'm going to send you a bounce. I'm sure you'll
understand.
Apr 27 22:06:17 a postfix/smtpd[4266]: connect from
edenpics.com[154.37.1.234]
Apr 27 22:06:25 a postfix/smtpd[4266]: NOQUEUE: reject: RCPT from
edenpics.com[154.37.1.234]: 550 <$rcpt_email_address_deleted>: Recipient
address rejected: User unknown in local recipient table;
from=<ecard-bounce(_at_)edenpics(_dot_)com> to=<$rcpt_email_address_deleted>
proto=ESMTP helo=<anoigo.edenpics.com>
Apr 27 22:06:37 a postfix/smtpd[4268]: connect from
edenpics.com[154.37.1.234]
Apr 27 22:06:37 a postfix/smtpd[4268]: NOQUEUE: reject: RCPT from
edenpics.com[154.37.1.234]: 550 <$sender_email_address_deleted>: Recipient
address rejected: User unknown in local recipient table;
from=<mail(_at_)anoigo(_dot_)edenpics(_dot_)com> to=<$sender_email_address_deleted>
proto=ESMTP helo=<anoigo.edenpics.com>
At least now it is you sending this misdirected bounce, not some other
random user also being selected by the abuser.
Not related to this list, but a recommendation anyway:
Ask people to confirm their email address by confirmed opt-in. It could
work like so:
[note: by "cookie" I do not mean a browser cookie, but a semi-random
string which is not easily guessed and changes depending on the user's
email address, time of day, etc.]
1) display some cookie on your site.
2) user sends an email, containing the cookie, to a special mailbox at
your site, asking to become a member.
3) you send an email back, containing another cookie, asking the user to
confirm. Do explain that someone asked for your invite, and be sorry if
the user at ip address ppp.qqq.rrr.sss abused your service. Show headers,
so that the victim can complain to the abuser instead of to you.
4) user replies with the 2nd cookie, thereby confirming that he does
actually use the email address he entered on your site.
5) Return a password to the user.
6) Let the user login, using his email address and the password.
The 1st cookie is to hinder spambots and alike.
The 2nd cookie is to protect your own service from bad guys abusing your
service. This cookie has to be secure, it should not be easily guessed.
HTH
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
-------------------------------------------
-----------------------------------------------------------------------
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