Re: QMAILQUEUE patch for qmail-1.03
I vote to leave it alone. Let the configuring individual invoke
/bin/sh in QMAILQUEUE herself if she understands and still wants to
make that particular convenience vs. overhead tradeoff.
Valued at $0.02,
JS
On Sun, Jun 10, 2001 at 10:26:28PM -0600, Bruce Guenter wrote:
>
> I've been contemplating rewriting the patch to do an exec of
> { "/bin/sh", "-c", $QMAILQUEUE } instead of exec'ing $QMAILQUEUE as-is.
> This would allow for putting the contents of the script named by
> $QMAILQUEUE (which is frequently a one-line shell script anyways) into
> the variable itself. Are there any downsides to this approach other
> than the obvious overhead of adding /bin/sh to the execution path? Is
> this overhead significant enough to make such a modification a bad idea?
> --
> Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/ http://untroubled.org/
> OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8
Re: need a badmailto solution
Check out badrcptto from the SPAMCONTROL patch set. JS On Mon, May 21, 2001 at 02:54:18PM -0500, Brian Moon wrote: > > I have a need to set up a file like badmailfrom that filters for recipients > in incoming emails. > > I have tried qtools but cannot find the right combo. > > What I have is a file with a bunch of email addresses in it that are all > known bad to addresses. Some come in as To, some as CC and some as BCC. I > can't block the user portion only (.qmail-address) as some are reused for > other domains on our site ([EMAIL PROTECTED] is bad but > [EMAIL PROTECTED] is not). > > Has anyone out there come up with a good solution for this? > > Thanks, > > Brian Moon > -- > dealnews.com, Inc. > Makers of dealnews & dealmac > http://dealnews.com/ | http://dealmac.com/ > >
Re: leave a copy of messages on server
FWIW, this is a tactic I have recommended on many occasions when an Outlook or Outlook Express user reports seemingly inexplicable behavior. It repairs such problems remarkably often. Respectfully, JS On Mon, May 21, 2001 at 10:37:17AM -0700, Isaac Chapman wrote: > > To fix my Outlook problem, I erased the appropriate Outlook email accounts > from the registry and then recreated it in Outlook. Not exactly sure why, > but this solved the problem. > > Outlook's account registry location: > HKEY_CURRENT_USER/Software/Microsoft/Office/Outlook/OMI Account > Manager/Accounts/ > > Where is the appropriate number for the email account connecting > with Qmail.
Re: patch combination: qmtp + outgoingip
Just FYI in case anyone was losing sleep over not being able to use the QMTP patch and the outgoing IP patche to qmail-remote.c at the same time. Well, and also to prevent my previous post from being an archive orphan. It turns out that the additional qmail_remote.c code for QMTP totally confuses the outgoingip patch, and even if the patch wasn't confused, it would have missed out on patching the additional call to the new flavor of timeoutconn(). With too few arguments passed in both cases, no wonder qmail_remote was choking. Case closed. Later, JS On Fri, May 18, 2001 at 05:31:19PM -0400, Jim Steele wrote: > > Does anyone have a qmail-remote.c that has been patched for qmtp AND > outgoingip? I must have botched the patch combination, since I now get: > > qmail-remote2001-05-18 17:21:26.339297500 delivery 1: deferral: >qmail-remote_crashed./ > > Thank goodness I backed up the binaries and use RCS on the source. > > Thanks, > JS
patch combination: qmtp + outgoingip
Does anyone have a qmail-remote.c that has been patched for qmtp AND outgoingip? I must have botched the patch combination, since I now get: qmail-remote2001-05-18 17:21:26.339297500 delivery 1: deferral: qmail-remote_crashed./ Thank goodness I backed up the binaries and use RCS on the source. Thanks, JS
Re: failure notice
This is not spam. This is the W32/Hybris worm. Your user is infected. Check the logs for the email message immediately preceding this one. That's probably your infected user, since Hybris attaches itself to the wsock2.dll library and sends out an email message immediately after a valid one is sent. See the following for more information on Hybris: http://www.sophos.com/virusinfo/analyses/w32hybrisd.html http://www.zdnet.com/anchordesk/stories/story/0,10738,2716778,00.html http://www.symantec.com/avcenter/venc/data/w95.hybris.gen.html http://www.sophos.com/virusinfo/articles/navidad.html Enjoy, JS On Wed, May 16, 2001 at 03:27:17PM -0400, Kirti S. Bajwa wrote: > From: "Kirti S. Bajwa" <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: RE: failure notice > Date: Wed, 16 May 2001 15:27:17 -0400 > X-Mailer: Internet Mail Service (5.5.2653.19) > > Hi: > > Somebody is using our company's mail server to send Spam mail. Following is > a copy of the bounced message. I have received hundreds of these messages. I > have looked into qmail-send logs and find bounced messages but the from > address is "garbage". > > It seems that person who is sending SPAM is a regular dial-in customer. For > example, the message below, this person logged in as a dial-in customer and > was assigned an IP address of 63.113.255.43, which is a valid IP address for > the dial-in modem bank. > > From this message or from qmail-send logs, I can't find out the user id of > this person. Is there any way I can stop it or better to find out who this > person is (sending SPAM)? > > Kirti
Re: tcpserver -p and smtpd and DNS
On Mon, May 14, 2001 at 12:35:32PM +, Mark Delany wrote: > > =.:allow > :deny > Close. To achieve this, the tcp.smtp file should actually contain: =:allow :deny I just experimented with both forms. With the dot, nothing matched, including hosts with good forward/reverse resolvability. Without it, only sites for which tcpserver didn't unset TCPREMOTEHOST matched. This, of course, is exactly the desired behavior. As already mentioned in this thread, tcpserver -p unsets TCPREMOTEHOST when the name obtained by reverse lookup can't be resolved to the original IP. Consequently, for such an (arguably) undesirable client IP, no match occurs at the "=:allow" line in the above tcp.smtp settings, since the "=" token only matches when TCPREMOTEHOST is defined. The ":deny" line then rejects those undesirable clients as they fall through. Just to be thorough, even if obvious, I'll also mention that these two lines must appear LAST in your tcp.smtp file.
