[Mailman-Developers] RE: [ZMailman] Goals and next steps?

[Trevor Toenjes]

Barry,
Thank you so much for getting involved with this project.  yeehaw!!

Sorry for all the MTA requests.  I have never admined Mailman. I was
planning on installing it in the next few weeks and then this project was
born.

> Do you mean you want the user-specific
> bounce statistics to be stored in Zope?  That will be doable when I
> integrate the bounce stats into the MemberAdaptor API (which I will do
> this week as part of the bounce processing overhaul).

Yes. That is what I meant.  I want be able to put rules on bounces as they
come back into Zope to delete, notify the list's manager, or notify an
account mamager responsible for that email.
Bounce management could be a whole workflow and list management module on
its own.

The further we can go with Validation prior to delivery the better.  I agree
with the UUCP fossile reference.

Cheers,
Trevor


> -----Original Message-----
> From: zmailman-admin@mail.iuveno-net.de
> [mailto:zmailman-admin@mail.iuveno-net.de]On Behalf Of Barry A. Warsaw
> Sent: Tuesday, December 04, 2001 4:23 PM
> To: Trevor Toenjes
> Cc: Fred Wilson Horch; Stephan Richter; Zmailman List;
> mailman-developers@python.org
> Subject: RE: [ZMailman] Goals and next steps?
>
>
>
> >>>>> "TT" == Trevor Toenjes <zope@toenjes.com> writes:
>
>     TT> My wishes:
>     TT> A.  I would like to use Zmailman as an MTA from Zope.
>
>     TT> So I would like to deliver a payload of Zope multi-part mime
>     TT> content to zMailman and assign it to a list for delivery.
>
> This will be easy in MM2.1.  Using the email package, you compose the
> MIME subparts into a Message object, then you use Mailman's Post.py
> module to get the message into the incoming queue.  MM's incoming
> queue runner then picks it up and does the normal moderate-and-munge
> pipeline processing on the message, eventually sending it to the
> sink queues -- outgoing, archiver, digester, news -- as appropriate.
>
> Nothing too Zope specific here.
>
>     TT> Then I would like to get to the bounce data, etc, from Zope.
>
> I'm not sure what that means.  Do you mean you want the user-specific
> bounce statistics to be stored in Zope?  That will be doable when I
> integrate the bounce stats into the MemberAdaptor API (which I will do
> this week as part of the bounce processing overhaul).
>
>     TT> And perform logic on the list, like automatically removing
>     TT> names from the list that are bounced after 48 hours.  So, we
>     TT> should allow for Mailman to reside on its own server for
>     TT> high-volume cases.
>
> All doable in MM2.1 because it will do all the member-specific data
> access and modifications through the MemberAdaptor.
>
>     TT> B.  I would also like to get at and improve Mailman's
>     TT> validation capability.
>
> None of this is Zope specific BTW.
>
>     TT> Zmailman should have 3 options to validate an email address.
>     TT> 1.  Syntax -- Parses the address to ensure legal syntax Less
>     TT> than one millisecond.
>
> Right.  We do some of this, but could/should be using Python's RFC
> 2822 address parser as well.
>
>     TT> 2.  DNS -- All of the above, plus makes
>     TT> sure the domain exists and has an address for receiving email
>     TT> (as specified by MX or A records) A second or two. Default
>     TT> timeout is 10 seconds.
>
> Doable, although not curently done.
>
>     TT> 3.  SMTP -- All of the above, plus
>     TT> contacts the domain's mail server and inquires about the
>     TT> recipient Tens of seconds. Default timeout is 60 seconds.
>     TT> Combined with the DNS timeout, this makes a worst case of 70
>     TT> seconds.
>
> Harder, because you are not at all guaranteed that the SMTP server
> provides validation services (i.e. VRFY).  The web page you reference
> even points this out.
>
> Note that all this could be done fairly easily in Python and hooked
> into the Utils.ValidateEmail() function in Mailman.  It probably
> /should/ be done for MM2.1.  Note further though that just because an
> email address is RFC 822 valid doesn't necessarily mean we want to
> support them in Mailman.  First off, it should be RFC 2822 compliant.
> Second off, does Mailman really need to accept UUCP addresses these
> days?
>
>     | http://www.hexillion.com/docs/guides/HexValidEmail/concepts/
>     | good reference
>
> Interest, thanks!
>
> -Barry
> _______________________________________________
> ZMailman mailing list
> ZMailman@mail.iuveno-net.de
> http://mail.iuveno-net.de/mailman/listinfo/zmailman