|
|
|
|
|
|
| Author |
Message |
love wadhwa
*nix forums beginner
Joined: 21 Jul 2006
Posts: 1
|
 Posted: Fri Jul 21, 2006 4:26 am Post subject:
Fwd: problem
|
|
|
---------- Forwarded message ----------
From: love wadhwa <lovewadhwa@gmail.com>
Date: Jul 20, 2006 7:17 PM
Subject: problem
To: de5@ornl.gov
Sir
i installed qmail referring your article "life with qmail"after installation
i used mrtg as for benchmarking in which i got the 19300 messages being
delivered in 1 hour.however i need to increase it to 25000/hour.i have
increased the concurrency.Please help me to reach that target.I really need
it.I have searched for patches but couldn;t know which one to apply
for.ialso don;t know how to prevent dns query for outgoing mail .do
help me sir.
Hoping a quick and positive response from ur side.
Warm Regards
Love Wadhwa
RedHat Certified Engg
--
Warm Regards
Love Wadhwa
RedHat Certified Engg |
|
| Back to top |
|
 |
BAGI Akos
*nix forums beginner
Joined: 08 Apr 2005
Posts: 17
|
| Posted: Tue Jul 18, 2006 4:56 pm Post subject:
Re: ezmlm-manage problem Solved!
|
|
|
Hi ME!
Here is the solution:
I found it in the ezmlm-idx -> ezmlm-make docuomentation at the
virtualdomain part:
I wrote the lkmd-agaba-test3 in the inlocal ( originally was agaba-test3)
Then qmailctl hup and that's it.
Thx me for helping me.
BR
Akos
BAGI Akos írta:
| Quote: | Hi List!
I'm using qmail since 2 years without problems.
I have ssmtpd, spop3, rblsmtpd, smtp-auth and virtual domains using the
qmail's virtualdomain entries (like: domain:domain-code).
Now I'm setting up a mailing list with ezmlm.
I downloaded the latest(?) DJB's page ezmlm-0.53.tar.gz (62693 bytes)
I had to edit the sorce because the ezmlm-manage log() type-mismatch
problem.
The list name is: test3
The user is: agaba
The domain is: lelekmod.hu
The domain code is: lkmd
The sender is abagi@compuflex.hu
The receipent is: agaba-test3-help@lelekmod.hu
At the time:
The list is working if I write a mail to agaba-test3@lelekmod.hu.
But the automatic functions (like, help, sub and unsub) are not working.
Here is the send/current log:
-----------------------------------------------------
@4000000044bc804411cd4dec new msg 2561556
@4000000044bc804411cd655c info msg 2561556: bytes 854 from
abagi@compuflex.hu> qp 17507 uid 1015
@4000000044bc8044120b879c starting delivery 3037: msg 2561556 to local
lkmd-agaba-test3-help@lelekmod.hu
@4000000044bc8044120ba2f4 status: local 1/10 remote 0/20
|
| Quote: | @4000000044bc8044126d04a4 delivery 3037: failure:
ezmlm-manage:_fatal:_I_do_not_accept_messages_at_this_address_(#5.1.1)/
|
| Quote: | @4000000044bc8044126d1ffc status: local 0/10 remote 0/20
@4000000044bc804414507e2c bounce msg 2561556 qp 17510
@4000000044bc8044145091b4 end msg 2561556
------------------------------------------------------------------------ |
|
|
| Back to top |
|
|
Miroslav Pendev
*nix forums beginner
Joined: 14 Jul 2006
Posts: 4
|
| Posted: Fri Jul 14, 2006 3:17 pm Post subject:
Re: Messages sitting in /var/qmail/queue/mess/ (ALRM doesn't help)
|
|
|
On Fri, Jul 14, 2006 at 09:55:07AM -0400, Kyle Wheeler wrote:
| Quote: | On Thursday, July 13 at 09:56 PM, quoth Miroslav Pendev:
Accoring to:
http://www.cyberis.net/support/qmail/misc/INTERNALS.phtml
the messages are stuck in the middle of stage S3.
I guess instead of an empty file in intd/ , there should be the envelope
information of the message in the file...
Is there any way to fix this so that qmail can 'see' them as messages
for delivery?
Have you tried any of the queue-repair tools?
|
Yes, I tried queue-fix and queue-repair against a backup copy, but they didn't
detect the actual issue.
Although they seem to be good tools, IMHO they are tools to repair the directory
structure and permissions, not exactly for problems like this one. The structure
is OK.
If I am not wrong, to fix this is actually more complicated as qmail wasn't able
to create the envelope info (who is the message coming from, and where it is
suppose to go).
So the 'fix' will have to parse the messages and manually recreate that info.
If you know a tool that can do that, let me know and I will try it.
It would probably be easier to qmail-inject these messages, than to parse them
and fix the envelopes for the queue.
Thanks,
Miro |
|
| Back to top |
|
|
Kyle Wheeler
*nix forums Guru Wannabe
Joined: 07 Jan 2005
Posts: 208
|
| Posted: Fri Jul 14, 2006 1:55 pm Post subject:
Re: Messages sitting in /var/qmail/queue/mess/ (ALRM doesn't help)
|
|
|
On Thursday, July 13 at 09:56 PM, quoth Miroslav Pendev:
| Quote: | Accoring to:
http://www.cyberis.net/support/qmail/misc/INTERNALS.phtml
the messages are stuck in the middle of stage S3.
I guess instead of an empty file in intd/ , there should be the envelope
information of the message in the file...
Is there any way to fix this so that qmail can 'see' them as messages
for delivery?
|
Have you tried any of the queue-repair tools?
~Kyle
--
Man cannot live by bread alone. He must have peanut butter.
-- Bill Cosby |
|
| Back to top |
|
|
Miroslav Pendev
*nix forums beginner
Joined: 14 Jul 2006
Posts: 4
|
| Posted: Fri Jul 14, 2006 1:56 am Post subject:
Re: Messages sitting in /var/qmail/queue/mess/ (ALRM doesn't help)
|
|
|
| Quote: | The problem is that in the queue I have ~1300 messages that qmail doesn't
want to deliver - probably because the queue is broken.
They are all sitting in:
/var/qmail/queue/mess/
and I can open and read them - there is nothing wrong with the files.
|
Just to add some more info:
qmail-qstat returns:
messages in queue: 1449
messages in queue but not yet preprocessed: 0
each of these messages has an empty file in intd/ folder (with the same filename
as in mess/)
Accoring to: http://www.cyberis.net/support/qmail/misc/INTERNALS.phtml
the messages are stuck in the middle of stage S3.
I guess instead of an empty file in intd/ , there should be the envelope
information of the message in the file...
| Quote: | Is there any way to fix this so that qmail can 'see' them as messages
for delivery?
|
Thanks,
Miro |
|
| Back to top |
|
|
Matt Simpson
*nix forums beginner
Joined: 29 Dec 2005
Posts: 19
|
| Posted: Thu Jun 15, 2006 1:41 pm Post subject:
Re: gmail
|
|
|
At 6:11 AM 6/15/06, Ted Fines wrote:
| Quote: | This is changing the direction of this topic, but am I the only one
worried about doing this?
|
No.
| Quote: | Even though Google is widely accepted as the 'good' guy right now,
that can all change very quickly.
|
I think it's already beginning to change.
| Quote: | When Google becomes the 'bad' guy -- and that is not an if, that is a when --
|
Agree that it's "when" instead of "if" .... but maybe disagree that
it's in the future.
Remember, Google fought the government's request for all their search
data only because they were worried it would expose trade secrets,
not because they were worried about privacy. They turned over data
to the Chinese government because that's the cost of doing business
in China. So they value privacy only until it conflicts with their
bottom line. |
|
| Back to top |
|
|
Ted Fines
*nix forums addict
Joined: 21 Jan 2005
Posts: 73
|
| Posted: Thu Jun 15, 2006 11:11 am Post subject:
Re: qmail+gmail spam filtering
|
|
|
--- Original Message ---
| Quote: | On Wednesday 14 June 2006 18:46, you wrote:
Hello almighty wise ones....
Just a thought....I read today that gmail can act as spam filtering.
Wondering is there anybody with detailed intructions on how to achive this
with qmail. Anybody has proven this to be tru....? If this works..then
qmail will have double filter rite provided you configured spamassassin
with it..
i'd imagine you just point your MX at gmail and forward it
from there.
qmail doesn't even need to know about gmail.
|
This is changing the direction of this topic, but am I the only one worried about doing this? gmail offers a number of 'free' services, such as webmail and more recently, complete e-mail hosting for companies. All 'free'. Anyone in touch with reality knows this is not free. They are mining all data flowing through them six ways from Sunday.
Even though Google is widely accepted as the 'good' guy right now, that can all change very quickly. Think Wal-Mart when Sam Walton was running it compared to how it is run now. When Google becomes the 'bad' guy -- and that is not an if, that is a when -- it will still have years worth of personal information about you that you've freely handed over to them.
Just something to think about...
Ted |
|
| Back to top |
|
|
Markus Stumpf
*nix forums Guru Wannabe
Joined: 11 Jan 2005
Posts: 122
|
| Posted: Wed May 31, 2006 11:15 am Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
On Tue, May 23, 2006 at 02:59:10PM -0600, Blair Lowe wrote:
| Quote: | What purpose do you think your backup MXes are serving?
To catch and queue email that has been sent when the higher precedent
email servers are down.
|
This is a bad idea.
I have full control over my own mailserver. If it cannot send a message
for three hours I can configure it to return the message to the sender,
so that the sender can use other ways to reach the recipient if it is
urgent. I know that eMail is no real time communication medium, but I
can assume it is and handle accordingly if this doesn't work.
If your main mailserver is down for 10 days and all mail is queued at
the backup MXs all I can see that it has left my mailserver and one of
yours has picked it up. Can I assume the mail has reached the destination
if I get no immediate/timely (within e.g. 4 hours) error? Would you
assume this?
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
Don't claim that you know everything. Besides not being
true it is very irritating to those of us who do. |
|
| Back to top |
|
|
Donald Nash
*nix forums beginner
Joined: 11 Mar 2005
Posts: 14
|
| Posted: Wed May 24, 2006 2:05 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
--On May 23, 2006 2:59:10 PM -0600 Blair Lowe <qmail@domainsunder.ca> wrote:
| Quote: | The only problem is that we are now relying on the sender to resend and
do his job according to RFC's.
|
As opposed to relying on the sender to send to a backup MX when the primary
is down, and do his job according to the RFCs?
| Quote: | I have found that quite often this is not the case
|
I find that quite surprising. Do you have numbers quantify this, or is it
something you've noticed but not really nailed down? My point is, this
problem may not be as bad as you think. For that matter, I'm a bit puzzled
as to how you'd observe it at all, since the lack of a retry means the
messages never arrives and thus cannot be observed. In any case, the vast
majority of legitimate mail software out there (sendmail, qmail, Postfix,
Exim, Exchange, Notes, Groupwise, and probably lots more that don't occur
to me at the moment), implements queue-and-retry. In fact, the only mail
software I know of that doesn't do queue-and-retry (at least not at the
moment), is spamware.
Sounds like you have a decision to make. Which is more important, catering
to senders with broken SMTP clients who can't do something as simple as a
retrying later when the destination SMTP server is down, or closing down a
path by which spammers reach you? In my opinion if someone doesn't value
their own mail enough to implement queue-and-retry to help ensure it gets
delivered, then it's not your job to value it more than they do. Backup
MXes are generally more trouble than they're worth.
--
Donald L. Nash, <D.Nash@its.utexas.edu>
Information Technology Services, The University of Texas at Austin |
|
| Back to top |
|
|
Blair Lowe
*nix forums beginner
Joined: 28 Dec 2005
Posts: 28
|
| Posted: Tue May 23, 2006 8:59 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
On Mon, 2006-08-05 at 18:23 -0600, Charles Cazabon wrote:
| Quote: | Blair Lowe <qmail@domainsunder.ca> wrote:
I was looking for a way to block spammers from using higher procedence
level MX records.
The best way is to eliminate your backup MXes. DNS and SMTP tells the client
the difference between "no such domain" and "not accepting connections at the
moment"; clients will back off and try again.
|
The only problem is that we are now relying on the sender to resend and
do his job according to RFC's. I have found that quite often this is not
the case, so my clients would loose mail if the primary servers are
down.
| Quote: |
Others choose to deploy dummy backup MXes that simply reject all mail, on the
grounds that only the spammers will try connecting to those machines. I
personally think that's a little riskier, unless they're physically hosted in
the same network and so suffer from identical connectivity.
What purpose do you think your backup MXes are serving?
|
To catch and queue email that has been sent when the higher precedent
email servers are down.
Blair. |
|
| Back to top |
|
|
Michael Di Martino
*nix forums addict
Joined: 09 Jan 2005
Posts: 69
|
| Posted: Thu May 18, 2006 10:10 pm Post subject:
Re: Chris Berry's lazyness
|
|
|
Since this thread has nothing to do with qmail please take off list.
Regards,
Michael Di Martino
Director of MIS
The telx Group
Office: 212 480 3300 X.2022
Cell: 646 207 6603
mdm@telx.com
--------------------------
Sent from my BlackBerry Wireless Handheld |
|
| Back to top |
|
|
Blair Lowe
*nix forums beginner
Joined: 28 Dec 2005
Posts: 28
|
| Posted: Fri May 12, 2006 5:59 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
On Tue, 2006-09-05 at 14:00 -0400, Chris Garrigues wrote:
| Quote: | From: John Levine <johnl@iecc.com
Date: 9 May 2006 17:03:02 -0000
Unfortunately, the anti-spam appliance is highest priority, and the
secondary is the real mail server, so we need to actually get mail on
the secondary server while the primary sorts through the junk.
If I were you, I would not make the real mail server an MX at all,
but instead configure the appliance manually to know where to
send the filtered mail.
My real mail server is behind a firewall and I have two different firewalls
listed with MXes. I used to have my web server listed with a very high MX and
it returned 451 for everything, but I disabled that after discovering (through
user complaints) that there are some real mail servers who tried to send
everything there. Can you believe it?
|
Yes I do believe it. It is that kind of stupidity with some mail server
programmers that causes problems such as this in the first place
(otherwise I would not need an offsite MX at all, and the sender would
properly resend for a week).
TTYL,
Blair. |
|
| Back to top |
|
|
Chris Garrigues
*nix forums beginner
Joined: 09 Jun 2005
Posts: 5
|
| Posted: Tue May 09, 2006 5:23 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
| Quote: | From: John Levine <johnl@iecc.com
Date: 9 May 2006 17:03:02 -0000
Unfortunately, the anti-spam appliance is highest priority, and the
secondary is the real mail server, so we need to actually get mail on
the secondary server while the primary sorts through the junk.
If I were you, I would not make the real mail server an MX at all,
but instead configure the appliance manually to know where to
send the filtered mail.
|
My real mail server is behind a firewall and I have two different firewalls
listed with MXes. I used to have my web server listed with a very high MX and
it returned 451 for everything, but I disabled that after discovering (through
user complaints) that there are some real mail servers who tried to send
everything there. Can you believe it?
Chris
--
Chris Garrigues Trinsic Solutions
President 710-B West 14th Street
Austin, TX 78701-1755
512-322-0180 http://www.trinsics.com
Would you rather proactively pay for
uptime or reactively pay for downtime?
Trinsic Solutions
Your Proactive IT Management Partner |
|
| Back to top |
|
|
John R Levine
*nix forums beginner
Joined: 08 Mar 2005
Posts: 39
|
| Posted: Tue May 09, 2006 5:03 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
| Quote: | Unfortunately, the anti-spam appliance is highest priority, and the
secondary is the real mail server, so we need to actually get mail on
the secondary server while the primary sorts through the junk.
|
If I were you, I would not make the real mail server an MX at all,
but instead configure the appliance manually to know where to
send the filtered mail.
By the way, for a spam trap server, I much prefer to use rblsmtpd:
#!/bin/sh
RBLSMTPD="Mail service not available."
export RBLSMTPD
# block everything
exec tcpserver -u120 -g105 -v -p -c60 -R 10.1.1.1 smtp \
/usr/local/bin/rblsmtpd -r'localhost' \
/usr/local/bin/fixcrio \
/bin/echo "500 Internal error. You shouldn't see this" 2>&1
This rejects everything with 451 so if a real mail server stumbles on
it by mistake, it'll retry the real mail server later. If you want it
to do a 553 instead, put a hyphen at the front of the RBLSMTPD string.
R's,
John |
|
| Back to top |
|
|
Blair Lowe
*nix forums beginner
Joined: 28 Dec 2005
Posts: 28
|
| Posted: Tue May 09, 2006 4:37 pm Post subject:
Re: blocking higher precedence MX servers from spammers
|
|
|
On Mon, 2006-08-05 at 21:35 -0400, Peter Kleiner wrote:
| Quote: | Charles Cazabon wrote:
Blair Lowe <qmail@domainsunder.ca> wrote:
I was looking for a way to block spammers from using higher procedence
level MX records.
Others choose to deploy dummy backup MXes that simply reject all mail,
on the
grounds that only the spammers will try connecting to those machines.
This is something I've done, thanks to some guidance from Markus Stumpf.
Since April 7, it has blocked 2,229 *connections* for only one of my
low-traffic domains.
I
personally think that's a little riskier, unless they're physically
hosted in
the same network and so suffer from identical connectivity.
I agree, and have done so.
Setting this up was trivial. Install qmail as guided by LWQ. Have your
tcp.smtp file look as such:
127.:allow,RELAYCLIENT=""
:allow,QMAILQUEUE="/var/qmail/bin/tmperrqueue"
Then create a /var/qmail/bin/tmperrqueue like:
#!/bin/sh
cat > /dev/null
exit 71
Make it executable, add your domains to rcpthosts and locals, set up
your MX records, and you're set!
PK
|
Very cool!
A great spam trap, but I need mail backup.
Unfortunately, the anti-spam appliance is highest priority, and the
secondary is the real mail server, so we need to actually get mail on
the secondary server while the primary sorts through the junk.
Maybe I could Have the tcp.smtp file allow the lower priority MX's, but
in the case of a failure, we want to accept all mail, so there is the
rub (back to the firewall daemon solution I suppose).
One could also have a daemon or cron job check for the higher priority
servers being up, and then automatically change the tcp.rules
accordingly: kind of clunky, but simple.
TTYL,
Blair. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 6:35 am | All times are GMT
|
|
MPAA | Discount Magazines | Loans | Loans | Free Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Apps
»
Qmail
