librelist archives

So confused.

From:

Date:

2010-01-06 @ 19:46

I'm so confused. What I've been trying to do is we send an email to someone
if for any reason it bounces it cancels the account. But I feel like im
missing something. The bouncer code doesn't actually do anything at all and
just creates an error below. If mail isn't a bounce it just forwards it to
the postfix server. What am I missing ?

Best Regards,

Kevin

 

@route(".+")

@stateless

def BOUNCER(message):

        email = bounce.detect(message)

        error = email.error_for_humans()

        to = message.bounce.final_recipient

        params = urllib.urlencode({'to' : to, 'error': error})

        headers = {"Content-type": "application/x-www-form-urlencoded",
"Accept": "text/plain"}

        conn = httplib.HTTPConnection("192.168.62.11:80")

        conn.request("POST", "/CDS/bounced-emails.php", params, headers)

        response = conn.getresponce()

        loggin.debug(response.status, response.reason)

        data = response.read()

        conn.close()

        return START

 

 

 

@route("(address)@(host)", address=".+", host=".+")

@bounce_to(soft=BOUNCER, hard=BOUNCER)

@stateless

def START(message, address=None, host=None):

        return FORWARD

 

@route_like(START)

@stateless

def FORWARD(message, address=None, host=None):

    relay.deliver(message)

 

 

Results :

Traceback (most recent call last):

  File
"/usr/lib/python2.6/site-packages/lamson-1.0pre11-py2.6.egg/lamson/server.py
", line 183, in process_message

    routing.Router.deliver(mail.MailRequest(Peer, From, To, Data))

  File
"/usr/lib/python2.6/site-packages/lamson-1.0pre11-py2.6.egg/lamson/routing.p
y", line 360, in deliver

    self.call_safely(func, message, matchkw)

  File
"/usr/lib/python2.6/site-packages/lamson-1.0pre11-py2.6.egg/lamson/routing.p
y", line 385, in call_safely

    self.UNDELIVERABLE_QUEUE.push(message)

AttributeError: 'str' object has no attribute 'push'

On Wed, Jan 06, 2010 at 02:46:52PM -0500, kjones12@optonline.net wrote:
> I'm so confused. What I've been trying to do is we send an email to someone
> if for any reason it bounces it cancels the account. But I feel like im
> missing something. The bouncer code doesn't actually do anything at all and
> just creates an error below. If mail isn't a bounce it just forwards it to
> the postfix server. What am I missing ?

So, firs thing, you have both of these as stateless, which won't work.
Stateless *always* runs on email it matches.  So if someone sends to
blah@blah.com both your BOUNCER and START handlers will fire.

Next, make sure you read about how the state transisions work:

http://lamsonproject.org/docs/introduction_to_finite_state_machines.html

That's the #1, #2, and #3 thing that web programmers completely don't
get.  The fact that you have stateless on all of these indicates that
you might not get this concept, but it is crucial to handling this.

Ok, once you get that, go in and change this so that you have nothing
stateless, and that you have a set of unit tests that probe non-bounce
emails go through START->FORWARD and bounce emails are going through
BOUNCER.

Unit tests are how you want to make this work.  In fact, do them TDD
style where you write out the "conversation" that should happen, and
then make your states so the tests work.

-- 
Zed A. Shaw
http://zedshaw.com/

CM SPAM detection: spam
References: <001601ca8f08$ff08fd50$fd1af7f0$@net>
 <001601ca8f08$ff08fd50$fd1af7f0$@net> <20100106204636.GH26249@zedshaw>

Yes it was confusing I thought I understood the concept of the state
machine. But poking around more with your examples and reading the intro to
state machines and poking around as m g did though I have no need for the
states at this time I was more interested in your bounce class since we
start the process by sending the email and just care if it bounces or not it
is still exciting. In any case it has made me appreciate the Lamson Project
even more. And things are coming along well now that I'm getting over the
learning curve for both your Library and the Python Language. Thanks again
Zed
Best Regards,
Kevin Jones

-----Original Message-----
From: lamson@librelist.com [mailto:lamson@librelist.com] On Behalf Of Zed A.
Shaw
Sent: Wednesday, January 06, 2010 3:47 PM
To: lamson@librelist.com
Subject: Re: [lamson] So confused.

On Wed, Jan 06, 2010 at 02:46:52PM -0500, kjones12@optonline.net wrote:
> I'm so confused. What I've been trying to do is we send an email to
someone
> if for any reason it bounces it cancels the account. But I feel like im
> missing something. The bouncer code doesn't actually do anything at all
and
> just creates an error below. If mail isn't a bounce it just forwards it to
> the postfix server. What am I missing ?

So, firs thing, you have both of these as stateless, which won't work.
Stateless *always* runs on email it matches.  So if someone sends to
blah@blah.com both your BOUNCER and START handlers will fire.

Next, make sure you read about how the state transisions work:

http://lamsonproject.org/docs/introduction_to_finite_state_machines.html

That's the #1, #2, and #3 thing that web programmers completely don't
get.  The fact that you have stateless on all of these indicates that
you might not get this concept, but it is crucial to handling this.

Ok, once you get that, go in and change this so that you have nothing
stateless, and that you have a set of unit tests that probe non-bounce
emails go through START->FORWARD and bounce emails are going through
BOUNCER.

Unit tests are how you want to make this work.  In fact, do them TDD
style where you write out the "conversation" that should happen, and
then make your states so the tests work.

-- 
Zed A. Shaw
http://zedshaw.com/

On Wed, Jan 6, 2010 at 3:46 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> That's the #1, #2, and #3 thing that web programmers completely don't
> get.  The fact that you have stateless on all of these indicates that
> you might not get this concept, but it is crucial to handling this.
>

Interesting observation, especially since HTTP is stateless... or are
these two different types of stateless-ness?

On Wed, Jan 06, 2010 at 04:56:24PM -0500, m g wrote:
> On Wed, Jan 6, 2010 at 3:46 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> > That's the #1, #2, and #3 thing that web programmers completely don't
> > get.  The fact that you have stateless on all of these indicates that
> > you might not get this concept, but it is crucial to handling this.
> >
> 
> Interesting observation, especially since HTTP is stateless... or are
> these two different types of stateless-ness?

No, that's pretty much the reason.  HTTP is stateless so stateless
operations and apps work best.  SMTP *has* state and is actually defined
in terms of a state machine, so apps work best if they're state
machines.

Another reason a stateful app works best for email is because the
namespace of actions is too small.  With HTTP you have full comples URLs
that can take parameters.  With email the only reliable thing you have
is an email address, which is limited to a smaller number of chars
before an @.

Web programmers however don't know this so they usaully go at their
first lamson app tacking @stateless on everything and having problems.

-- 
Zed A. Shaw
http://zedshaw.com/

On Wed, Jan 6, 2010 at 5:27 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Wed, Jan 06, 2010 at 04:56:24PM -0500, m g wrote:
>> On Wed, Jan 6, 2010 at 3:46 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>> > That's the #1, #2, and #3 thing that web programmers completely don't
>> > get.  The fact that you have stateless on all of these indicates that
>> > you might not get this concept, but it is crucial to handling this.
>> >
>>
>> Interesting observation, especially since HTTP is stateless... or are
>> these two different types of stateless-ness?
>
> No, that's pretty much the reason.  HTTP is stateless so stateless
> operations and apps work best.  SMTP *has* state and is actually defined
> in terms of a state machine, so apps work best if they're state
> machines.
>
> Another reason a stateful app works best for email is because the
> namespace of actions is too small.  With HTTP you have full comples URLs
> that can take parameters.  With email the only reliable thing you have
> is an email address, which is limited to a smaller number of chars
> before an @.
>
> Web programmers however don't know this so they usaully go at their
> first lamson app tacking @stateless on everything and having problems.
>

Ah, makes sense.

Is this in the documentation anywhere (perhaps FAQ or
introduction_to_finite_state_machines.txt)?  I have read through the
documentation on two different occasions.  It was always clear _how_
the FSM worked, but never the motivation for _why_ it was there.

It is very possible that I am not good at connecting the dots either.

>Is this in the documentation anywhere (perhaps FAQ or 
introduction_to_finite_state_machines.txt)?
>I have read through the documentation on two different occasions.  It
>was always clear _how_ the FSM worked, but never the motivation for _why_
it was there.
>It is very possible that I am not good at connecting the dots either.

One thing that was not clear to me when reading the documentation was what
was making up the state.  Maybe if the 
http://lamsonproject.org/docs/introduction_to_finite_state_machines.html 
had a statement that said by default Lamsons state machine is based on 
only the "sender" it would be more clear.

In the librelist admin.py handler you can see how the state has been 
expanded to not only use the "sender" but also  mailinglist name from the 
"to".  This is how librelist can manage multiple subscriptions from the 
same "sender".

Troy

On Thu, Jan 07, 2010 at 01:55:12PM -0500, Troy Sorzano wrote:
> >Is this in the documentation anywhere (perhaps FAQ or 
introduction_to_finite_state_machines.txt)?
> >I have read through the documentation on two different occasions.  It
> >was always clear _how_ the FSM worked, but never the motivation for 
_why_ it was there.
> >It is very possible that I am not good at connecting the dots either.


> One thing that was not clear to me when reading the documentation was
> what was making up the state.  Maybe if the
> http://lamsonproject.org/docs/introduction_to_finite_state_machines.html
> had a statement that said by default Lamsons state machine is based on
> only the "sender" it would be more clear.

Hmm, yep that seems to trip folks up too.  It's actually the
sender+module.  So if you have app.handlers.admin and app.handlers.lists
then these two modules have separate states stored.

That's sort of covered in:

http://lamsonproject.org/docs/writing_a_state_storage.html

> In the librelist admin.py handler you can see how the state has been
> expanded to not only use the "sender" but also  mailinglist name from
> the "to".  This is how librelist can manage multiple subscriptions
> from the same "sender".

Ah yes, that is missing.  Alright, added to the bug list:

http://support.lamsonproject.org/tktview/e9fa4c5c2a823e6efc181bc7917ff5a71b347153


-- 
Zed A. Shaw
http://zedshaw.com/