[qmailtoaster] Re: stripped attachments...part II
On 07/17/2014 01:32 PM, Eric Broch wrote: I have a query into the dovecot user's group concerning the implementation of 'any' spam filter, including DSPAM, in the dovecot-lda process as their site does not make it obvious to me how to do it. There's a plugin for that. I mentioned it either here or on the devel list recently. I think it's called anti-spam. I've found a source for Maildrop (standalone) in the event it is no longer supported by QMT and in the interim: 1) wget http://dl.atrpms.net/el6-i386/atrpms/stable/atrpms-repo-6-7.el6.i686.rpm 2) rpm -Uvh atrpms*.rpm 3) yum install maildrop I don't have a problem keeping maildrop around. It's rather large for what it does, but so what? Even after it's no longer a part of the stock QMT (if indeed that ever happens), I imagine that it will remain in the repos in a deprecated state. I've thought about wading into the DSPAM code myself as it has worked so well for me, and still is. If we have someone (or two) who wants to maintain the sources, I wouldn't be adverse to include it in the QMT 'family' of software. Thanks! -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: stripped attachments...part II
On 07/16/2014 07:34 PM, Eric Broch wrote:
Update:
I think you were correct in the last statement of the above email, EricS.
I've found a workaround for this issue, if anyone cares, as DSPAM MAY be
on the ropes, though, I'll use it for as long as possible. Make the call
to dspam in the .mailfilter file instead of the .qmail-default file. Use
the 'xfilter' call like so:
exception {
xfilter /path/to/dspamc --user $EXT@$HOST --deliver=stdout
}
I've had it in place for a couple days and clients have reported
delivered attachments where once there was failure.
EricB.
That's interesting.
I expect that when we implement dovecot's deliver lda that it will be
able to handle dspam ok for you. Even though we might not make dspam
part of the stock QMT, I hope to people will still be able to use it if
they choose. Who knows? Maybe someone will step up to support it at some
point.
This makes me wonder if we might need to keep maildrop around as a
bridge to dovecot's deliver in order to implement that. I certainly hope
not. Seems like a wasteful step.
Anywise, thanks for your work on this, EB. :)
--
-Eric 'shubes'
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: stripped attachments...part II
On 7/17/2014 9:38 AM, Eric Shubert wrote:
On 07/16/2014 07:34 PM, Eric Broch wrote:
Update:
I think you were correct in the last statement of the above email,
EricS.
I've found a workaround for this issue, if anyone cares, as DSPAM MAY be
on the ropes, though, I'll use it for as long as possible. Make the call
to dspam in the .mailfilter file instead of the .qmail-default file. Use
the 'xfilter' call like so:
exception {
xfilter /path/to/dspamc --user $EXT@$HOST --deliver=stdout
}
I've had it in place for a couple days and clients have reported
delivered attachments where once there was failure.
EricB.
That's interesting.
I expect that when we implement dovecot's deliver lda that it will be
able to handle dspam ok for you. Even though we might not make dspam
part of the stock QMT, I hope to people will still be able to use it
if they choose. Who knows? Maybe someone will step up to support it at
some point.
This makes me wonder if we might need to keep maildrop around as a
bridge to dovecot's deliver in order to implement that. I certainly
hope not. Seems like a wasteful step.
Anywise, thanks for your work on this, EB. :)
I have a query into the dovecot user's group concerning the
implementation of 'any' spam filter, including DSPAM, in the dovecot-lda
process as their site does not make it obvious to me how to do it.
I've found a source for Maildrop (standalone) in the event it is no
longer supported by QMT and in the interim:
1) wget
http://dl.atrpms.net/el6-i386/atrpms/stable/atrpms-repo-6-7.el6.i686.rpm
2) rpm -Uvh atrpms*.rpm
3) yum install maildrop
I've thought about wading into the DSPAM code myself as it has worked so
well for me, and still is.
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: stripped attachments...part II
On 5/9/2014 1:24 PM, Eric Shubert wrote:
On 05/09/2014 11:19 AM, ebr...@whitehorsetc.com wrote:
Are you sure that both .qmail-default and .qmail are not used in the
delivery process? I'm seeing each email processed by both files as each
email has a dspam tag (.qmail-default) and also is logged by maildrop
(.qmail).
That said, I do have the servers set up to do the test you suggest.
I wouldn't bet my life on it, so no I'm not positive. It doesn't make
sense to me though that both would be invoked. So much for making sense.
Upon further review, it appears to me now that you're correct. The
domain's .qmail-default is used first, invoking vdelivermail, which
then must invoke the user's .qmail file if it exists. I need to do a
little more digging in the source to see what's really going on.
In the meantime, can you do a little more testing? I'm guessing that
the attachments are making it to the queue and they're being dropped
during delivery. Can you verify this? We'll simply need to track this
thing through the various stages to see where the problem is.
I'm guessing the problem is between dspam and vdelivermail. That's
just a guess though.
Update:
I think you were correct in the last statement of the above email, EricS.
I've found a workaround for this issue, if anyone cares, as DSPAM MAY be
on the ropes, though, I'll use it for as long as possible. Make the call
to dspam in the .mailfilter file instead of the .qmail-default file. Use
the 'xfilter' call like so:
exception {
xfilter /path/to/dspamc --user $EXT@$HOST --deliver=stdout
}
I've had it in place for a couple days and clients have reported
delivered attachments where once there was failure.
EricB.
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: stripped attachments...part II
On 05/09/2014 11:19 AM, ebr...@whitehorsetc.com wrote: Are you sure that both .qmail-default and .qmail are not used in the delivery process? I'm seeing each email processed by both files as each email has a dspam tag (.qmail-default) and also is logged by maildrop (.qmail). That said, I do have the servers set up to do the test you suggest. I wouldn't bet my life on it, so no I'm not positive. It doesn't make sense to me though that both would be invoked. So much for making sense. Upon further review, it appears to me now that you're correct. The domain's .qmail-default is used first, invoking vdelivermail, which then must invoke the user's .qmail file if it exists. I need to do a little more digging in the source to see what's really going on. In the meantime, can you do a little more testing? I'm guessing that the attachments are making it to the queue and they're being dropped during delivery. Can you verify this? We'll simply need to track this thing through the various stages to see where the problem is. I'm guessing the problem is between dspam and vdelivermail. That's just a guess though. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: stripped attachments...part II
On 05/09/2014 11:19 AM, ebr...@whitehorsetc.com wrote: Are you sure that both .qmail-default and .qmail are not used in the delivery process? I'm seeing each email processed by both files as each email has a dspam tag (.qmail-default) and also is logged by maildrop (.qmail). That said, I do have the servers set up to do the test you suggest. I wouldn't bet my life on it, so no I'm not positive. It doesn't make sense to me though that both would be invoked. So much for making sense. Upon further review, it appears to me now that you're correct. The domain's .qmail-default is used first, invoking vdelivermail, which then must invoke the user's .qmail file if it exists. I need to do a little more digging in the source to see what's really going on. In the meantime, can you do a little more testing? I'm guessing that the attachments are making it to the queue and they're being dropped during delivery. Can you verify this? We'll simply need to track this thing through the various stages to see where the problem is. I'm guessing the problem is between dspam and vdelivermail. That's just a guess though. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com Sadly, the reason for my sporadic invocation of help on this issue and the inability to test as I would please, is because it is unpredictable and getting clients' clients to resend the offending emails more than once is like herding cats. One person simply refused. However, I've got everything set up to catch the offending software during delivery and will let you know when possible. In your estimation, if there indeed was a problem between dspam and vdelivermail, how would one address this issue? Thanks for your help, EricS. EricB. - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: stripped attachments...part II
On 05/09/2014 12:53 PM, ebr...@whitehorsetc.com wrote: On 05/09/2014 11:19 AM, ebr...@whitehorsetc.com wrote: Are you sure that both .qmail-default and .qmail are not used in the delivery process? I'm seeing each email processed by both files as each email has a dspam tag (.qmail-default) and also is logged by maildrop (.qmail). That said, I do have the servers set up to do the test you suggest. I wouldn't bet my life on it, so no I'm not positive. It doesn't make sense to me though that both would be invoked. So much for making sense. Upon further review, it appears to me now that you're correct. The domain's .qmail-default is used first, invoking vdelivermail, which then must invoke the user's .qmail file if it exists. I need to do a little more digging in the source to see what's really going on. In the meantime, can you do a little more testing? I'm guessing that the attachments are making it to the queue and they're being dropped during delivery. Can you verify this? We'll simply need to track this thing through the various stages to see where the problem is. I'm guessing the problem is between dspam and vdelivermail. That's just a guess though. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com Sadly, the reason for my sporadic invocation of help on this issue and the inability to test as I would please, is because it is unpredictable and getting clients' clients to resend the offending emails more than once is like herding cats. One person simply refused. However, I've got everything set up to catch the offending software during delivery and will let you know when possible. In your estimation, if there indeed was a problem between dspam and vdelivermail, how would one address this issue? Thanks for your help, EricS. EricB. - I understand your situation. Diagnostics are tough when things aren't easily reproduced. One thing you might try is to use tee to capture what's going through the pipes. For instance, you could have this in .qmail-default: | tee -a /tmp/pre-dspam.log | /usr/local/bin/dspamc --user $EXT@$HOST --deliver=stdout | tee -a /tmp/post-dspam.log | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox This should give you 2 files, pre-dspam.log and post-dspam.log. These will get to be pretty big, so make sure you don't fill up a filesystem. You could use the same technique in the .qmail file. The tee command is very handy at times for capturing what goes through pipes. :) I'll let you know if I think of something else. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: stripped attachments...part II
On 05/08/2014 11:17 AM, Eric Broch wrote: Hello list, I've had this ongoing problem but have left it hanging as it is difficult to test sometimes, but one of my clients' clients has just gotten around to sending a test email with attachments to me (to test) and several of my client's employees and we're all experiencing stripped attachments from said email. Both my client and I use QMT hosts on CentOS 5 similarly configured, both using DSPAM. Below are 1) the clients QMT clamd and send logs and 2) my QMT clamd and send logs. The test email was sent by the sender to my client and me with 4 pdf attachments to users on each QMT host. As you can see in each log there the 4 scanned attachments (clamd log) and larger sized email logged (send log). Viewing the mail on the server and in the email client the attachments are gone and the size of the email changed. I've changed user and domain info, everything else is un-touched. 1a) Client's clamd log of questionable email 2014-05-08 10:31:16.745172500 Listening daemon: PID: 1606 2014-05-08 10:31:16.745177500 MaxQueue set to: 100 2014-05-08 10:40:28.678671500 /var/qmail/simscan/1399567228.63204.1757/msg.1399567228.63204.1757: OK 2014-05-08 10:40:28.679188500 /var/qmail/simscan/1399567228.63204.1757/addr.1399567228.63204.1757: OK 2014-05-08 10:40:28.680575500 /var/qmail/simscan/1399567228.63204.1757/textfile1: OK 2014-05-08 10:40:28.680735500 /var/qmail/simscan/1399567228.63204.1757/textfile2: OK 2014-05-08 10:41:06.642352500 /var/qmail/simscan/1399567258.553367.1809/msg.1399567258.553367.1809: OK 2014-05-08 10:41:06.642528500 /var/qmail/simscan/1399567258.553367.1809/addr.1399567258.553367.1809: OK 2014-05-08 10:41:06.643731500 /var/qmail/simscan/1399567258.553367.1809/textfile1: OK 2014-05-08 10:41:06.643909500 /var/qmail/simscan/1399567258.553367.1809/textfile2: OK 2014-05-08 10:41:06.644907500 /var/qmail/simscan/1399567258.553367.1809/Roof CMU Veneer Wall.pdf: OK 2014-05-08 10:41:06.645739500 /var/qmail/simscan/1399567258.553367.1809/Panel Wall.pdf: OK 2014-05-08 10:41:06.648692500 /var/qmail/simscan/1399567258.553367.1809/BPS_Elevations_100% SD.PDF: OK 2014-05-08 10:41:06.650922500 /var/qmail/simscan/1399567258.553367.1809/20140414111036551.pdf: OK 2014-05-08 10:51:05.884090500 No stats for Database check - forcing reload 1b) Client's send log of questionable email 2014-05-08 10:41:06.879908500 new msg 655979 2014-05-08 10:41:06.879931500 info msg 655979: bytes 2962846 from clientscli...@clientsclientdomain.com qp 1820 uid 89 2014-05-08 10:41:06.881908500 starting delivery 6524: msg 655979 to local mydomain.com...@mydomain.com 2014-05-08 10:41:06.883269500 status: local 1/10 remote 0/60 2014-05-08 10:41:11.099262500 delivery 6524: success: did_0+0+1/ 2014-05-08 10:41:11.099263500 status: local 0/10 remote 0/60 2014-05-08 10:41:11.099263500 end msg 655979 .. 2a) My clamd log of questionable email: 2014-05-08 10:38:34.593747500 /var/qmail/simscan/1399567110.56384.1642/msg.1399567110.56384.1642: OK 2014-05-08 10:38:34.593750500 /var/qmail/simscan/1399567110.56384.1642/addr.1399567110.56384.1642: OK 2014-05-08 10:38:34.595607500 /var/qmail/simscan/1399567110.56384.1642/textfile1: OK 2014-05-08 10:38:34.596172500 /var/qmail/simscan/1399567110.56384.1642/textfile2: OK 2014-05-08 10:38:34.598097500 /var/qmail/simscan/1399567110.56384.1642/Roof CMU Veneer Wall.pdf: OK 2014-05-08 10:38:34.603765500 /var/qmail/simscan/1399567110.56384.1642/Panel Wall.pdf: OK 2014-05-08 10:38:34.604838500 /var/qmail/simscan/1399567110.56384.1642/BPS_Elevations_100% SD.PDF: OK 2014-05-08 10:38:34.609207500 /var/qmail/simscan/1399567110.56384.1642/20140414111036551.pdf: OK 2b) My send log of questionable email: 2014-05-08 10:38:35.010130500 new msg 2883665 2014-05-08 10:38:35.010132500 info msg 2883665: bytes 2962824 from clientscli...@clientsclientdomain.com qp 1648 uid 89 2014-05-08 10:38:35.026076500 starting delivery 14591: msg 2883665 to local clientdomain.com-postmas...@clientdomain.com 2014-05-08 10:38:35.026079500 status: local 1/10 remote 0/60 2014-05-08 10:38:35.026080500 starting delivery 14592: msg 2883665 to local clientdomain.com-employ...@clientdomain.com 2014-05-08 10:38:35.026082500 status: local 2/10 remote 0/60 2014-05-08 10:38:35.393330500 delivery 14591: success: did_0+0+1/ 2014-05-08 10:38:35.393332500 status: local 1/10 remote 0/60 2014-05-08 10:38:35.782489500 delivery 14592: success: did_0+0+1/ 2014-05-08 10:38:35.782492500 status: local 0/10 remote 0/60 2014-05-08 10:38:35.782493500 end msg 2883665 This is a relatively new but ongoing issue. Can anyone point me in the right direction to solve this? EricB - While dspam isn't officially supported, we can certainly do our best to help you get things fixed up. I would suspect that the problem is happening during delivery. IOW, the attachments are making to the queue, but they're being stripped between the queue and
