Subscribe OK/ Doesn't Post [Imap-specific]
I have a unique problem. Users operating squirrelmail[via imap] can subscribe to a list. But cannot post to it.
They see the traffic, but when responding to a post, the replies never make it to the list.
The same user can switch to Eudora/Ximian/Kmail[pop3d] and respond to a post, and see their reply, it makes it to the list just fine.
I've read the logs in mailman, thinking smtp-failures log would have some answers, none found there or the other logs. I have also monitored traffic with my recv'ing MTA, it detects no mails coming from the web mail/squirrelmail submissions, but sees the complete pop3 sessions just fine.
/etc/aliases looks fine: stupid-pet-tricks1: postmaster
Any ideas on which logs I could trace an error out? It seems unique to imap clients, does anyone using Exim as their MM MTA suggest a look at transports/directors instead of Mailman itself?
-krb
At 3:57 AM -0700 2004/05/02, Karl R. Balsmeier wrote:
I've read the logs in mailman, thinking smtp-failures log would have some answers, none found there or the other logs. I have also monitored traffic with my recv'ing MTA, it detects no mails coming from the web mail/squirrelmail submissions, but sees the complete pop3 sessions just fine.
The problem sounds like it's on the sending MTA. Can you get the logs from that machine?
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
Thanks Brad,
Yes, the [below] output of the mail log on the sending server shows some detail, but perhaps not all. I will run the qmail on the sending server (the one where squirrelmail is being used) in debug mode and see if I can't capture a better explanation as to just why these imap-client sessions are failing...
Any ideas?
sendsrvr qmail: 1083496562.271934 new msg 2371240 sendsrvr qmail: 1083496562.272011 info msg 2371240: bytes 842 from <test@domain.org> qp 23610 uid 500 sendsrvr imapd: Connection, ip=[::ffff:127.0.0.1] sendsrvr imapd: LOGIN, user=test, ip=[::ffff:127.0.0.1], protocol=IMAP sendsrvr qmail: 1083496562.373877 starting delivery 39108: msg 2371240 to remote testlist@mailman.domain.org sendsrvr qmail: 1083496562.373939 status: local 0/10 remote 1/20 sendsrvr qmail: 1083496562.449644 delivery 39108: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/ sendsrvr qmail: 1083496562.449707 status: local 0/10 remote 0/20 sendsrvr imapd: LOGOUT, user=test, ip=[::ffff:127.0.0.1], headers=0, body=0
-karlski
At 3:57 AM -0700 2004/05/02, Karl R. Balsmeier wrote:
I've read the logs in mailman, thinking smtp-failures log would have some answers, none found there or the other logs. I have also monitored traffic with my recv'ing MTA, it detects no mails coming from the web mail/squirrelmail submissions, but sees the complete pop3 sessions just fine.
The problem sounds like it's on the sending MTA. Can you get the logs from that machine?
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
At 4:26 AM -0700 2004/05/02, Karl R. Balsmeier wrote:
sendsrvr qmail: 1083496562.373877 starting delivery 39108: msg 2371240 to remote testlist@mailman.domain.org sendsrvr qmail: 1083496562.373939 status: local 0/10 remote 1/20 sendsrvr qmail: 1083496562.449644 delivery 39108: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
Here's the problem. It's even spelled out in pretty plain english -- The remote server could not contact yours.
The exact reasons are not clear, but the problem is most likely on their end. Could be a firewall problem, or a routing problem, or who knows what. But this is something you need to discuss with the administrators of that machine and your local network support group.
You could also get some help from mailing lists or newsgroups that are specific to the MTAs you're using on both ends. But I think this is about as much help as we're likely to be able to provide.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
Brad, Thanks for the analysis, but i'm sticking to my guns. I have done my homework my friend! ; ) The reason I believe it's Mailman related is because SUBSCRIBING WORKS from Imap-clients but then when they POST, it doesn't come through. I can post to any other mailman-based list in the world with the same Imap-client, so I know it's not that. Question: How can an IMAP-client session connect just fine to subscribe to a list, go through all the motions involved with confirming & tailoring said subscription, and then mysteriously *not* work when it comes to *posting* a message to the list *that works in all other manner*? I understand the *logic* of the error I sent, but not the *SOURCE* after checking ALL logs. I am in FULL control of all of these machines, accounts, network, router, you name it. I know it can't connect because it says it can't, I am little more seasoned than you are giving me credit for. ****EVERYTHING works except this minor issue.*** Someone else asked that I run a test from the sending MTA, so I did. I only wanted to prove that it's not Mailman-specific, thus the contact with this list. I REPEAT: All other elements of the mailman setup work great from the same servers on both ends, e.g. Pop3-based client sessions work fine. Mailman integrates with other open-source programs, it's natural to get shunted around between the projects when a problem arises, so there's no negative element, just a sincere wish to fix an intermediate-level problem. -karlski
At 4:26 AM -0700 2004/05/02, Karl R. Balsmeier wrote:
sendsrvr qmail: 1083496562.373877 starting delivery 39108: msg 2371240 to remote testlist@mailman.domain.org sendsrvr qmail: 1083496562.373939 status: local 0/10 remote 1/20 sendsrvr qmail: 1083496562.449644 delivery 39108: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
Here's the problem. It's even spelled out in pretty plain english -- The remote server could not contact yours.
The exact reasons are not clear, but the problem is most likely on their end. Could be a firewall problem, or a routing problem, or who knows what. But this is something you need to discuss with the administrators of that machine and your local network support group.
You could also get some help from mailing lists or newsgroups that are specific to the MTAs you're using on both ends. But I think this is about as much help as we're likely to be able to provide.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
At 2:57 PM -0700 2004/05/02, Karl R. Balsmeier wrote:
The reason I believe it's Mailman related is because SUBSCRIBING WORKS from Imap-clients but then when they POST, it doesn't come through. I can post to any other mailman-based list in the world with the same Imap-client, so I know it's not that.
Are they posting "virgin" messages to the list, or replying to them? If they're replying, then the reply address is most likely getting munged somewhere, and it's probably not your server.
If they're posting virgin messages to the exact same address (well, address family) that they used to subscribe to the list, then you'd need to see more diagnostic data.
Question: How can an IMAP-client session connect just fine to subscribe to a list, go through all the motions involved with confirming & tailoring said subscription, and then mysteriously *not* work when it comes to *posting* a message to the list *that works in all other manner*?
This has nothing to do with IMAP. There's a problem somewhere with some program munging addresses, and it's hard to say where that problem is. Since everything else works with your server and all your other clients, the odds are extremely high that this problem is unique to the other server and perhaps some aspect of the other server, and therefore unrelated to Mailman ... which means that there is little more help that we are likely to be able to provide.
Someone else asked that I run a test from the sending MTA, so I did. I only wanted to prove that it's not Mailman-specific, thus the contact with this list.
The problem certainly seems to be something other than Mailman.
As such, I think we've probably provided you with about as much help as we're likely to be able to.
Mailman integrates with other open-source programs, it's natural to get shunted around between the projects when a problem arises, so there's no negative element, just a sincere wish to fix an intermediate-level problem.
I understand, but if the problem isn't specific to Mailman, then you're in the area of general mail-system debugging -- which is beyond the remit of this list.
That said, I think many of us would be willing to try to continue to help if we can, but you must understand that our ability to do so may well be very limited depending on the particular MTAs, MUAs, Local Delivery Agents, etc... that are in use on the various systems.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
participants (2)
-
Brad Knowles -
Karl R. Balsmeier