Mailing List Archive

(SOLVED) SPF blocking e-mails coming from an E-card service server
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.

Thanks again to all.
Regards,
Daniel - Edenpics.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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Fri, 27 Apr 2007, dan1 wrote:

> 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.

Great!

> 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 hope you added some kind of changing hash token to localpart of MAIL FROM so
that spammers can't use your service as an open bounce relay.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan,

you wrote:
> 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.

Glad to hear that!

> If you would be willing to add it to the SPF-compliant E-card services,
> I would be pleased.

We aren't listing all kinds of services that are SPF compliant because the
list would eventually grow huge, and also those services' target audiences
wouldn't be looking at that list anyway.

I have even been considering us stopping listing SPF-enabled proprietary
products[1] because the list is going to get too long as SPF support
becomes common.

> 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.

Glad you got it to work.

References:
1. http://www.openspf.org/Implementations

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGMloEwL7PKlBZWjsRAvXXAKCHhFXaKfuEW9izkq3Ty8BIjVKBBgCgxcfS
jZ6qDB3/K5gfNDdRvM+Zxr0=
=JRra
-----END PGP SIGNATURE-----

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
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@edenpics.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@anoigo.edenpics.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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
Hello, Stuart.

>I hope you added some kind of changing hash token to localpart of MAIL FROM
>so
>that spammers can't use your service as an open bounce relay.

Humm... no not really, and I wouldn't know how to do this.
However I am checking the database to know if the destination addresses are
right, and also to know the source e-mail address where it can be the only
destination.
The spammer should also probide the exact proper ecard ID, which is
difficult to guess.
I have used a personnalised header (I didn't find any other) 'X-msgid' to
pass the ecard ID. I check against this header in the script and with the
db.

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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Fri, 27 Apr 2007, dan1 wrote:

> >I hope you added some kind of changing hash token to localpart of MAIL FROM
> >so
> >that spammers can't use your service as an open bounce relay.
>
> Humm... no not really, and I wouldn't know how to do this.
> However I am checking the database to know if the destination addresses are
> right, and also to know the source e-mail address where it can be the only
> destination.
> The spammer should also probide the exact proper ecard ID, which is
> difficult to guess.

That will do it as far as blocking spammers. Good job. You may have problems
with recipients who "helpfully" remove all "unneeded" headers from bounces to
make them "friendly". (I have ... mumbles disgusted insults under breath
against these MTA "programmers")

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
> On Fri, 27 Apr 2007, dan1 wrote:
>
>> >I hope you added some kind of changing hash token to localpart of MAIL
>> >FROM
>> >so
>> >that spammers can't use your service as an open bounce relay.
>>
>> Humm... no not really, and I wouldn't know how to do this.
>> However I am checking the database to know if the destination addresses
>> are
>> right, and also to know the source e-mail address where it can be the
>> only
>> destination.
>> The spammer should also probide the exact proper ecard ID, which is
>> difficult to guess.
>
> That will do it as far as blocking spammers. Good job. You may have
> problems
> with recipients who "helpfully" remove all "unneeded" headers from bounces
> to
> make them "friendly". (I have ... mumbles disgusted insults under breath
> against these MTA "programmers")

Hello, Stuart.

Yes, I have been fighting a long time to find any specific and tolerated
header which can contain any valid ecard ID number, but didn't find any.
however the rfc states that we are allowed to put just any X-.. headers as
we want it so I believe that it is rfc compliant.

If somebody knows about a specific header for this, I would be glad to
know...

Thanks,
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
Hello, Alex.

Thanks for the interesting feedback.
I didn't understand everything though.

Have you been sending the 'here's your bounce' ecard to my address?
I didn't really understand how you did it.
It is just like if you would have sent me a normal e-card, but this was not
what you did, right?

I didn't understand the two log lines you provided. It seems that they are
the ones which were bouncing to the failing address, right?

I understand your suggestion about the cookies, and I thank you for this
solution, but I am a bit reluctant as it is too cumbersome for the customer.
I seek a way he can send e-cards just as with any other e-card service.
Also, if anyone abuses my system, they won't go very far as they are limited
to only a few e-cards per IP adress.

However, please talk a bit more about the bounce and the 'here's your
bounce' mail you sent me, is this to you a flaw in my code?

Thanks in advance. We will probably release this code on SPF as an example
if it works, as Scott asked me to.

Daniel


----- Original Message -----
From: "Alex van den Bogaerdt" <alex@ergens.op.het.net>
To: <spf-discuss@v2.listbox.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@edenpics.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@anoigo.edenpics.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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
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@office.vandenbogaerdt.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@ergens.op.het.net>
To: <spf-discuss@v2.listbox.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@edenpics.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@anoigo.edenpics.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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Fri, Apr 27, 2007 at 11:43:04PM +0200, dan1 wrote:

> 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?

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. I did _not_
send that email and I do not wish to be bothered about failures. It is
your service, not mine, and you should clean up your mess, not I.

If this sounds harsh, then it is because you do not receive enough
misdirected bounces yourself.

My opinion.
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Fri, 27 Apr 2007, dan1 wrote:

> However, please talk a bit more about the bounce and the 'here's your
> bounce' mail you sent me, is this to you a flaw in my code?

Alex is complaining that you don't verify the alleged MAIL FROM entered
by a user on your site. He would like you to make all users have
an account on your site, confirmed by sending them an email with a
confirmation token (cookie) which they have to send in a reply or
enter on your website. This is standard procedure for creating accounts
with confirmed email addresses. Then you can be sure the user really has that
MAIL FROM when he sends e-cards.

I'm not sure Alex's complaint is justified. Let's compare, assuming
a mean person enters your email as the MAIL FROM just to annoy you:

Your way: you get a bogus bounce for each e-card sent by the meanie.

Alex's way: you get a bogus bounce for each time the meanie enters
your email to create an account.

In both cases, you already limit the number of time they can do that by IP.

I don't see the advantage to requiring accounts, Alex.


Musings: This business of e-card web sites sending the email is
all wrong. The site should generate an e-card for you, then you download
or link to the generated card and email the user yourself. (Of course
if M$ tries to make this convenient, then an e-card site will be able to do
mass mailings every time an Outlook user connects.)

I have seen sites where the email has a link that expires in 30 days,
and I have to click on the link to see the card. That link could be sent
directly by the sender.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
RE: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
} -----Original Message-----
} From: Stuart D. Gathman [mailto:stuart@bmsi.com]
} Sent: Saturday, April 28, 2007 12:21 AM
} To: spf-discuss@v2.listbox.com
} Subject: Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an E-
} card service server
}
} On Fri, 27 Apr 2007, dan1 wrote:
}
} > However, please talk a bit more about the bounce and the 'here's your
} > bounce' mail you sent me, is this to you a flaw in my code?
}
} Alex is complaining that you don't verify the alleged MAIL FROM entered
} by a user on your site. He would like you to make all users have
} an account on your site, confirmed by sending them an email with a
} confirmation token (cookie) which they have to send in a reply or
} enter on your website. This is standard procedure for creating accounts
} with confirmed email addresses. Then you can be sure the user really has
} that
} MAIL FROM when he sends e-cards.
}
} I'm not sure Alex's complaint is justified. Let's compare, assuming
} a mean person enters your email as the MAIL FROM just to annoy you:
}
} Your way: you get a bogus bounce for each e-card sent by the meanie.
}
} Alex's way: you get a bogus bounce for each time the meanie enters
} your email to create an account.
}
} In both cases, you already limit the number of time they can do that by
} IP.
}
} I don't see the advantage to requiring accounts, Alex.
}
}
} Musings: This business of e-card web sites sending the email is
} all wrong. The site should generate an e-card for you, then you download
} or link to the generated card and email the user yourself. (Of course
} if M$ tries to make this convenient, then an e-card site will be able to
} do
} mass mailings every time an Outlook user connects.)
}
} I have seen sites where the email has a link that expires in 30 days,
} and I have to click on the link to see the card. That link could be sent
} directly by the sender.

I agree, but I have extra reasons. I hate it when someone gives some web
site my email address. In many cases these sites just want to collect email
addresses to sell or abuse (IMO). I believe that is why ecards were
invented! I tell people to just email me the link to whatever and I will
look. But they never listen. They just click "email to a friend". Some
friend!

Guy

}
} --
} Stuart D. Gathman <stuart@bmsi.com>
} Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-
} 6154
} "Confutatis maledictis, flammis acribus addictis" - background song for
} a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Sat, Apr 28, 2007 at 12:21:12AM -0400, Stuart D. Gathman wrote:

> Your way: you get a bogus bounce for each e-card sent by the meanie.

Which is rate limited, fine, but still is more than one with relatively
little effort.

> Alex's way: you get a bogus bounce for each time the meanie enters
> your email to create an account.

Not just an email address. See cookie #1. More effort and less result.

There's only one mail per malicious subscription. There's more than one
bounce if that same person can send ten e-cards.

(BTW it's not a bounce, it is a message which is sent in "my way")


> In both cases, you already limit the number of time they can do that by IP.
>
> I don't see the advantage to requiring accounts, Alex.

* General principle: know who is using your service. In this case,
knowing the (verified) email address is good enough.
* One mail (per try) instead of more than one bounce (per email
address, IP address)
* Sending unsollicited mail is bad, but the following example at least
sucks less than a misdirected bounce:
"
Someone, presumably you, asked us to send this invite. The request came
from $IP_ADDRESS ($RDNS). If this is not you, please accept our apologies
and please complain to their ISP.

If you reply to this message, leave the subject int... yadda yadda yadda
"

I'm sure I can think of more if I really try.

cheers
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
>I agree, but I have extra reasons. I hate it when someone gives some web
>site my email address. In many cases these sites just want to collect
>email
>addresses to sell or abuse (IMO). I believe that is why ecards were
>invented! I tell people to just email me the link to whatever and I will
>look. But they never listen. They just click "email to a friend". Some
>friend!
>
>Guy

Guy, I agree with you.
However, this is not the case on our site, and it is stated clearly for the
user.
The only ecard system I can trust is mine, but I do react the same way than
yourself for all the others. They are plenty of advenrtisements and
everything
else, and this smells a lot about money, and email collection.
We don't do that on our site.
In any case, even if we put the cookie security like described by Alex, the
problem
remains exactly the same, as the server can still keep the e-mails of the
sender and
receivers. Therefore this is not an extra reason to my opinion.

Cheers,
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Sat, 28 Apr 2007, Alex van den Bogaerdt wrote:

> 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.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
>> 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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
I would just like to say that I think that if we are going to have sites like
e-card sites, what Dan is trying to do here is the right thing.

Unless someone comes up with a way to request sign-up verification for an
e-mail address without actually sending an e-mail, I think it's inevitable
that someone will be able to attempt to sign someone up for an e-mail related
service.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
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
RE: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
} -----Original Message-----
} From: Scott Kitterman [mailto:scott@kitterman.com]
} Sent: Sunday, April 29, 2007 11:32 AM
} To: spf-discuss@v2.listbox.com
} Subject: Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an E-
} card service server
}
} I would just like to say that I think that if we are going to have sites
} like
} e-card sites, what Dan is trying to do here is the right thing.
}
} Unless someone comes up with a way to request sign-up verification for an
} e-mail address without actually sending an e-mail, I think it's inevitable
} that someone will be able to attempt to sign someone up for an e-mail
} related
} service.
}
} Scott K

Dan/e-card sites could generate a key and email address and request you send
the first email to register. The ecard could use SPF and whatever else to
verify that the email is not forged. Then it would send an email with a
confirm link or whatever they would normally do.

Guy

-------------------------------------------
-----------------------------------------------------------------------
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
RE: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Sun, 29 Apr 2007 11:57:34 -0400 "Guy" <spf@watkins-home.com> wrote:
>} -----Original Message-----
>} From: Scott Kitterman [mailto:scott@kitterman.com]
>} Sent: Sunday, April 29, 2007 11:32 AM
>} To: spf-discuss@v2.listbox.com
>} Subject: Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an
E-
>} card service server
>}
>} I would just like to say that I think that if we are going to have sites
>} like
>} e-card sites, what Dan is trying to do here is the right thing.
>}
>} Unless someone comes up with a way to request sign-up verification for an
>} e-mail address without actually sending an e-mail, I think it's
inevitable
>} that someone will be able to attempt to sign someone up for an e-mail
>} related
>} service.
>}
>} Scott K
>
>Dan/e-card sites could generate a key and email address and request you send
>the first email to register. The ecard could use SPF and whatever else to
>verify that the email is not forged. Then it would send an email with a
>confirm link or whatever they would normally do.
>
Wouldn't stop people from signing you up on the web for the signup mail.

Our web site describes best practices for web generated mail. AFAICT, Dan
has done all we asked and even donated code to make it easier for others to
do the same. What he's gotten in return is a large ration of grief.

Personally I'm very dissapointed in the community's reaction to Dan trying
to do the right thing.

If we need a best practice on validation of web entered e-mail addresses,
let's write it up and get some consensus. Let's quit berating Dan for not
doing stuff we haven't even bothered to write down.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
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
RE: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
} -----Original Message-----
} From: Scott Kitterman [mailto:scott@kitterman.com]
} Sent: Sunday, April 29, 2007 12:50 PM
} To: spf-discuss@v2.listbox.com
} Subject: RE: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an E-
} card service server
}
} On Sun, 29 Apr 2007 11:57:34 -0400 "Guy" <spf@watkins-home.com> wrote:
} >} -----Original Message-----
} >} From: Scott Kitterman [mailto:scott@kitterman.com]
} >} Sent: Sunday, April 29, 2007 11:32 AM
} >} To: spf-discuss@v2.listbox.com
} >} Subject: Re: [spf-discuss] (SOLVED) SPF blocking e-mails coming from an
} E-
} >} card service server
} >}
} >} I would just like to say that I think that if we are going to have
} sites
} >} like
} >} e-card sites, what Dan is trying to do here is the right thing.
} >}
} >} Unless someone comes up with a way to request sign-up verification for
} an
} >} e-mail address without actually sending an e-mail, I think it's
} inevitable
} >} that someone will be able to attempt to sign someone up for an e-mail
} >} related
} >} service.
} >}
} >} Scott K
} >
} >Dan/e-card sites could generate a key and email address and request you
} send
} >the first email to register. The ecard could use SPF and whatever else
} to
} >verify that the email is not forged. Then it would send an email with a
} >confirm link or whatever they would normally do.
} >
} Wouldn't stop people from signing you up on the web for the signup mail.

How would you sign up with my email address if you had to send the first
email as me and the e-card used SPF?

} Our web site describes best practices for web generated mail. AFAICT, Dan
} has done all we asked and even donated code to make it easier for others
} to
} do the same. What he's gotten in return is a large ration of grief.
}
} Personally I'm very dissapointed in the community's reaction to Dan trying
} to do the right thing.

I don't think I am giving Dan any grief, if so, sorry. Just giving comments
or suggestions. And must of the thread is beyond me!

Guy

} If we need a best practice on validation of web entered e-mail addresses,
} let's write it up and get some consensus. Let's quit berating Dan for not
} doing stuff we haven't even bothered to write down.
}
} Scott K

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Sunday 29 April 2007 22:11, Guy Watkins wrote:

> I don't think I am giving Dan any grief, if so, sorry. Just giving
> comments or suggestions. And must of the thread is beyond me!
>
No, you weren't. You were just the last in the chain on the thread when I
finally had time to write that response. Sorry about that.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
On Sun, 29 Apr 2007, Scott Kitterman wrote:

> I would just like to say that I think that if we are going to have sites like
> e-card sites, what Dan is trying to do here is the right thing.

> Unless someone comes up with a way to request sign-up verification for an
> e-mail address without actually sending an e-mail, I think it's inevitable
> that someone will be able to attempt to sign someone up for an e-mail related
> service.

Hmm. I'm not sure it's worth it, but one way would be to display
a cookie on the web page when registering. The user would be instructed
to copy/paste the cookie to an email message, and send it to the web site.

When the email with cookie is received, only then would a confirmation email be
sent to verify that the email can receive as well as send.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
>>Dan/e-card sites could generate a key and email address and request you
>>send
>>the first email to register. The ecard could use SPF and whatever else to
>>verify that the email is not forged. Then it would send an email with a
>>confirm link or whatever they would normally do.
>>
> Wouldn't stop people from signing you up on the web for the signup mail.
>
> Our web site describes best practices for web generated mail. AFAICT, Dan
> has done all we asked and even donated code to make it easier for others
> to
> do the same. What he's gotten in return is a large ration of grief.
>
> Personally I'm very dissapointed in the community's reaction to Dan trying
> to do the right thing.
>
> If we need a best practice on validation of web entered e-mail addresses,
> let's write it up and get some consensus. Let's quit berating Dan for not
> doing stuff we haven't even bothered to write down.
>
> Scott K

Hello.

Thanks Scott for defending me, that's appreciated. No problems, sometimes we
all slide in some eagerness too quickly.
Forgiveness is also a best practice to be learnt and applied ;-)
No problems Guy, you were not seen as offending me at all yourself. I have
understood your constructive suggestion about displaying only the cookie on
the web page, and requesting the user to send the e-mail first. It is an
option which would avoid a service to be used as a spam box.

Nevertheless, I think that the question of how we should register or how we
should do to avoid having a mail sent to anyone we want is to my opinion
sliding outside of the first aim about the sample code's security.
The sample code is only handling bounces, it is not how you register people,
how you let them send an e-card. This is something on top, that the ecard
provider have to solve. This is why I believe we should leave others get
involved on that question, and I don't think this is an SPF community issue.
The reason is that just any service can be used as a spam box this way, even
the SPF mailing list when we request a subscription. In that thought, these
ecard services are not more dangerous than all mailing lists as for their
potential spam abuse. I think we are too keen on security issue where there
is no need to see such a thing, unless there are real abuses, and we are
going too far in this concern IMHO.

Anyhow, here are my conclusions about the sample code.

1. The code does what it is intended for, and does it well: it allows
anybody to produce a service which sends an SPF compatible e-mail on behalf
of someone else, by forcing the sender's email address and keeping the
Return-Path address of the sending server, like suggested on the SPF
technical page, and helps to do so by providing a bouncing system which
takes care to handle these bounces and report in a _very_ secure way to the
sender that its destination address failed if it was the case (because
combined with the unique random ecard ID checked against the database). This
code cannot be abused by spammers.

2. The security of this code is not involved, but it is transferred to the
ecard/other service generator which must take care of the verification of
the real sender's address. As for the forging capability of hties system,
and thus the spam abuse potential, he can do this with Guy's suggestion of a
cookie displayed on the page, which the user should copy and paste in a new
e-mail he sends to a predefined e-mail address. This would probably be the
highest security system. A second level would be a captcha with each sent
e-cards would already be something quite secure, because automated systems
would not be able to use the service at all, even if one person could still
harm anyone else by hand. The third level is that there is no captcha, but
there are other limitations to the service which prevents spammers to use
the service as they would like. These limitations are notably to check the
sender's IP address against an online IP spam blacklist. I believe that the
third level is already enough, and we could further discuss about this. This
third level is better or equal to the level of security everyone uses on the
web, like for mailing lists, 'send this page to a friend', and so forth. I
don't believe that it is something which really causes spam dangers on the
internet, due to the described limitations of the service.

Thanks to all again. I think we have been able to construct something which
I hope is the right thing.

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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
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@example.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
Re: (SOLVED) SPF blocking e-mails coming from an E-card service server [ In reply to ]
>> 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@example.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

1 2  View All