FAQ

However, when I look at /var/log/mailog after after sending mail to
the list, I don't see anything at all added to the log. That is, it
seems like the mail isn't even ever getting to the smtp server. I
also sent mail to a user on the server system directly, and nothing
showed up in the maillog.
Then it sounds like there's a disconnect between Mailman and your MTA.
Isn't /var/log/maillog an smtp-level log? I'm under the impression
that it has nothing to do with mailman in particular. I'm mentioning
this because as I said in a previous message, it seems like mail isn't
even reaching the system because when I send mail directly to a user
account on that system, there is no record of such a message in
/var/log/maillog. Likewise, there's no record of anything when I send
to a mailman list.
Check the logs in /usr/local/mailman/logs/smtp and
/usr/local/mailman/logs/smtp-failure, and compare those against the
MTA logs.
My smtp logs only contain outgoing messages sent by crond -- nothing
incoming. I don't have a smtp-failure log. Is the maillog the MTA log?
If not, where is the MTA log?
I have port 25 forwarded to my server -- is this all I have to do?
I'm not sure what you mean by "I have port 25 forwarded to my server".
My server is behind a router and SMTP's default port is 25. Therefore,
I've forwarded incoming requests on port 25 to the server. However,
there may be something else I need to do to get incoming mail to be
recognized.
You may need to enable increased debugging on your MTA to see
what is going on. If your MTA is not local, then you may need to use
network sniffing software to watch all SMTP transactions, so that you
can see what is going on.
My MTA is a local sendmail install. How do I increase debugging support?

Note that the only way I can get an incoming mail entry to show up in
maillog is if I send mail locally on the system from, say, root to
foo, where foo is a non-root user on the same system. Otherwise, I see
nothing at all.

So, unless I'm missing something, it looks like my problem is
independent of mailman.

Does anyone have suggestions?

Thanks,
jim

Search Discussions

  • Brad Knowles at Feb 17, 2005 at 11:40 pm

    At 6:23 PM -0500 2005-02-17, jpsota at gmail.com wrote:

    Isn't /var/log/maillog an smtp-level log?
    Typically, yes. It should be written by the syslog daemon, based
    on messages sent to syslog by the MTA.
    I'm under the impression
    that it has nothing to do with mailman in particular.
    Other than the fact that an incoming message has to hit the MTA
    before the MTA can pass that off to Mailman, and that Mailman has to
    hand off an outgoing message to the MTA before it can be delivered to
    the remote server, you are correct.
    I'm mentioning
    this because as I said in a previous message, it seems like mail isn't
    even reaching the system because when I send mail directly to a user
    account on that system, there is no record of such a message in
    /var/log/maillog. Likewise, there's no record of anything when I send
    to a mailman list.
    That sounds like you've got an MTA problem.
    Check the logs in /usr/local/mailman/logs/smtp and
    /usr/local/mailman/logs/smtp-failure, and compare those against the
    MTA logs.
    My smtp logs only contain outgoing messages sent by crond -- nothing
    incoming. I don't have a smtp-failure log.
    Outgoing messages sent by crond to ... where? Are they being
    sent to mailing lists or mailing list recipients?
    My server is behind a router and SMTP's default port is 25. Therefore,
    I've forwarded incoming requests on port 25 to the server. However,
    there may be something else I need to do to get incoming mail to be
    recognized.
    You'll need to make sure that your upstream ISP does not block
    all incoming port 25 connections. This is becoming more and more
    common for residential and other dynamic IP address connections.

    You'll also need to make sure that the DNS is set up correctly to
    direct all incoming mail for you to the IP address of your router,
    which should then be redirected to your server.
    My MTA is a local sendmail install. How do I increase debugging support?
    You need to modify the configuration file for sendmail. This
    might be a direct modification, or you might need to modify a
    sendmail.mc file, which would then be re-compiled into your
    sendmail.cf. This is going to depend on your particular OS, your
    configuration, etc....


    If you want to make the modification directly to your
    sendmail.cf, you'll need to find the line that says "LogLevel=" and
    increase the number specified -- the higher the number, the more data
    that will be logged. For what you're talking about doing, it is not
    likely that you would need to go above fourteen or fifteen.

    Once the line has been updated, you'll need to save the
    configuration file, and then stop and restart sendmail.
    Note that the only way I can get an incoming mail entry to show up in
    maillog is if I send mail locally on the system from, say, root to
    foo, where foo is a non-root user on the same system. Otherwise, I see
    nothing at all.
    Where is Mailman configured to send outgoing mail? To your local
    sendmail installation, or direct to your upstream ISP?
    So, unless I'm missing something, it looks like my problem is
    independent of mailman.
    The problem does seem to be in the MTA, that's true.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedFeb 17, '05 at 11:23p
activeFeb 17, '05 at 11:40p
posts2
users2
websitelist.org

2 users in discussion

Brad Knowles: 1 post Jpsota: 1 post

People

Translate

site design / logo © 2022 Grokbase