FAQ
I'm beginning to think it would have been easier to just start all
over if I didn't care about my users getting upset. Anyway I still
seem to have a problem that I didn't have before the restore.

Since I don't know what is supposed to happen during processing I
guess all I can do is guess. When I send a request to one on my lists
(<list name>-request) the smtp log shows an error. The request gets
processed at least is it piped tp the mailman request command, and
then seems to get sent to <list name.-bounces>. The problem is that it
tries to send it via hostname.domain.com which my SMTP server tries to
send to my ISPs mail host. The mail is summarily rejected. I THINK it
should be going to <list name>-bounces at localhost instead. In any case
what is supposed to be happening here and why it is trying to send it
to bounces? Thanks.

Search Discussions

  • Mark Sapiro at Jan 9, 2008 at 3:36 am

    Dennis Putnam wrote:
    Since I don't know what is supposed to happen during processing I
    guess all I can do is guess. When I send a request to one on my lists
    (<list name>-request) the smtp log shows an error. The request gets
    processed at least is it piped tp the mailman request command, and
    then seems to get sent to <list name.-bounces>. The problem is that it
    tries to send it via hostname.domain.com which my SMTP server tries to
    send to my ISPs mail host. The mail is summarily rejected. I THINK it
    should be going to <list name>-bounces at localhost instead. In any case
    what is supposed to be happening here and why it is trying to send it
    to bounces? Thanks.

    One thing you can try is to create a new test list and see if that
    works. Then at least, you will have a better idea if there is some
    issue with mailman or if it has specifically to do with the restored
    lists.

    That said, here's what's supposeed to happen when you mail
    listname-request.

    The mail is piped to "|/path/to/mailman/mail/mailman request listname".

    It is processed by the scripts/request script and the results are sent
    to the From: address of the original mail with the subject "The
    results of your email commands". This message is sent from and with
    envelope from listname-bounces at ...

    That message is either delivered to the original sender (you) or it
    bounces in which case the bounce is sent to the listname-bounces
    address. The domain in the from/sender of the reply is the host_name
    attribute of the list which should not be 'localhost'

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Dennis Putnam at Jan 10, 2008 at 12:38 am
    I'll give that a try. In the mean time maybe it is not what I thought
    based on your explanation. The specific error from my ISP complains
    about a missing DNS entry for RCPT TO. How do I set mailman to place
    the correct RCPT TO information in the headers for my SMTP server. I
    tried setting:

    DEFAULT_REPLY_GOES_TO_LIST = 2
    REPLY_TO_ADDRESS = '<acceptable host/domain>'

    It seems that is not what it is using for the RCPT TO.

    Thanks again.

    At 10:36 PM 1/8/2008, you wrote:


    One thing you can try is to create a new test list and see if that
    works. Then at least, you will have a better idea if there is some
    issue with mailman or if it has specifically to do with the restored
    lists.

    That said, here's what's supposeed to happen when you mail
    listname-request.

    The mail is piped to "|/path/to/mailman/mail/mailman request
    listname".

    It is processed by the scripts/request script and the results are sent
    to the From: address of the original mail with the subject "The
    results of your email commands". This message is sent from and with
    envelope from listname-bounces at ...

    That message is either delivered to the original sender (you) or it
    bounces in which case the bounce is sent to the listname-bounces
    address. The domain in the from/sender of the reply is the host_name
    attribute of the list which should not be 'localhost'

    - --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Jan 10, 2008 at 7:38 pm

    Dennis Putnam wrote:
    I'll give that a try. In the mean time maybe it is not what I thought
    based on your explanation. The specific error from my ISP complains
    about a missing DNS entry for RCPT TO. How do I set mailman to place
    the correct RCPT TO information in the headers for my SMTP server. I
    tried setting:

    DEFAULT_REPLY_GOES_TO_LIST = 2
    REPLY_TO_ADDRESS = '<acceptable host/domain>'

    It seems that is not what it is using for the RCPT TO.

    RCPT TO is the SMTP command for specifying the recipient(s) of the
    message. These will be the addresses of the list members or the
    owner/moderator or other recipient of a Mailman generated notice.

    I do not thing that is what the ISP's MTA is complaining about. I thing
    it returns whatever reject status it is returning in response to a
    RCPT TO command, but that doesn't mean it is complaining about the
    recipient address.

    I believe what it doesn't like is the MAIL FROM address - i.e. the
    listname-bounces at host_name address. Is your list's host_name in DNS?

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Dennis Putnam at Jan 10, 2008 at 10:11 pm
    Thanks for the reply.

    No. I do not have a static IP or a registered domain, which is why all
    mail from this server has to go through my ISP's server. However,
    non-mailman mail is sent just fine. If it is indeed the "MAIL FROM"
    then why would my changes in mm_cfg.py, not have fixed it? On the
    other hand, why would it complain about 'RCPT TO' rather then 'MAIL
    FROM'?

    At 02:38 PM 1/10/2008, you wrote:

    RCPT TO is the SMTP command for specifying the recipient(s) of the
    message. These will be the addresses of the list members or the
    owner/moderator or other recipient of a Mailman generated notice.

    I do not thing that is what the ISP's MTA is complaining about. I
    thing
    it returns whatever reject status it is returning in response to a
    RCPT TO command, but that doesn't mean it is complaining about the
    recipient address.

    I believe what it doesn't like is the MAIL FROM address - i.e. the
    listname-bounces at host_name address. Is your list's host_name in DNS?

    - --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Jan 10, 2008 at 11:24 pm

    Dennis Putnam wrote:
    No. I do not have a static IP or a registered domain, which is why all
    mail from this server has to go through my ISP's server. However,
    non-mailman mail is sent just fine. If it is indeed the "MAIL FROM"
    then why would my changes in mm_cfg.py, not have fixed it? On the
    other hand, why would it complain about 'RCPT TO' rather then 'MAIL
    FROM'?

    The changes you made in mm_cfg.py

    DEFAULT_REPLY_GOES_TO_LIST = 2
    REPLY_TO_ADDRESS = '<acceptable host/domain>'

    have nothing to do with this issue. First, they only set defaults for
    new lists. They have no effect on existing lists. Second, they only
    have to do with a Reply-To: header in outgiong list posts which has
    absolutely nothing to do with your problem.

    On the
    other hand, why would it complain about 'RCPT TO' rather then 'MAIL
    FROM'?

    Lots of reasons. It could be a relaying issue which can't be detected
    until the MTA knows the destination, or it could just be that the MTA
    is configured to do the FROM domain check at RCPT time in the SMTP
    transaction.

    What is the exact reject response from the MTA?

    What is the difference between 'non-Mailman' mail that works and
    Mailman mail that doesn't. Does the non-Mailman mail come from a
    different envelope from domain? Does non-Mailman mail use SMTP-AUTH to
    authenticate to the ISP?

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Dennis Putnam at Jan 11, 2008 at 10:53 pm
    Thanks for the reply.

    I'll remove those changes.

    The exact response is:

    550 [PERMFAIL] bellsouth.net requires valid sender domain (in reply to
    RCPT TO command))

    I should have paid more attention, sorry. Is not the RCPT TO command
    itself but the reply to it and I believe it is referring to my
    mailman/SMTP server.

    I can't tell you the specific difference because there are no useful
    messages (just a 250 sent message) when it is successful. My main
    point was that a message formed by the 'mail' command, on the same
    server, works so it seems a mailman config issue. I don't think
    SMTP-AUTH matters since both go through the same local 'SMTP' server
    to the same ISP mail server. Right? Isn't the mechanism 'sendmail' in
    both cases to my SMTP server? Or is 'mailman' trying to talk directly
    to my ISP's mail server? I don't recall doing anything special with
    mailman when it was working for my ISP's mail server. I may have done
    something to 'postfix' specifically for mailman but I don't recall
    what.

    At 06:24 PM 1/10/2008, you wrote:


    The changes you made in mm_cfg.py

    DEFAULT_REPLY_GOES_TO_LIST = 2
    REPLY_TO_ADDRESS = '<acceptable host/domain>'

    have nothing to do with this issue. First, they only set defaults for
    new lists. They have no effect on existing lists. Second, they only
    have to do with a Reply-To: header in outgiong list posts which has
    absolutely nothing to do with your problem.

    On the
    other hand, why would it complain about 'RCPT TO' rather then 'MAIL
    FROM'?

    Lots of reasons. It could be a relaying issue which can't be detected
    until the MTA knows the destination, or it could just be that the MTA
    is configured to do the FROM domain check at RCPT time in the SMTP
    transaction.

    What is the exact reject response from the MTA?

    What is the difference between 'non-Mailman' mail that works and
    Mailman mail that doesn't. Does the non-Mailman mail come from a
    different envelope from domain? Does non-Mailman mail use SMTP-AUTH to
    authenticate to the ISP?

    - --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Jan 11, 2008 at 11:36 pm

    Dennis Putnam wrote:
    550 [PERMFAIL] bellsouth.net requires valid sender domain (in reply to
    RCPT TO command))

    I should have paid more attention, sorry. Is not the RCPT TO command
    itself but the reply to it and I believe it is referring to my
    mailman/SMTP server.

    I think it is refering to the domain of the 'sender' of the mail which
    is the list's host_name attribute.

    I can't tell you the specific difference because there are no useful
    messages (just a 250 sent message) when it is successful.

    And what are the other things in your MTA's log entries like the from
    and to addresses. The ISP is complaining about the domain of the from
    address that you would see in your MTAs logs.

    My main
    point was that a message formed by the 'mail' command, on the same
    server, works so it seems a mailman config issue. I don't think
    SMTP-AUTH matters since both go through the same local 'SMTP' server
    to the same ISP mail server. Right?

    Yes, based on your description, that's right.

    Isn't the mechanism 'sendmail' in
    both cases to my SMTP server? Or is 'mailman' trying to talk directly
    to my ISP's mail server?

    Unless you changed SMTPHOST and SMTPPORT (putting them in mm_cfg.py)
    Mailman is sending to the MTA that it talks to on port 25 at
    'localhost'.

    I don't recall doing anything special with
    mailman when it was working for my ISP's mail server. I may have done
    something to 'postfix' specifically for mailman but I don't recall
    what.

    So look in your local maillog for the postfix entries for successful
    and unsuccessful posts. The difference will be in the domain of the
    'from' address in the log entries.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brad Knowles at Jan 11, 2008 at 4:48 am

    On 1/9/08, Dennis Putnam wrote:

    It seems that is not what it is using for the RCPT TO.
    RCPT TO is a recipient address. Look through the list of subscribers
    for your list and make sure that they are all correctly formed and
    valid domains.

    --
    Brad Knowles <brad at shub-internet.org>
    LinkedIn Profile: <http://tinyurl.com/y8kpxu>
  • Dennis Putnam at Jan 12, 2008 at 4:40 pm
    Thanks for the reply. I have a guess as to what is wrong but I don't
    know how to fix it in mailman. Here are the syslog entries for a
    non-mailman email:

    Jan 12 10:55:10 dap002 postfix/qmgr[2345]: 47CD185063:
    from=<dap at home.bellsouth.net>, sizeC5, nrcpt=1 (queue active)
    Jan 12 10:55:16 dap002 postfix/smtp[21572]: 47CD185063:
    to=<dap1 at bellsouth.net>, relay=mail.bellsouth.net[204.127.217.17]:25,
    delay=5.8, delays=0.05/0.02/5.5/0.28, dsn=2.0.0, status=sent (250 ok
    ; id 080112155515H0100n202se)
    Jan 12 10:55:16 dap002 postfix/qmgr[2345]: 47CD185063: removed

    Note the from hostname is 'home.bellsouth.net'. Now the mailman entries:

    Jan 12 10:56:12 dap002 postfix/qmgr[2345]: D4F7D85061:
    from=<cufsalumni-bounces at dap002.bellsouth.net>, size015, nrcpt=1
    (queue active)
    Jan 12 10:56:12 dap002 postfix/smtpd[21582]: disconnect from dap002[127.0.0.1]
    Jan 12 10:56:16 dap002 postfix/smtp[21572]: D4F7D85061:
    to=<dap1 at bellsouth.net>, relay=mail.bellsouth.net[207.115.11.17]:25,
    delay=3.5, delays=0.03/0.01/3.3/0.19, dsn=5.0.0, status=bounced (host
    mail.bellsouth.net[207.115.11.17] said: 550 [PERMFAIL] bellsouth.net
    requires valid sender domain (in reply to RCPT TO command))

    Here the from hostname is 'dap002.bellsouth.net' instead of
    'home.bellsouth.net', that is not to say I know this is the problem
    but its all I can see as different. Obviously mailman is somehow
    overriding the normal from hostname and building its own. The name
    'dap002' is the LAN hostname but I cannot use that as the from
    address to my ISP. My ISP has a special hostname for situations like
    this that will properly resolve via DNS although it is a dummy name
    for all DHCP assigned IPs. My mm_cfg.py has these 2 lines referring
    to the hostname but obviously they are not what is being used in this case:

    DEFAULT_EMAIL_HOST = 'home.bellsouth.net'
    DEFAULT_URL_HOST = 'home.bellsouth.net'
  • Brad Knowles at Jan 12, 2008 at 10:58 pm

    On 1/12/08, Dennis Putnam wrote:

    Thanks for the reply. I have a guess as to what is wrong but I don't
    know how to fix it in mailman. Here are the syslog entries for a
    non-mailman email:

    Jan 12 10:55:10 dap002 postfix/qmgr[2345]: 47CD185063:
    from=<dap at home.bellsouth.net>, sizeC5, nrcpt=1 (queue active)
    Jan 12 10:55:16 dap002 postfix/smtp[21572]: 47CD185063:
    to=<dap1 at bellsouth.net>, relay=mail.bellsouth.net[204.127.217.17]:25,
    delay=5.8, delays=0.05/0.02/5.5/0.28, dsn=2.0.0, status=sent (250 ok
    ; id 080112155515H0100n202se)
    Jan 12 10:55:16 dap002 postfix/qmgr[2345]: 47CD185063: removed

    Note the from hostname is 'home.bellsouth.net'. Now the mailman entries:
    Clearly, the hostname is "dap002" in some domain, because that's the
    name that is showing up in the "hostnme" field in the syslog file.
    Jan 12 10:56:12 dap002 postfix/qmgr[2345]: D4F7D85061:
    from=<cufsalumni-bounces at dap002.bellsouth.net>, size015, nrcpt=1
    (queue active)
    Jan 12 10:56:12 dap002 postfix/smtpd[21582]: disconnect from
    dap002[127.0.0.1]
    Jan 12 10:56:16 dap002 postfix/smtp[21572]: D4F7D85061:
    to=<dap1 at bellsouth.net>, relay=mail.bellsouth.net[207.115.11.17]:25,
    delay=3.5, delays=0.03/0.01/3.3/0.19, dsn=5.0.0, status=bounced (host
    mail.bellsouth.net[207.115.11.17] said: 550 [PERMFAIL] bellsouth.net
    requires valid sender domain (in reply to RCPT TO command))
    Well, if the hostname really was home.bellsouth.net, that would map
    to IP address 216.77.188.41, but the reverse DNS for this IP address
    points back to dsl.bellsouth.net, which does map correctly back to
    the same IP address. So, I would not be surprised to see
    "home.bellsouth.net" changed to "dsl.bellsouth.net" in your outgoing
    mail.
    Here the from hostname is 'dap002.bellsouth.net' instead of
    'home.bellsouth.net', that is not to say I know this is the problem
    but its all I can see as different.
    Certainly, the name dap002.bellsouth.net does not exist in the DNS.
    If this is what your system is trying to use to identify itself to
    the outside world, that would be a problem.
    Obviously mailman is somehow
    overriding the normal from hostname and building its own. The name
    'dap002' is the LAN hostname but I cannot use that as the from
    address to my ISP. My ISP has a special hostname for situations like
    this that will properly resolve via DNS although it is a dummy name
    for all DHCP assigned IPs. My mm_cfg.py has these 2 lines referring
    to the hostname but obviously they are not what is being used in this
    case:
    I suspect that the problem you're having may be a hostname or MTA
    misconfiguration issue, which Mailman is not involved in, and which
    cannot be fixed within Mailman.

    Try typing the command "hostname" at the command-line prompt on the
    machine. Also check your MTA configuration to make sure that this is
    not being over-ridden.
    DEFAULT_EMAIL_HOST = 'home.bellsouth.net'
    DEFAULT_URL_HOST = 'home.bellsouth.net'
    If you made these changes after the list was created, then they will
    not be reflected in the list configuration. I think that running
    "fix_url" will do that for you, but you'll have to check the FAQ
    Wizard or the archives of the list to be sure.

    --
    Brad Knowles <brad at shub-internet.org>
    LinkedIn Profile: <http://tinyurl.com/y8kpxu>
  • Mark Sapiro at Jan 13, 2008 at 2:44 am

    Dennis Putnam wrote:
    Here the from hostname is 'dap002.bellsouth.net' instead of
    'home.bellsouth.net', that is not to say I know this is the problem
    but its all I can see as different. Obviously mailman is somehow
    overriding the normal from hostname and building its own. The name
    'dap002' is the LAN hostname but I cannot use that as the from
    address to my ISP. My ISP has a special hostname for situations like
    this that will properly resolve via DNS although it is a dummy name
    for all DHCP assigned IPs. My mm_cfg.py has these 2 lines referring
    to the hostname but obviously they are not what is being used in this case:

    DEFAULT_EMAIL_HOST = 'home.bellsouth.net'
    DEFAULT_URL_HOST = 'home.bellsouth.net'

    These will affect list attributes at list creation time but not
    subsequently. You can run fix_url to fix the list but in this case,
    that isn't necessary. In this case, all you need to do is go the the
    list admin General Options page and change "Host name this list
    prefers for email." (host_name) from dap002.bellsouth.net to
    home.bellsouth.net.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Dennis Putnam at Jan 13, 2008 at 1:25 am

    At 05:58 PM 1/12/2008, you wrote:
    Well, if the hostname really was home.bellsouth.net, that would map
    to IP address 216.77.188.41, but the reverse DNS for this IP address
    points back to dsl.bellsouth.net, which does map correctly back to
    the same IP address. So, I would not be surprised to see
    "home.bellsouth.net" changed to "dsl.bellsouth.net" in your outgoing mail.
    As I said later, that is a special name set up by the ISP for just
    this type situation.

    Certainly, the name dap002.bellsouth.net does not exist in the DNS.
    If this is what your system is trying to use to identify itself to
    the outside world, that would be a problem.
    Only mailman is trying to use that name.

    I suspect that the problem you're having may be a hostname or MTA
    misconfiguration issue, which Mailman is not involved in, and which
    cannot be fixed within Mailman.
    If that we the case, why is it only mailman sending mail that is
    effected? As I demonstrated, when using the 'mail' command, everything is fine.

    Try typing the command "hostname" at the command-line prompt on the
    machine. Also check your MTA configuration to make sure that this
    is not being over-ridden.
    There is no MTA setting that would effect mailman and nothing else
    that I can find? Any suggestions?

    If you made these changes after the list was created, then they will
    not be reflected in the list configuration. I think that running
    "fix_url" will do that for you, but you'll have to check the FAQ
    Wizard or the archives of the list to be sure.
    Keep in mind this was a working system that started giving me trouble
    after a restore.
  • Stephen J. Turnbull at Jan 13, 2008 at 3:24 am
    Dennis Putnam writes:
    Keep in mind this was a working system that started giving me trouble
    after a restore.
    Unfortunately, that's not really possible. People who do not have
    access to your system can only match symptoms to cases they've seen in
    the past. This particular symptom is universal for this kind of case:
    if *nothing* was working, you wouldn't be posting here at this point.
    So it tells us nothing we didn't already know.

    As for "worked, broke, restored from backup, some stuff still doesn't
    work", the most common cause for that in my experience is that the
    configuration changed between backup and the initial breakdown. Then
    this change won't be reflected in the restore.

    You say "this hostname only shows up with mailman", do you run your
    own MTA, or do you ship everything off to bellsouth which actually
    runs the MTA? Mailman is not really an MTA, but it does have to be
    quite a bit smarter than your typical MUA, so it may be that Mailman
    is picking up the hostname from /etc/hostname or from the DNS, whereas
    other programs are authenticating in some other way and bellsouth's
    MTA is happy with them but not with Mailman.
  • Brad Knowles at Jan 13, 2008 at 4:24 am

    On 1/12/08, Dennis Putnam wrote:

    Certainly, the name dap002.bellsouth.net does not exist in the DNS.
    If this is what your system is trying to use to identify itself to
    the outside world, that would be a problem.
    Only mailman is trying to use that name.
    Not true. Check your own syslog files. They very clearly say
    "dap002" in the hostname field. Syslog and perhaps other processes
    are somehow picking up that value from somewhere. You should find
    out where.
    I suspect that the problem you're having may be a hostname or MTA
    misconfiguration issue, which Mailman is not involved in, and which
    cannot be fixed within Mailman.
    If that we the case, why is it only mailman sending mail that is
    effected? As I demonstrated, when using the 'mail' command, everything
    is fine.
    You could trace the entire SMTP dialog process and see what input is
    actually being generated. With postfix, you could increase the
    debugging level, or you could use alternative programs (like tcpdump
    or WireShark) to sniff the traffic at the network layer. I'd suggest
    doing both.

    Without hard evidence one way or the other, it's difficult to tell.
    There is no MTA setting that would effect mailman and nothing else
    that I can find? Any suggestions?
    Within the MTA configuration, there should not be anything that would
    affect only Mailman. It should affect everything that passes through
    the machine, but for example if Mailman is using unqualified host
    names for outgoing mail, then the MTA may be configured to try to fix
    that, and in the process of "fixing" that, other problems might be
    caused.

    This is why you need to know exactly what is being sent "on the wire"
    between Mailman and the MTA, and what the MTA is doing internally
    with what it is getting from Mailman.
    Keep in mind this was a working system that started giving me trouble
    after a restore.
    It's entirely possible that the restore process may have missed some
    configuration file or some configuration option somewhere. Without
    more information, it's going to be impossible to tell.

    --
    Brad Knowles <brad at shub-internet.org>
    LinkedIn Profile: <http://tinyurl.com/y8kpxu>
  • Dennis Putnam at Jan 13, 2008 at 2:33 pm
    Success!!!!! :-D

    It seems I owe you another adult beverage of your choice. Thanks.

    Just out of curiosity, where is that parameter kept such that it did
    not get restored from the backup yet all the list archives and members did?
    At 09:44 PM 1/12/2008, you wrote:

    These will affect list attributes at list creation time but not
    subsequently. You can run fix_url to fix the list but in this case,
    that isn't necessary. In this case, all you need to do is go the the
    list admin General Options page and change "Host name this list
    prefers for email." (host_name) from dap002.bellsouth.net to
    home.bellsouth.net.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: PGP.sig
    Type: application/pgp-signature
    Size: 195 bytes
    Desc: not available
    Url : http://mail.python.org/pipermail/mailman-users/attachments/20080113/15634d11/attachment.pgp
  • Mark Sapiro at Jan 13, 2008 at 2:58 pm

    Dennis Putnam wrote:
    Success!!!!! :-D

    It seems I owe you another adult beverage of your choice. Thanks.

    Just out of curiosity, where is that parameter kept such that it did
    not get restored from the backup yet all the list archives and members did?

    host_name is in the list's config.pck file along with all the other
    list attributes, membership, options, etc.

    So the question is not why it didn't get restored, because it must
    have. The question is what else was different before that allowed it
    to work?

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Dennis Putnam at Jan 15, 2008 at 12:12 am

    At 08:14 AM 1/14/2008, you wrote:
    Ahh... your quoting seems to be working now... now I can at least
    make sense of your replies without straining...

    Next we'll address the top-posting problem... ;)
    The top posting problem was temporary until I could get the quoting
    working right. I figured it would be less confusing that way. :-)

    jk...

    --

    Best regards,

    Charles

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: PGP.sig
    Type: application/pgp-signature
    Size: 195 bytes
    Desc: not available
    Url : http://mail.python.org/pipermail/mailman-users/attachments/20080114/6e645221/attachment.pgp

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJan 9, '08 at 2:54a
activeJan 15, '08 at 12:12a
posts18
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase