Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not wanting to spur a flame war here, but I'd like to set one thing clear:

dan1 wrote:
> Alex van den Bogaerdt wrote:
> > 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 page in no way encourages sender address forgery. Please learn about
the meaning of the "From", "Sender", and "Reply-To" headers. It then
should become clear that what said page recommends does not constitute
sender address forgery.

And here's another thing: you might not be fully aware of the dangers to
your (certainly well intentioned) service (and it applies to thousands of
similar services, too!):

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

Today, spam and viruses aren't sent by a few single boxes. Today, entire
networks of hijacked computers are used to do that. Those networks can
comprise hundreds of thousands of "zombie" or "bot" computers (and thus IP
addresses), each sending just a few messages. Such a bot net could easily
be instructed to abuse your service to bomb a victim address with billions
of bounces. (But then, they could just as well bomb the victim directly,
unless of course it is _you_ and your service who the attacker wants to
strike.)

I'm not telling you what to do beyond making your service SPF compliant --
I merely want to raise your awareness for scale of the potential dangers
out there.

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

iD8DBQFGN0pnwL7PKlBZWjsRAvk2AKDPRTvGAwioNbkLe5flxVUkAydHngCfb9C0
FOIYLqL8dlFgQxZaNhqFd10=
=c/yo
-----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

On Tue, May 01, 2007 at 02:10:42PM +0000, Julian Mehnle wrote:

> > http://www.openspf.org/Best_Practices/Webgenerated
>
> This page in no way encourages sender address forgery. Please learn about
> the meaning of the "From", "Sender", and "Reply-To" headers. It then
> should become clear that what said page recommends does not constitute
> sender address forgery.

Indeed. See the last line: "the least you can do is to keep the bounces
from actually going to <president@whitehouse.gov>."

However, this is precisely what Dan is doing wrong IMHO.

(side note: I use "user@example.com" instead of "president@whitehouse.gov").

Original situation: Dan had a service, and he expected "user@example.com"
to deal with bounces that occured because of Dan's service.

Next: SPF got in the way. Example.com didn't want Dan to use user's
email address. This is why example.com published a policy. Now Dan is
no longer able to send his ecards.

Next: Dan modified his service, and Dan's site now uses Dan's email domain
to send his ecards.

---> so far so good <---

Next: Dan is collecting bounces, and sends them to user@example.com just
like in the original situation.

In other words: No problem is "solved" (see subject). All Dan has done
is to work around SPF, and while doing so he goes directly against the
spirit of SPF.


Does this sounds harsh Dan? That is because either
a) you still don't understand the problem.
or
b) you don't care.

I just hope it is (a), because in that case a dialog is possible.

> And here's another thing: you might not be fully aware of the dangers to
> your (certainly well intentioned) service (and it applies to thousands of
> similar services, too!):

Hear hear.

Dan, please don't shoot the messenger. I may bring bad news to you, but it
is because of what you (and others) are doing that SPF exists in the first
place.

SPF is not about spam. SPF is about forgery.

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

On Tue, May 01, 2007 at 12:25:25PM +0200, dan1 wrote:

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

Ack.

This was a generic statement about "such bounces", and I will suggest this
to anyone, not just this list, about any bounce, not just yours.

Also: "We have never had any problem reported..." Good; let's hope it
stays this way. Just in case problems do occur, spamcop will let you
know about this but only if I do forward your bounce to them.

Please see my other reply for another attempt to point out why I consider
your problem far from "Solved".

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

Alex, just a little bit of feedback. I can certainly see why Dan felt piled on, and why your comments in particular might have given that impression.

On Tue, May 01, 2007 at 9:21 AM PDT, Alex van den Bogaerdt wrote:

> Original situation: Dan had a service, and he expected "user@example.com"
> to deal with bounces that occured because of Dan's service.

That's *one* of the issues, but it's certainly not the only one. In the interests of user education, let's not over-simplify. There are multiple e-mail best practice issues involved when running a web-based service that generates messages to one party on behalf of a second party, and bounce handling is one of them.

> Next: SPF got in the way. Example.com didn't want Dan to use user's
> email address. This is why example.com published a policy. Now Dan
> is no longer able to send his ecards.
>
> Next: Dan modified his service, and Dan's site now uses Dan's email
> domain to send his ecards.
>
> ---> so far so good <---
>
> Next: Dan is collecting bounces, and sends them to user@example.com just
> like in the original situation.

So far, so good. What you're describing here is the learning process in action. User sees a problem, takes steps to fix it, and then discovers that that has unmasked a larger problem.

> In other words: No problem is "solved" (see subject). All Dan has done
> is to work around SPF, and while doing so he goes directly against the
> spirit of SPF.

This is an uncharitable characterization. The very fact that Dan took the time to find this list, join it, take feedback, make changes, and still come back to engage in this discussion already shows his good intentions. While his interim solution still isn't fully doing the right thing, he has demonstrated a willingness to learn and to make the right changes. "All Dan has done is to work around SPF, and while doing so he goes directly against the spirit of SPF" makes it sound like you're accusing him of a deliberate attempt to deceive folks.

Are you?

> Does this sounds harsh Dan? That is because either
> a) you still don't understand the problem.
> or
> b) you don't care.

This is a great example of where someone who lives immersed in this stuff everyday oversimplifies. You've been involved in the minutiae of proper message handling and SPF for how long? You think about this stuff all the time -- it's second nature to you. It's not to Dan and to the vast majority of other people you're trying to get to use SPF. You've now taken an ongoing learning process and turned it into an adversarial confrontation.

> I just hope it is (a), because in that case a dialog is possible.

This statement is downright condescending and hostile -- and I'm sure you didn't mean it to be. Nevertheless, that's how it comes across.

Educating someone about SPF (or other technology) isn't an all-or-nothing process. It's an iterative process. Not everyone is going to take every statement that is made and immediately see the implications, or remember it down the road after working on other aspects. I'm willing to bet you didn't get your mastery of the subject overnight, and I'm willing to bet Dan won't either. What I *am* willing to bet is that by being patient and pointing out the flaws and dangers in Dan's current implementation without using adversarial language -- and being willing to repeat things that you and others have said so that with his added understanding and context they now make sense -- you'll be able to keep working with him to produce another educated SPF user.

--
Devin L. Ganger, Exchange MVP Email: deving@3sharp.com
3Sharp LLC Phone: 425.882.1032 x1011
14700 NE 95th Suite 210 Cell: 425.239.2575
Redmond, WA 98052 Fax: 425.558.5710
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/

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

On Tue, May 01, 2007 at 10:39:08AM -0700, Devin Ganger wrote:

> > In other words: No problem is "solved" (see subject). All Dan has done
> > is to work around SPF, and while doing so he goes directly against the
> > spirit of SPF.
>
> This is an uncharitable characterization. The very fact that Dan took the time to find this list, join it, take feedback, make changes, and still come back to engage in this discussion already shows his good intentions. While his interim solution still isn't fully doing the right thing, he has demonstrated a willingness to learn and to make the right changes. "All Dan has done is to work around SPF, and while doing so he goes directly against the spirit of SPF" makes it sound like you're accusing him of a deliberate attempt to deceive folks.
>
> Are you?


I am not accusing Dan of anything. I was pointing out that the problem was
not "SOLVED" (see subject). You say "... isn't fully doing ...". I say
"...fully isn't doing, quite the opposite...". And I stand by my opinion.

Earlier I only thought Dan was not able to see why SPF was invented and why
it is a bad idea to accept unverified user input as a sender address.

Now I am not sure anymore. I am more and more convinced that Dan does not
care, enough or at all, about the fact that his service and thousands of
other, similar, services are part of the problem. But I am still open to
the possibility that this is just ignorance, and that's why I had to ask.

Why do I think so? Because on multiple occasions Dan is stating that he does
not think his site is part of the problem. He is not a spammer and he does
not receive complaints, so all is well. Anyone saying otherwise is harsh.




I am not going to comment on your opinion on how you have read and interpreted
the text I have written. I will ask one thing: next time you are going to
attack someone personally (as opposed to something technical) please do so
in private and not on-list.

Thank you very much for your interesting choice of words. I cannot help
thinking about the pot and kettle, I hope you see why. I am not willing to
feed the fire thus I will not respond to this thread anymore. This includes
the original topic as well as the topic drift which is about to occur.

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

> Today, spam and viruses aren't sent by a few single boxes. Today, entire
> networks of hijacked computers are used to do that. Those networks can
> comprise hundreds of thousands of "zombie" or "bot" computers (and thus IP
> addresses), each sending just a few messages. Such a bot net could easily
> be instructed to abuse your service to bomb a victim address with billions
> of bounces. (But then, they could just as well bomb the victim directly,
> unless of course it is _you_ and your service who the attacker wants to
> strike.)

Hello, Julian.

Yes, I know what you are talking about. This is why I have included an
online check of this kind of networks, wich stores the IPs of zombies and
other things as soon as they can.
Of course, it is not perfect, but already something qutie secure this way.

For the forgery, I meant to change the 'from' header, sorry if this is not
the definition of the forgery.
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

> Please see my other reply for another attempt to point out why I consider
> your problem far from "Solved".
>

Hello, Guys.
When I wrote 'SOLVED', it was regarding the first e-mail I sent to this list
to ask how we should do things right so that ecards service could be
compatible with SPF. I hadn't any script doing what was suggested on the
Best Practices web page, so I had to code my own. I have been able to do it
only after a lot of efforts, and wanted to share it, as I believe that it is
doing the exact thing which is suggested on that page, and it is doing it
well. If it arises other problems, then some other suggestions should be put
there for developpers like me.

>a) you still don't understand the problem.
>or
>b) you don't care.

a) I understand that the technical best practices seems to not be a best
practice at all to your point of view (I hope I am right saying this, but it
seems so at least). You are maybe absolutely right, but yet as I am not an
SPF expert, I can only follow the sugestions I could find, which is what I
did. So up to the suggested solutions I found officially on the website,
yes, the problem is solved.

b) I cannot say that I care a lot. I want to find a way for my ecard system
to be able to be SPF compliant. If it is impossible in it's nature, as you
seem to be thinking, then I cannot help. But if it is possible, then I would
like to find the simplest and best way to reach that goal, and thus I had to
check the suggestions, which I followed.
I emphasis again: I am not the right person to find the solution, I am
merely here to read the official solutions, and only those ones, that you
have been able to provide on your site.

I agree with Alex that it becomes a bit too firing here, and it is a bit
sad. I will also not post anymore to this thread so that we calm down, but I
encourage you other guys to talk about this apparently new problem that it
seems to be generating, and I leave you find the best solutions. I think to
have provided good ones in my other e-mails, but you can be judges
yourselves.

Still thanks to all for your support and time shared, which is appreciated.

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

dan1 wrote:

> When I wrote 'SOLVED', it was regarding the first e-mail I sent to
> this list to ask how we should do things right so that ecards service
> could be compatible with SPF.

Yes, that's clear. I didn't follow all details of the philosophical
debate after that. Of course it would be ideal to prevent any abuse,
and Alex' proposal with a confirmed login and passwords etc. would
do this . But you're confronted with users who hate such "complex"
login / password procedures, and therefore you decided that it does
not work for you.

When I forward an article from heise.de (a German version of "/.")
it also doesn't ask me for my password, it uses some heuristics to
limit abuse like you do. Or at least I think that that's what they
do, in fact I have an account and a cookie for their site, so maybe
they use the cookie. But I think they don't.

Frank


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

On Tue, 1 May 2007, Frank Ellermann wrote:

> Yes, that's clear. I didn't follow all details of the philosophical
> debate after that. Of course it would be ideal to prevent any abuse,
> and Alex' proposal with a confirmed login and passwords etc. would
> do this . But you're confronted with users who hate such "complex"
> login / password procedures, and therefore you decided that it does
> not work for you.

Not only that, but a get quite a bit of "confirmation" spam from web
sites informing me that someone has attempted to register my email.
Alex's cure is as bad or worse than the disease. As it is, my content
filter has "learned" to ignore confirmation emails. I think captchas,
as Dan suggested, are the next level of escalation in the spam wars as
it affects mail generating web sites.

On the infrequent occasions that I actually need to register somewhere, I
generally need to whitelist the sender of the confirmation email.

IMPORTANT POINT: It is usually not obvious on a web site which address
or domain I need to whitelist. I generally watch my mail logs just after
submitting the registration request - but most users have no way of
doing this. *All web registration sites should clearly display where
the confirmations and emails from the site will be coming from*.
Typical end users will then "add the address to their address book" for
end-user friendly whitelisting.

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