Topic: Checking MDA used by fetchmail?

[openSUSEftw]

Ok, I'll do my best not to revert to my trolling ways, but all of a sudden, SME has been throwing the following error:

Code: [Select]


Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 220 serv.dom.lan ESMTP
Jun  8 13:15:09 serv fetchmail[8658]: SMTP> EHLO localhost
Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 250-dom.lan Hi Unknown [127.0.0.200]
Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 250-PIPELINING
Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 250-8BITMIME
Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 250 SIZE 15000000
Jun  8 13:15:09 serv fetchmail[8658]: SMTP> MAIL FROM:<scrubbed@scrubbed> BODY=7BIT SIZE=290049
Jun  8 13:15:09 serv fetchmail[8658]: SMTP< 250 <scrubbed@scrubbed>, sender OK - how exciting to get mail from you!
Jun  8 13:15:09 serv fetchmail[8658]: SMTP> RCPT TO:<scrubbed@scrubbed>
Jun  8 13:15:10 serv fetchmail[8658]: SMTP< 250 <scrubbed@scrubbed>, recipient ok
Jun  8 13:15:10 serv fetchmail[8658]: SMTP> DATA
Jun  8 13:15:10 serv fetchmail[8658]: SMTP< 354 go ahead
Jun  8 13:15:12 serv fetchmail[8658]: SIGPIPE thrown from an MDA or a stream socket error

Now, as much as I would like to chalk this up to the upgrade I did last week, it's an ongoing issue. It just happens from time to time, but I've managed to isolate it this time with a little bit of effort.

So, my question is how do I check all these configuration properties? The config command reminds me of the Windows registry (sorry, but *shudder*. I happen to like Linux's config files) and doesn't provide much help in actually searching for a specific kind of key. My reasoning is, if I can find whatever the mail delivery agent is, I can check the logs and figure out how to work my way around this.

[CharlieBrady]

So, my question is how do I check all these configuration properties?

All what configuration properties? You haven't mentioned any, as far as I can see.

My reasoning is, if I can find whatever the mail delivery agent is, I can check the logs and figure out how to work my way around this.

fetchmail delivers mail via SMTP. You'll find logs in /var/log/qpsmtpd/current.

[openSUSEftw]

My apologies, CharlieBrady, I indeed didn't mention any. I kind of worked out the config command anyway, so ignore that one.

However, after trying again to upgrade the server and doing a signal-event post-upgrade && signal-event reboot, I'm still getting this error:

Code: [Select]

@400000004c0e42753b89eba4 11103 dispatching DATA
@400000004c0e42753b977094 11103 354 go ahead
@400000004c0e4276003faad4 11103 trying to get config for databytes
@400000004c0e42760049a96c 11103 max_size: 15000000 / size: 0
@400000004c0e42760056e03c 11103 trying to get config for timeout
@400000004c0e4276006caa5c 11103 spooling message to disk
@400000004c0e427601b66c54 11103 max_size: 15000000 / size: 1536
@400000004c0e427601c46674 11103 trying to get config for me
@400000004c0e427601d6062c 11103 451 Incomplete DATA
@400000004c0e42762ff8b16c 7145 cleaning up after 11103

The main one I'm worried about (and what I've been getting all afternoon) is that '451 Incomplete DATA' line. Is there a way to fix this? It seems to cause fetchmail to error out. I read a post somewhere while I was Googling a solution that invoking "fetchmail --blahblah - << EOF" causes some kind of weird error, but this doesn't seem to be the same one.

[CharlieBrady]

The main one I'm worried about (and what I've been getting all afternoon) is that '451 Incomplete DATA' line. Is there a way to fix this?

Not without diagnosing the problem first.

It seems to cause fetchmail to error out.

I think it is likely to be the other way around. qpsmtpd is writing '451 Incomplete DATA'  to its logs when the connection from fetchmail closes before fetchmail has written the '.\r\n' which indicates the end of the message text.

My advise is to avoid fetchmail - it's always been a buggy program. If you can't or won't do that, you'll need to learn why the socket connection between fetchmail and qpsmtpd is being closed prematurely.

[openSUSEftw]

Well, I found the problem. I was looking in completely the wrong place. It was the SPI on the router cutting off what it thought were malicious connections. Turned it off and everything's running sweet again. Thanks for your help