If this helps it is the non delivery report
This is an automatically generated Delivery Status Notification
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipient has been delayed:
l...@intertron.net
Message will be retried for 2 more day(s)
Technical details of temporary failure:
The recipient server did not accept our requests to connect. Learn
more at http://mail.google.com/support/bin/answer.py?answer=7720
[domain.net (1): Connection refused]
On Wed, Sep 15, 2010 at 4:49 PM, Eric Alan Solo <sambarino1...@gmail.com> wrote:
> Ok, due to my lack of comprehension I'm going to just step through
> this troubleshooting guide and let you know the results, hopefully you
> will spot something that I am unable to see.
>
> -------------------------
>
> I'm going to assume Sendmail as the MTA (its still the most commonly
> found - though postfix is gaining ground): Note however that the only
> MTA specific items in this FAQ are item 3 about aliases which doesn't
> apply to all MTA configurations; item 4 about smrsh which applies only
> to sendmail, and item 11 about mm-handler which applies only to that
> rarely used configuration.
>
> 1. Check_perms. In all cases you should start by checking the
> permissions on the files that were setup:
> ~mailman/bin/check_perms
>
> /* r...@domain:/usr/lib/mailman/Mailman# check_perms
> * /var/lib/mailman/bin bad group (has: root, expected list)
> * /var/lib/mailman/scripts bad group (has: root, expected list)
> * /var/lib/mailman/templates bad group (has: root, expected list)
> * /var/lib/mailman/icons bad group (has: root, expected list)
> * /var/lib/mailman/cgi-bin bad group (has: root, expected list)
> * /var/lib/mailman/mail bad group (has: root, expected list)
> * /var/lib/mailman/Mailman bad group (has: root, expected list)
> * /var/lib/mailman/logs bad group (has: root, expected list)
> * /var/lib/mailman/locks bad group (has: root, expected list)
> * /var/lib/mailman/cron bad group (has: root, expected list)
> * Problems found: 10
> * Re-run as list (or root) with -f flag to fix
> *
> */ > I tried running check_perms -f but it doesn't do anything, not
> sure what the issue is here so I just moved on to look at other
> things.
>
> 2. Cron/mailmanctl.
> a. Mailman 2.0.x only - Make sure that the cron daemon is running
> ps aux |grep cron |grep -v grep
>
> / * root 506 0.0 0.3 2380 808 ? Ss Sep03 0:00 cron
> */ > looks right to me
>
> This will print out the process information about the cron daemon. If
> it returns a blank line, then cron is NOT running. NOTE: Mailman
> 2.0.13 and lower does not run an independent daemon. The qrunner
> process is run via cron.
>
> b. Mailman 2.1.x - Later versions of Mailman, versions 2.1 and
> above, need cron for certain support jobs, but not for normal mail
> delivery. In Mailman 2.1.x there is an independent daemon called
> mailmanctl. You need to make sure that the mailmanctl daemon is also
> running
> ps auxww| grep mailmanctl |grep -v grep
> */ list 29170 0.0 2.1 11296 5256 ? Ss Sep10 0:00
> /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
> */ > looks fine to me
>
> If this returns a blank line then the Mailman daemon is not running! Also, do
> ps auxww | egrep 'p[y]thon'
>
> or
>
> ps -fAww | egrep 'p[y]thon'
>
> /* list 29170 0.0 2.1 11296 5256 ? Ss Sep10 0:00
> /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
> * list 29171 0.0 2.8 10916 7012 ? S Sep10 0:46
> /usr/bin/python /var/lib/mailman/bin/qrunner --runner=ArchRunner:0:1
> -s
> * list 29172 0.0 2.9 11292 7332 ? S Sep10 0:50
> /usr/bin/python /var/lib/mailman/bin/qrunner --runner=BounceRunner:0:1
> -s
> * list 29173 0.0 2.8 10908 7004 ? S Sep10 0:46
> /usr/bin/python /var/lib/mailman/bin/qrunner
> --runner=CommandRunner:0:1 -s
> * list 29174 0.0 2.8 10920 7032 ? S Sep10 0:47
> /usr/bin/python /var/lib/mailman/bin/qrunner
> --runner=IncomingRunner:0:1 -s
> * list 29175 0.0 2.8 10896 7056 ? S Sep10 0:46
> /usr/bin/python /var/lib/mailman/bin/qrunner --runner=NewsRunner:0:1
> -s
> * list 29176 0.0 3.0 11276 7488 ? S Sep10 0:48
> /usr/bin/python /var/lib/mailman/bin/qrunner
> --runner=OutgoingRunner:0:1 -s
> * list 29178 0.0 2.8 10916 7232 ? S Sep10 0:45
> /usr/bin/python /var/lib/mailman/bin/qrunner --runner=VirginRunner:0:1
> -s
> * list 29179 0.0 2.8 10908 7016 ? S Sep10 0:00
> /usr/bin/python /var/lib/mailman/bin/qrunner --runner=RetryRunner:0:1
> -s
> */ > looks fine to me
>
> or however you might spell it on your system. This should show that
> mailmanctl and eight qrunner processes are all running. See item 6.
> below.
>
> 3. Aliases. To create a mailman list you ran "newlist" and it printed
> out four (or ten) lines that you needed to copy to the /etc/aliases
> file (or wherever your MTA goes to find its aliases). Check that the
> aliases are in /etc/aliases:
> grep wrapper /etc/aliases
>
> Note for version 2.1: "wrapper" has been replaced with "mailman",
> grep mailman /etc/aliases
>
> Even if the aliases are there, you may still need to reset the aliases
> hash table so that it includes this new alias information:
> newaliases
>
> Here is a typical alias listing for a group called "sys":
> ## Mailman verion 2.0.x system mailing list
> sys: "|/home/mailman/mail/wrapper post sys"
> sys-admin: "|/home/mailman/mail/wrapper mailowner sys"
> sys-request: "|/home/mailman/mail/wrapper mailcmd sys"
> sys-owner: sys-admin
>
> And here's a typical list of aliases for the 'mailman' list in mailman 2.1.x.
> ## mailman mailing list
> mailman: "|/usr/local/mailman/mail/mailman post mailman"
> mailman-admin: "|/usr/local/mailman/mail/mailman admin mailman"
> mailman-bounces: "|/usr/local/mailman/mail/mailman bounces mailman"
> mailman-confirm: "|/usr/local/mailman/mail/mailman confirm mailman"
> mailman-join: "|/usr/local/mailman/mail/mailman join mailman"
> mailman-leave: "|/usr/local/mailman/mail/mailman leave mailman"
> mailman-owner: "|/usr/local/mailman/mail/mailman owner mailman"
> mailman-request: "|/usr/local/mailman/mail/mailman request mailman"
> mailman-subscribe: "|/usr/local/mailman/mail/mailman subscribe mailman"
> mailman-unsubscribe: "|/usr/local/mailman/mail/mailman unsubscribe mailman"
>
> If you are using Sendmail with virtual domains, you will have to also
> add entries into the into the 'virtusertable' to make the mapping for
> the virtual domain to the local aliases previously setup, similiar to
> the following:
> ## mailman virtual mappings
> s...@virtdomain.com sys
> sys-ad...@virtdomain.com sys-admin
> sys-requ...@virtdomain.com sys-request
> sys-ow...@virtdomain.com sys-admin
>
> then run 'make' or 'makemap' to rebuild the virtusertable.db file and
> restart sendmail. This solution is limited in that you can not have
> multiple virtual domain with the same local address/list name. NOTE:
> in mailman version 2.1 and above you may have a secondary aliases file
> that is used specifically for Mailman and the lists that it creates:
> ~mailman/data/aliases
>
> You will need to make sure that this alias file isrecognized by your
> MTA (postfix, sendmail, etc), and that it is up-to-date with your
> latest aliases. If you do not have integration turned on, or you do
> not have this alias file, then all your aliases must go in the
> standard /etc/aliases file as specified above.
>
> /* I totally ignored aliases on setup etc because the installation
> guide I was following said that I didn't need them, I "should" have
> configured the MTA (exim4) to do */ that stuff according to that guide
>
> 4. Smrsh. Check to see if your MTA uses smrsh. Red Hat as well as a
> few other distributions automatically setup Sendmail to use smrsh.
> Smrsh stops Sendmail from running a script or other program that is
> included in an alias. Mailman uses a program called "wrapper" to run
> all of its aliases (see the alias examples above):
> grep "smrsh" sendmail.cf
>
> /* grep: sendmail.cf: No such file or directory
> /* > makes no sense so I moved on
>
> If this comes up blank then Sendmail does not use smrsh and the rest
> of this section doesn't apply - skip to 5.; if not, then your server
> is probably running smrsh and you need to make sure that smrsh is
> setup to allow Mailman's wrapper program to run. Locate the smrsh
> directory and do an ls -l of that directory. On Red Hat:
> ls -l /etc/smrsh
>
> and the output should be similar to:
> wrapper -> /home/mailman/mail/wrapper
>
> Note: some systems setup the smrsh directory in:
> /usr/adm/sm.bin/
>
> Note: to find the sm.bin directory try:
> strings /usr/lib/smrsh | grep sm.bin
>
> Note for version 2.1: the wrapper program is now simply called "mailman",
> mailman -> /var/mailman/mail/mailman
>
> 5. Interface. Some distributions in a noble "attempt" to limit the
> number of open relays on the internet, default Sendmail so that it
> listens to a limited number of interfaces. The default interface that
> Mailman list's use is "localhost" (127.0.0.1) - this is configurable
> in Mailman's mm_cfg.py file. To check Sendmail's configuration file:
> grep "Port" sendmail.cf
> /* sendmail.cf: No such file or directory
> */ > makes no sense so I moved on
>
> This will list out the DeamonPortOption and indicate the interfaces it
> listens on (0.0.0.0 would mean all interfaces). You can also check out
> which interfaces your MTA is listening on by using:
> netstat -na |grep ":25 "
> /* tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
> */ > looks right to me
>
> In a similar vein, some folks have reported that "localhost" is not
> defined in their /etc/hosts file (it should be set to 127.0.0.1). Also
> make sure /etc/hosts is world readable. Also see 4.73 How do I debug
> smtp-failure problems - delivery to user-example.com failed with code
> -1- and Low level smtp error-. The settings in
> ~mailman/Mailman/mm_cfg.py (or Defaults.py) that are used to set these
> "Delivery Defaults":
> DELIVERY_MODULE = 'SMTPDirect'
> SMTPHOST = 'localhost'
> SMTPPORT = 0 # default from smtplib
> /* My settings do reflect those values
> */
>
> 6. qrunner.
> Mailman 2.0.x only - If you are running Mailman 2.0.x then qrunner is
> run every minute via a cron job (that is why cron must be running for
> Mailman to work). Try running the program by hand. The exact syntax
> can be found in Mailman's cron jobs:
> su mailman
> crontab -l
> /* when i try to run crontab -l i get this:
> * no crontab for root
> */ don't understand what I'm supposed to do
>
> Here is an example of running qrunner by hand:
> su mailman
> /usr/bin/python -S /home/mailman/cron/qrunner
>
> If this generates any errors then send those to the list for diagnosis
> - or look at the last few lines of errors and search the list for key
> words from the error messages.
> Mailman 2.1.x - If you are running Mailman 2.1.x then the qrunners are
> daemons that are started by $prefix/bin/mailmanctl, which itself may
> be being run via a 'mailman' startup script. This is described in the
> INSTALL document for the version of MM you are running. Note that
> there are eight qrunners. These runners and their functions are:
> ArchRunner # messages for the archiver
> BounceRunner # for processing of bounces
> CommandRunner # commands and confirmations from the outside world
> IncomingRunner # posts from the outside world
> NewsRunner # outgoing messages to the nntpd
> OutgoingRunner # outgoing messages to the smtpd
> VirginRunner # internally crafted (virgin birth) messages
> RetryRunner # retry temporarily failed deliveries
>
> If you aren't doing any gatwaying to usenet, you can do without
> NewsRunner, and if you aren't archiving any lists, you can do without
> ArchRunner, but the other six are required to be running for normal
> Mailman operation. Also note that if any queues are 'sliced' there
> will be more than one runner for that queue, and you need them all.
> For example, if OutgoingRunner is set up for 4 slices, there will be
> four copies of OutgoingRunner processing slices 0:4, 1:4, 2:4 and 3:4.
> If any of these four is not running, its portion of the out queue will
> not be processed.
>
> 7. Locks. A errant lock file can stop a list from processing as
> Mailman waits for the lock to be removed. Since your list is not
> sending, we shall assume that no lock files should be on the list and
> that it is safe to delete any we find.
> Note that we are talking here about locks with the list name as part
> of the lock file name. The master-qrunner locks are normal and are not
> the cause of non-delivery problems. On the contrary, if they
> weren't there it would indicate that the qrunners weren't running.
> ls -l ~mailman/locks
>
> The output will be something like:
> qrunner.lock.moya.trilug.org.22845
>
> /* > I don't get that output, I get: "lrwxrwxrwx 1 root root 17
> 2010-09-10 05:45 locks -> /var/lock/mailman"
> * > I know that's not really checking the locks but not sure what to do
> * > I tried "ps aux | grep qrunner" and got
> * root 14818 0.0 0.3 3332 824 pts/0 S+ 10:34 0:00 grep
> qrunner
> */ > along with the other 8 runners
>
> This indicates that process # 22845 created the lock. To look at this
> process and see what it is (if it still exists):
> ps aux |grep 22845 |grep -v grep
>
> 8. Logs. If you don't have any of the common problems above, then you
> should look for errors in your log files. First look for errors in
> your MTA log files. On Red Hat that would be in /var/log/maillog. Look
> in the log starting at the time you sent a test message. You should
> see your initial message come in and be passed on to your Mailman
> list, afterwards you may see warnings or errors caused by Mailman
> trying to send out mail to the members of the list.
> Next look in Mailman's logs. The files are in ~mailman/logs/ or
> usually /var/log/mailman on RedHat.
> There are several logs to look in for problems:
> error
> smtp-failure
> smtp
> vette
> locks
> post
> qrunner
>
> Note: if you look in the qrunner log you may see several warnings
> about "Could not acquire qrunner lock", these are actually normal and
> are NOT a problem, but other messages about qrunners terminating and
> being restarted or not do indicate a problem.
> Every line in the log files is dated so you should be able to isolate
> the place in the log files to start looking, based on when your
> problem started.
> What do the logs and the times of the entries in your MTA show. Is it
> passing the mail into the mailman alias properly? Check the time.
> Now check the Mailman post log and when it shows the message accepted
> for posting. The time should be very close to the MTA's time.
> Now back to the MTA, does it show the message going out to the various
> folks on the list?
>
> /* There are no logs for any of the emails I try to send to the
> mailman address, if I send a mail via the command line then there are
> logs for it, also for the
> */ subscribed mail, both of those things do work though
>
> 9. Qfiles. You may have a malformed email (or one that is simply too
> big) clogging up the flow of mail to your lists. Mail that is queued
> up by Mailman is stored in the directory:
> ~mailman/qfiles
>
> or in FHS compliant RedHat systems
> /var/spool/mailman
>
> /* All the qfiles directories are empty
> */
>
> Move any files out of the directory and into a temporary directory,
> then send a new test message to your list. If that works, then you can
> move some of the old queued up files back and let those process. If it
> stops working again then you have a bad message in that batch - delete
> them or copy them to a different temporary directory.
> Note that files accumulating in a queue directory can also mean that
> its qrunner (or one of its slice qrunners) is not running. See 1b and
> 5b above
>
> 10. SMTPHOST. Mailman would accept messages but they wouldn't go
> anywhere. logs/smtp would just show "All recipients refused: (61,
> 'Connection refused')". My mailserver is configured to listen only on
> its external IP address, no localhost or anything like that. I had to
> add to ~mailman/Mailman/mm_cfg.py:
> SMTPHOST = '<ip of my mailserver>'
>
> After that Mailman started working perfectly.
> /* Seeing as there are no smtp logs I dont think there is a point to
> changing it from my hostname to the ip
> */
>
> 11. Sendmail + mm-handler. If your mail is not getting to the mailing
> list then try testing mm-handler independently of sendmail:
> echo "From: jblo...@hotmail.com
> To: testl...@mailman.mydomain.com
> Subject: Test
> test mail body
> " | /etc/mail/mm-handler mailman.mydomain.com \
> -r jblo...@hotmail.com testlist
>
> To test with sendmail without your email client try:
> echo "From: jblo...@hotmail.com
> To: testl...@mailman.mydomain.com
> Subject: Test
> test mail body
> " | /usr/sbin/sendmail -fjblo...@hotmail.com \
> testl...@mailman.mydomain.com
>
> Also try editing mm-handler and setting DEBUG=1 and rerun the sendmail
> command above and see if you get a bounce.
>
> /* I can send mail from command line
> */
>
> 12. Topics. If your list has topics defined, make sure users have
> appropriate settings to receive the posts they want.
>
> /* no topics
> */
>
> 13. Archives. If your list(s) have archives, do posts get archived? If
> so, the problem is almost certainly in outgoing mail delivery. Focus
> on OutgoingRunner, qfiles/out, the 'error', 'smtp' and 'smtp-failure'
> logs and the logs of your MTA.
>
> /* no archives, they're empty (and i'm going to turn them off anyway)
>
> If none of the above steps helps, then try seeking out help on the
> mailman-users@python.org mailing list. When submitting your problem to
> the list please include the following information:
> version of mailman you are running,
> how it was installed (via rpm, apt-get, or source),
> version of OS your server is running,
> the MTA (sendmail, postfix, exim, qmail, etc) running on your server.
>
> /* using...
> * mailman 1:2.1.13-1
> * exim4 4.71-3ubuntu1
> * installed via apt-get
> * on ubuntu 10.04 server
> */
> -------------------------
>
> Thanks for your time,
> Eric
> On Fri, Sep 10, 2010 at 4:59 PM, Eric Alan Solo <sambarino1...@gmail.com>
> wrote:
>> ok, thanks
>>
>> On Fri, Sep 10, 2010 at 4:54 PM, Mark Sapiro <m...@msapiro.net> wrote:
>>> Eric Alan Solo wrote:
>>>>
>>>>Thanks for the response,
>>>>I was chatting with some guys in the irc channel who helped me a bit,
>>>>I'm now able to access the web interface.
>>>>Also I was able to send a message from the console, so now I need to
>>>>figure out why none of the mailman mails are being delivered.
>>>
>>>
>>> See the FAQ at <http://wiki.list.org/x/A4E9>.
>>>
>>> --
>>> Mark Sapiro <m...@msapiro.net> The highway is for gamblers,
>>> San Francisco Bay Area, California better use your sense - B. Dylan
>>>
>>>
>>
>
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
