qmail Digest 14 Dec 1999 11:00:00 -0000 Issue 849
Topics (messages 34296 through 34330):
Re: qmail dying on Solaris
34296 by: Robin Bowes
deny access from users
34297 by: Mark Maggelet
34298 by: John P. Looney
34299 by: Denis Voitenko
34300 by: Petr Novotny
34302 by: Denis Voitenko
Re: Hotmail
34301 by: Aaron L. Meehan
34303 by: Tim Hunter
34306 by: Alex at Star
qmail+mysql
34304 by: Brandi Andrews
Limit Number of POP3 account access attempts
34305 by: Boris Atanassov
34307 by: Petr Novotny
Re: Looking for a server side method of blocking.
34308 by: Michael m. Honse
Re: Oops, someone tried to send you a virus
34309 by: Bruno Wolff III
34310 by: Bruno Wolff III
34311 by: Dustin Miller
34313 by: Bruno Wolff III
34315 by: Dustin Miller
34316 by: Bruno Wolff III
34318 by: farber.admin.f-tech.net
34322 by: Jason Haar
y2k
34312 by: Alvaro Escobar
34314 by: Daniel Mattos
34317 by: Kai MacTane
Mac conflict?
34319 by: Franklin A Hays
setting up virtuals and using vpopmail
34320 by: Cris Leonard
Re: Anti Virus Solution
34321 by: Ismal Hisham Darus
34323 by: Jason Haar
34324 by: Ismal Hisham Darus
34327 by: vicente.erlang.vircom.com.br
34328 by: Jason Haar
Stopping big messages until later
34325 by: David L. Nicol
34329 by: David L. Nicol
tcpserver and qpopper 2.53 configuration
34326 by: Dinesh Punjabi
34330 by: Vince Vielhaber
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Peter C. Norton <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> What's the $PATH set to for the user who built qmail? On solaris having
> /usr/ucb before /usr/ccs/bin is fatal to qmail (and most other software).
> What you're seeing is commonly caused by this mistake.
>
Peter,
As it happens, I built qmail using gnu tools so I don't have /usr/ccs/bin in
the path at all. Most stuff is in /usr/local/bin. The path for root is
currently:
/usr/local/bin:/sbin:/usr/local/sbin:/usr/sbin:/usr/bin:/usr/ucb:/var/qmail/
bin:/home/vpopmail/bin
Why does this cause qmail-smtpd (+ qmail-pop3d as well) to die regularly?
Do you think this could be the problem here? It *used* to run OK - it's
only recently that I've run into this problem.
R.
Hello there
I'm wondering if somebody can help me configure qmail or UW imap
so that mail can only be accessed from the localhost. I'm running a
web-based email package and I want the script to be able to access
the imap account, but I want to disallow people from using a regular
email client.
thanks for any tips,
- Mark
On Mon, Dec 13, 1999 at 08:27:26AM -0800, Mark Maggelet mentioned:
> Hello there
> I'm wondering if somebody can help me configure qmail or UW imap
> so that mail can only be accessed from the localhost. I'm running a
> web-based email package and I want the script to be able to access
> the imap account, but I want to disallow people from using a regular
> email client.
Check out "tcp wrappers". It's a simple application that allows you to
specify what IP addresses can connect to which ports of your machine. In
your case, you would allow only local connections to your IMAP port.
"man tcpd" should show if you have it installed locally.
John
--
Microsoft. The best reason in the world to drink beer.
http://www.redbrick.dcu.ie/~valen
PGP signature
Put the following in /etc/hosts.deny
all:all
and the following in /etc/hosts.allow
all: 127.0.0.1
and do killall -HUP inetd this will disallow any sort of connections to
services ran out of inetd to your machine other than from localhost. Since
Apache is ran outside of inetd (I hope you do that) it will be accessible.
Also, I suppose you run wu-imapd out of inetd, not tcpserver or
independently.
Denis Voitenko
Tel: 856 809-9252
Mail: [EMAIL PROTECTED]
ICQ: 9396092
----- Original Message -----
From: "Mark Maggelet" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 13, 1999 8:27 AM
Subject: deny access from users
> Hello there
> I'm wondering if somebody can help me configure qmail or UW imap
> so that mail can only be accessed from the localhost. I'm running a
> web-based email package and I want the script to be able to access
> the imap account, but I want to disallow people from using a regular
> email client.
>
> thanks for any tips,
> - Mark
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13 Dec 99, at 11:27, Denis Voitenko wrote:
> Put the following in /etc/hosts.deny
>
> all:all
>
> and the following in /etc/hosts.allow
>
> all: 127.0.0.1
>
> and do killall -HUP inetd this will disallow any sort of connections to
> services ran out of inetd to your machine other than from localhost. Since
> Apache is ran outside of inetd (I hope you do that) it will be accessible.
> Also, I suppose you run wu-imapd out of inetd, not tcpserver or
> independently.
And what about running qmail-smtpd from inetd? :-) And it might
not be too bright to disable ident lookups. Some admins are too
paranoid/smart-assed and simply disable the connection if they
don't get ident reply.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBOFUuolMwP8g7qbw/EQLASQCdG2ir68hx74UOnRsDdub57kx3P9MAn07X
h0PjmIQPFqhRl3AAhZUF0YCo
=TvN+
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
> And what about running qmail-smtpd from inetd? :-) And it might
Then you add smtp: all to /etc/hosts.allow and be happy :-) or run smtp from
tcpserver.
> not be too bright to disable ident lookups. Some admins are too
> paranoid/smart-assed and simply disable the connection if they
> don't get ident reply.
We're trying to solve the problem one step at a time, right? :-) Are you
sure you want to have those smart-assed admins connecting to your box? 90%
of machines on the net at open-relayed in some way or the other and nobody
seems to have a major problem with it.
Quoting Monte Mitzelfelt ([EMAIL PROTECTED]):
> On Fri, 10 Dec 1999, Aaron L. Meehan wrote:
> > I would think that if a 500 code were sent, then qmail would see it
> > and the email would be deferred. All queued messages are over 2Mb.
> > Looks like anything larger than that is causing hotmail to choke.
> > That's what it looks like, anyway.
>
> Only if it thought its turn was over (ie DATA ... . was finished) as far
> as I can tell from the code. They are timing me out and giving me 500
> messages when it is my turn to talk. I haven't check the RFC's yet to see
> if this turn notion is correct or not, but it's the working theory around
> the office right now.
OK got it. It's now Monday morning and I've got 15 messages with
attachments queued for hotmail, all dying in the middle somewhere.
This is quite the waste of our bandwidth, I do think.
I don't think that behavior is compliant myself, but not sure what to
do about it at this point.
Aaron
In my queue I have 9 messages with attachments for hotmail.com, I noticed
the problem about a week ago, it has probably been longer. Any ideas for
contacting hotmail and letting them know how upsetting this makes us Admins?
> -----Original Message-----
> From: Aaron L. Meehan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 13, 1999 12:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Hotmail
>
>
> Quoting Monte Mitzelfelt ([EMAIL PROTECTED]):
> > On Fri, 10 Dec 1999, Aaron L. Meehan wrote:
> > > I would think that if a 500 code were sent, then qmail would see it
> > > and the email would be deferred. All queued messages are over 2Mb.
> > > Looks like anything larger than that is causing hotmail to choke.
> > > That's what it looks like, anyway.
> >
> > Only if it thought its turn was over (ie DATA ... . was finished) as far
> > as I can tell from the code. They are timing me out and giving me 500
> > messages when it is my turn to talk. I haven't check the RFC's
> yet to see
> > if this turn notion is correct or not, but it's the working
> theory around
> > the office right now.
>
> OK got it. It's now Monday morning and I've got 15 messages with
> attachments queued for hotmail, all dying in the middle somewhere.
> This is quite the waste of our bandwidth, I do think.
>
> I don't think that behavior is compliant myself, but not sure what to
> do about it at this point.
>
> Aaron
>
>Any ideas for
>contacting hotmail and letting them know how upsetting this makes us Admins?
Well, we could point out that by doing this hotmail are actually hurting their
own bandwidth. For instance, suppose someone is trying to send them a 2M file.
If they sent a 5xx error code after the 2M has been sent, the total bandwidth
used is 2M. On the other hand, by consistently killing the connection after 1M,
qmail will retry 40 times over 7 days, for a total cost of 40M.
Alex
________________________________________________________________________________
This message has been checked for all known viruses by the Star Screening System
http://academy.star.co.uk/public/virustats.htm
I was wondering if anyone knew what the tag should be in the patch for
qmail and checkpassword to make getpwd and checkpassword to both use
mysql crypt as opposed to using the standard crypt. I am trying to pull
my users out of a db from mysql(obviously) and it always returns
host....not found ..... it is only checking /etc/passwd (for any users
in passwd all of qmails functions work beautifully...)
In fact would it be better to change how mysql crypts? (would this be
easier and more efficient in order to still read from /etc/passwd?)
signed,
Stuck
please use [EMAIL PROTECTED] or [EMAIL PROTECTED] for all replies.
Any and all help is appreciated
Hello everybody.
I browsed through the message archive, but couldn't find solution for
the following problem : how to limit the number of POP3 unsuccessful
account access attempts ?
I'm running a qmail-mysql linux 2.2.10 system which is not behind a
firewall so I would like to have something like that.
Sorry for asking, but before modifying the code of checkpasswd/qmail
I'd like to be sure that I'm not invetning the wheel :)
-- Bobby
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13 Dec 99, at 17:40, Boris Atanassov wrote:
> I browsed through the message archive, but couldn't find solution for
> the following problem : how to limit the number of POP3 unsuccessful
> account access attempts ? I'm running a qmail-mysql linux 2.2.10 system
> which is not behind a firewall so I would like to have something like
> that.
A really cool way to prevent brute-force dictionary attack is to
invoke "sleep 2s; /bin/checkpasswd" instead of /bin/checkpasswd.
It's only a little nuisance for the legitimate users, and effectively
disables brute force. (Of course you need to limit number of running
connections via tcpserver.)
:-)
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBOFU+V1MwP8g7qbw/EQJK7gCeJpWZVXAuNjhJs1l8n2ehXXWQYtcAoNxY
WihqZgwFeTpPk8W95cZEAm0D
=HCNh
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
-----Original Message-----
From: Michael m. Honse [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 13, 1999 10:03 AM
To: '[EMAIL PROTECTED]'
Subject: Looking for a server side method of blocking.
Looking for a server side method to Block Incoming and outgoing email
address single and/or domains.
On Fri, Dec 10, 1999 at 01:55:19PM -0500,
Russell Nelson <[EMAIL PROTECTED]> wrote:
> Matthew Brown writes:
> > Actually, in this case, it was a completely automated system. I don't
> > believe malice here.
>
> Yes, and it did the right thing in this case -- to send email to all
> likely receipients of the email, since they got a virus that might
> cause them a problem.
I disagree. The email should have just been sent to the local recipient
and the (envelope) sender and not all of the other recipients. Think about how
this would scale if the servers for each person on the list were using the
same system as the two that sent warnings to this list about the message.
On Fri, Dec 10, 1999 at 01:40:23PM -0600,
>
> Of course, if a new script is written, another approach might be to instruct
> the alert to not send mail to any address with the word "list" or "group" in
> it. That might help, but it also might allow a loophole for, let's say, the
> mail alias, "webmastergroup". Hmm..
>
> Any ideas?
A message might be sent to the envelope sender, indicating that the message
is being embargoed and that there may have been a virus in it.
A message should be sent to the envelope recipients (i.e. the local
recipients) telling them how to retrieve their messages and warning
them that the message might contain a virus.
The message headers should NOT be scanned for addresses to forward the
warning to.
The script I'm currenly working on (similar to another lister's system)
attempts to filter out list and group-type e-mail addresses. In the virus
alert the list received, the virus scanning program un a user's mail system
mistakenly assumed that the alert should've been sent to all intended
recipients of the message, in an attempt to notify all the possible
recipients that they had received a virus.
The best solution, of course, is to run the virus program on the list
server's mail server, thereby preventing a mass infection of those who don't
run virus software.
Yes, I know, everyone should run virus software, but let's be honest: Not
many do.
-----Original Message-----
From: Bruno Wolff III [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 13, 1999 3:54 PM
To: Russell Nelson
Cc: [EMAIL PROTECTED]
Subject: Re: Oops, someone tried to send you a virus
On Fri, Dec 10, 1999 at 01:55:19PM -0500,
Russell Nelson <[EMAIL PROTECTED]> wrote:
> Matthew Brown writes:
> > Actually, in this case, it was a completely automated system. I don't
> > believe malice here.
>
> Yes, and it did the right thing in this case -- to send email to all
> likely receipients of the email, since they got a virus that might
> cause them a problem.
I disagree. The email should have just been sent to the local recipient
and the (envelope) sender and not all of the other recipients. Think about
how
this would scale if the servers for each person on the list were using the
same system as the two that sent warnings to this list about the message.
On Mon, Dec 13, 1999 at 03:58:50PM -0600,
Dustin Miller <[EMAIL PROTECTED]> wrote:
> The script I'm currenly working on (similar to another lister's system)
> attempts to filter out list and group-type e-mail addresses. In the virus
> alert the list received, the virus scanning program un a user's mail system
> mistakenly assumed that the alert should've been sent to all intended
> recipients of the message, in an attempt to notify all the possible
> recipients that they had received a virus.
Don't do this. Just use the envelope addresses. If the other people are
worried about viruses, they will be running their own scanning software.
They don't need your extra warning.
>
> The best solution, of course, is to run the virus program on the list
> server's mail server, thereby preventing a mass infection of those who don't
> run virus software.
I disagree. This is a lot of overhead on the list server for little benefit.
People who don't know how to safely handle their email can run virus
scanners on their systems. The list server shouldn't have to waste cycles
doing this.
> Yes, I know, everyone should run virus software, but let's be honest: Not
> many do.
No, everyone shouldn't. People who don't know how to safely read email should,
if they don't want to get burnt. Many people don't need to worry about
the problem because we don't use Microsoft products to read email and don't
run attached programs that are sent to us by email.
Of course, server-based virus scanning isn't for people like you and I,
people who scan their e-mails regularly either on their own mail server or
on the client side, or people who automatically distrust attachments.
But you and I and other members of this list are the exception to the rule,
not the norm. As for using just the envelope addresses, I disagree
slightly. If mail leaving my server is bound for a number of recipients,
all of whom are listed on ONE "TO" or "CC" header, I'm going to alert all of
them that they may have received a virus. I will not, however, send a
message from my server to a LIST, should one of my users send a virus to the
LIST.
The more I think about it, though, the more I ask myself...
Does the receipient REALLY need to know that someone tried to send them an
infected file? If the sender gets a bounce message from MAILER-DAEMON that
says, "I wasn't able to deliver your message; It was infected with the [blah
blah] virus", wouldn't that be enough? What's the reasoning for informing
the intended recipient that he was going to receive a virus, but didn't?
Dustin
-----Original Message-----
From: Bruno Wolff III [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 13, 1999 4:09 PM
To: Dustin Miller
Cc: Russell Nelson; [EMAIL PROTECTED]
Subject: Re: Oops, someone tried to send you a virus
On Mon, Dec 13, 1999 at 03:58:50PM -0600,
Dustin Miller <[EMAIL PROTECTED]> wrote:
> The script I'm currenly working on (similar to another lister's system)
> attempts to filter out list and group-type e-mail addresses. In the virus
> alert the list received, the virus scanning program un a user's mail
system
> mistakenly assumed that the alert should've been sent to all intended
> recipients of the message, in an attempt to notify all the possible
> recipients that they had received a virus.
Don't do this. Just use the envelope addresses. If the other people are
worried about viruses, they will be running their own scanning software.
They don't need your extra warning.
>
> The best solution, of course, is to run the virus program on the list
> server's mail server, thereby preventing a mass infection of those who
don't
> run virus software.
I disagree. This is a lot of overhead on the list server for little benefit.
People who don't know how to safely handle their email can run virus
scanners on their systems. The list server shouldn't have to waste cycles
doing this.
> Yes, I know, everyone should run virus software, but let's be honest: Not
> many do.
No, everyone shouldn't. People who don't know how to safely read email
should,
if they don't want to get burnt. Many people don't need to worry about
the problem because we don't use Microsoft products to read email and don't
run attached programs that are sent to us by email.
On Mon, Dec 13, 1999 at 04:14:29PM -0600,
Dustin Miller <[EMAIL PROTECTED]> wrote:
> Of course, server-based virus scanning isn't for people like you and I,
> people who scan their e-mails regularly either on their own mail server or
> on the client side, or people who automatically distrust attachments.
(On this list most people are probably safe from viruses.)
>
> But you and I and other members of this list are the exception to the rule,
> not the norm. As for using just the envelope addresses, I disagree
> slightly. If mail leaving my server is bound for a number of recipients,
> all of whom are listed on ONE "TO" or "CC" header, I'm going to alert all of
> them that they may have received a virus. I will not, however, send a
> message from my server to a LIST, should one of my users send a virus to the
> LIST.
How do you know which addresses are lists?
> The more I think about it, though, the more I ask myself...
>
> Does the receipient REALLY need to know that someone tried to send them an
> infected file? If the sender gets a bounce message from MAILER-DAEMON that
> says, "I wasn't able to deliver your message; It was infected with the [blah
> blah] virus", wouldn't that be enough? What's the reasoning for informing
> the intended recipient that he was going to receive a virus, but didn't?
If you bounce the message you need to let the envelope sender know. If you
delay the message by embargoing it, then you might want to let the envelope
sender know.
The recipient should have a way to retrieve a message sent to them, even if
your scanner says their may be a virus in it. The result could be a false
positive. Virus scanners just do pattern matching looking for a portion of
a virus. They will occasionally flag messages that don't contain viruses.
The recipient might actually want to get the message in spite of the virus.
There may be nonvirus information that they want to see, or they may have
wanted a copy of the virus.
Yeah but now a days you don't need to even open the attachment.... Windows
based MUA's are liked into the OS so deep that macro viruses just need to
be sent down and you're screwed.
Paul Farber
Farber Technology
[EMAIL PROTECTED]
Ph 570-628-5303
Fax 570-628-5545
On Mon, 13 Dec 1999, Dustin Miller wrote:
> Of course, server-based virus scanning isn't for people like you and I,
> people who scan their e-mails regularly either on their own mail server or
> on the client side, or people who automatically distrust attachments.
>
> But you and I and other members of this list are the exception to the rule,
> not the norm. As for using just the envelope addresses, I disagree
> slightly. If mail leaving my server is bound for a number of recipients,
> all of whom are listed on ONE "TO" or "CC" header, I'm going to alert all of
> them that they may have received a virus. I will not, however, send a
> message from my server to a LIST, should one of my users send a virus to the
> LIST.
>
> The more I think about it, though, the more I ask myself...
>
> Does the receipient REALLY need to know that someone tried to send them an
> infected file? If the sender gets a bounce message from MAILER-DAEMON that
> says, "I wasn't able to deliver your message; It was infected with the [blah
> blah] virus", wouldn't that be enough? What's the reasoning for informing
> the intended recipient that he was going to receive a virus, but didn't?
>
> Dustin
>
> -----Original Message-----
> From: Bruno Wolff III [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 13, 1999 4:09 PM
> To: Dustin Miller
> Cc: Russell Nelson; [EMAIL PROTECTED]
> Subject: Re: Oops, someone tried to send you a virus
>
>
> On Mon, Dec 13, 1999 at 03:58:50PM -0600,
> Dustin Miller <[EMAIL PROTECTED]> wrote:
> > The script I'm currenly working on (similar to another lister's system)
> > attempts to filter out list and group-type e-mail addresses. In the virus
> > alert the list received, the virus scanning program un a user's mail
> system
> > mistakenly assumed that the alert should've been sent to all intended
> > recipients of the message, in an attempt to notify all the possible
> > recipients that they had received a virus.
>
> Don't do this. Just use the envelope addresses. If the other people are
> worried about viruses, they will be running their own scanning software.
> They don't need your extra warning.
>
> >
> > The best solution, of course, is to run the virus program on the list
> > server's mail server, thereby preventing a mass infection of those who
> don't
> > run virus software.
>
> I disagree. This is a lot of overhead on the list server for little benefit.
> People who don't know how to safely handle their email can run virus
> scanners on their systems. The list server shouldn't have to waste cycles
> doing this.
>
> > Yes, I know, everyone should run virus software, but let's be honest: Not
> > many do.
>
> No, everyone shouldn't. People who don't know how to safely read email
> should,
> if they don't want to get burnt. Many people don't need to worry about
> the problem because we don't use Microsoft products to read email and don't
> run attached programs that are sent to us by email.
>
>
On Mon, Dec 13, 1999 at 04:14:29PM -0600, Dustin Miller wrote:
> The more I think about it, though, the more I ask myself...
>
> Does the receipient REALLY need to know that someone tried to send them an
> infected file? If the sender gets a bounce message from MAILER-DAEMON that
I think you're spot-on. As far as I'm concerned, I think it would be totally
appropriate to DELETE ON RECEIVAL any mail message containing a virus. All
this dicking around with cleaning doesn't stop the fact the the senders
system is compromised and they need to be fixed before anything can be
trusted from them. I wouldn't go that far - but I certainly think it's an
appropriate option :-)
The GPL'ed virus scanner for qmail I'm working on
(http://www.geocities.com/jhaar/) does send reports to a central
"virus-reports" address as well as the envelope sender - and it does remove
mailing-list/postmaster addresses first...
As you said, the primary objective of a sites virus scanner is to stop
viruses entering or leaving the site - not to baby-sit other site's users...
- cold, but true ;-)
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
|
Is qmail full y2k compliance ?
|
Knowing Dan Bernstein coding preferences, you would never worry about
that.
On Mon, 13 Dec 1999, Alvaro Escobar wrote:
:Is qmail full y2k compliance ?
:
----------------------------------
Daniel Mattos Tribeca Internet Initiatives Inc.
[EMAIL PROTECTED] http://www.tiii.com
-----------------
At 05:18 PM 12/13/99 -0500, you wrote:
>
>Knowing Dan Bernstein coding preferences, you would never worry about
>that.
>
>On Mon, 13 Dec 1999, Alvaro Escobar wrote:
>
>:Is qmail full y2k compliance ?
However, if you want or need an actual statement on the subject, look at
www.qmail.org. At the end of the first paragraph is a statement that qmail
is Y2K-compliant, with a link to a (slightly) expanded explanation.
This may be comforting to show to PHBs. However, Russ, if that statement is
intended for PHBs, you might want to consider tarting it up a bit, just to
comfort them a bit more. (Not that we personally care if a PHB is
comfortable, but one who feels comfortable about qmail is more likely to OK
its use in his or her organization, which is good for qmail.)
(PHB = Pointy-Haired Boss, a reference to _Dilbert_. A pointy-haired boss
is one with little brain but much power in the company's pecking order, and
who actually makes decisions about the software to be used based on
statements from the software company's marketing divisions.)
-----------------------------------------------------------------
Kai MacTane
System Administrator
Online Partners.com, Inc.
-----------------------------------------------------------------
>From the Jargon File: (v4.0.0, 25 Jul 1996)
hired gun /n./
A contract programmer, as opposed to a full-time staff member. All
the connotations of this term suggested by innumerable spaghetti
Westerns are intentional.
I am running qmail on a Slack(3.6)-Linux 2.2.7 dual pentium machine.
Recently a local administrator upgraded his Macintosh server to the
following:
Mac PPC 7200
Sys 8.1
Open Transport 1.3
TCP/IP 1.3
Eudora Internet Mail Server (EIMS) 2.2
After this upgrade email sent from his server to any alias on my server
would bounce with the following message (this is the message people would
receive on HIS server):
"After one day the following message could not be delivered to
[EMAIL PROTECTED] at host my.alias.edu. The last attempt to send this
message failed because no answer was returned by a DNS."
Sorry, I don't have header information to send along, though I noted the
following:
1) problem only started to occur after his upgrade
2) problem does NOT occur with any other server sending mail to aliases on
my linux box
3) DNS configurations and MX records are correct and have NOT been changed
within the past three weeks (problem started just over a week ago).
4) messages take almost a day to bounce back to his server (the Mac).
5) No error messages or even proof of existence is found on my linux box
for the bounced email messages, they simply are not getting through the
server to my end.
We were able to get a workaround going in which he rerouted mail to
my aliases to another smtp server. My questions are as follows:
1) Are there any known conflicts with qmail and the above Mac system? (I
realise qmail may get along nice with the Mac and no vice versa, my
counterpart in posting the same questions to a Mac MTA discussion list)
2) Potential solutions, or other potential sources that I should look at.
I am new to troubleshooting MTA problems on this system so if information
above needs more depth or doesn't make sense let me know and I can
clarify, any and all help is greatly appreciated!!
Thanks in advance,
Frank
-------------------------------------------------------------------------------
frank(at)osucau.okstate.edu
http://osucau.okstate.edu/~frank
"The best thing about graduating from the university was that I finally
had time to sit on a log and read a good book."
--Edward Abbey
-------------------------------------------------------------------------------
I know it must be that I am missing something but I have tried to find the error with
no resolve.
for example if I setup a virtual domain with the following for a DNS record
(the domain names below are bogus I am using real ones in the actual server)
@ IN SOA test.com. root.test.com. (
199922700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS NS1.nameserver.COM.
IN NS NS2.nameserver.COM.
IN MX 10 mail.test.com.
@ IN A 209.53.177.3
mail IN A 209.53.177.5
I add the domain using vpopmails scripts as follows
\home\vpopmail\bin\vadddomain test.com password
\home\vpopmail\bin\vadduser [EMAIL PROTECTED] password
when sending mail to [EMAIL PROTECTED] I get the following error
**<[EMAIL PROTECTED]>:
**Sorry. Although I'm listed as a best-preference MX or A for that host,
it **isn't in my control/locals file, so I don't treat it as local.
(#5.4.6)
now if I add the virtual domain mail.test.com using the scripts like the following
\home\vpopmail\bin\vadddomain mail.test.com password
\home\vpopmail\bin\vadduser [EMAIL PROTECTED] password
I can send mail to [EMAIL PROTECTED] and see it appear in
/home/vpopmail/domains/mail.test.com/frank/Maildir/new
I still can not send mail to [EMAIL PROTECTED]
any Ideas, Thanks in advance
Cris Leonard,
[EMAIL PROTECTED]
http://www.netcents.com
> It's fast, perl-based and specifically written for qmail.
>
> See http://www.geocities.com/jhaar/scan4virus/ for details...
>
>
>
> --
> Cheers
>
> Jason Haar
>
> Unix/Network Specialist, Trimble NZ
> Phone: +64 3 3391 377 Fax: +64 3 3391 417
how to get the Perl module Time::HiRes (if debugging enabled) ? *blushed*
> how to get the Perl module Time::HiRes (if debugging enabled) ? *blushed*
>
Well, I install all perl modules via
perl -e 'use CPAN; install /Time::HiRes/'
...but that depends a lot on firewalls/etc.
You can just go to CPAN and get it:
http://search.cpan.org/search?module=Time::HiRes
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
thanks a lot jason .. it works. !!!!
----- Original Message -----
From: "Jason Haar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 14, 1999 9:24 AM
Subject: Re: Anti Virus Solution
> > how to get the Perl module Time::HiRes (if debugging enabled) ?
*blushed*
> >
>
> Well, I install all perl modules via
>
> perl -e 'use CPAN; install /Time::HiRes/'
>
> ...but that depends a lot on firewalls/etc.
>
> You can just go to CPAN and get it:
>
> http://search.cpan.org/search?module=Time::HiRes
>
>
> --
> Cheers
>
> Jason Haar
>
> Unix/Network Specialist, Trimble NZ
> Phone: +64 3 3391 377 Fax: +64 3 3391 417
>
> > It's fast, perl-based and specifically written for qmail.
> >
> > See http://www.geocities.com/jhaar/scan4virus/ for details...
> >
I could not get it... Am I wrong?
Do you have another address?
-- Vicente Andrade
VIRCOM Internet Solutions
http://www.vircom.com.br
http://www.10reais.com.br
On Mon, Dec 13, 1999 at 11:50:54PM -0300, [EMAIL PROTECTED] wrote:
>
> > > It's fast, perl-based and specifically written for qmail.
> > >
> > > See http://www.geocities.com/jhaar/scan4virus/ for details...
> > >
>
> I could not get it... Am I wrong?
> Do you have another address?
Sheezh - my fault - but Geocities is running the flakiest FTP server I've
seen in a looong time.
All fixed - the appropriate index.html file is now in place :-)
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
Thinking about this situation over the weekend I concluded that
the sanest thing to do would be to hack qmail-remote so it
checks file-size and marks temporary failures for oversize mails during
peak times. This could be done by reading a file size from an external
file, and having the file size modified by something run from cron; or
the policy could be written into the patch (which would make the patch
too site-specific to share.)
Looking at the the qmail-remote.c program, I suppose the patch would
first define an error handler like all the other error handlers :
void temp_policy_size() { out("Z\
Message is too large to send during peak time. (#4.3.0)\n"); zerodie();
}
Then, find a place where we can stat the message text.... No, we can't
at all because qmail-remote reads stdin -- although we could read stdin
until we have enough, and issue the error the same place djb issues the
"out of memory" temporary system error --
no, we appear to be reading stdin and passing it to remote in
little pieces? The sending is done within the smtp() call -- in which
we learn that a new temp_* message is a breakable convention, as the
c<quit("Z......")> will work too -- or is that just within the smtp
session?
Anyway, the message gets sent within blast(), which reads from &ssin,
doubles line-starting dots, and writes to &smtpto, one character at a
time.
So.
In order to implement a size-driven policy completely within
qmail-remote,
you could allocate a buffer large enough to hold an entire
size-compliant message and load it from stdin, before looking up hosts
and dns and so forth. If you get to the end of my buffer and we are
doing
size-rationing, I would temp_policy_size() and that's that.
Later, when the smtp session is under way, blast() would read and send
the
buffer, before reading stdin, if there is any stdin left to read,
because
we're not in peak hours.
Alternately, you could have two qmail-remote programs, the original one
and
one that reads into a limited buffer, and then refers to it within
blast()
instead of reading &ssin, and have your cron job switch the link at
/var/qmail/bin/qmail-remote between /var/qmail/bin/qmail-remote_original
and /var/qmail/bin/qmail-remote_size-policy at the transition times,
something
like
0 8 * * * ln -f /var/qmail/bin/qmail-remote_size-policy
/var/qmail/bin/qmail-remote
0 20 * * * ln -f /var/qmail/bin/qmail-remote_original
/var/qmail/bin/qmail-remote
Since qmail-rspawn finds the program to run by having execvp consult the
file
system, this will work. To be supersuper safe you could add a wait and
retry
once before exiting with error condition somewhere near the execvp in
qmail-rspawn.
That way you don't have to mess with new control files any.
There are some rough edges in there; when I write my qmail-inspired MTA
I think I'll have the qmail-remote analogue take a file name as an
argument
and be responsible for setting the delivered flags itself instead of
simply reporting delivery status; this will of course make my system
vulnerable to stack-smashing attacks from remote SMTP servers, which
would
then have sufficient privilege to do some damage, should the OS I will
be
using be vulnerable to such things.
Ari Arantes Filho wrote:
> David,
>
> You are totally right:
>
> > What ari appears to me to be asking for is a way to derail large e-mails
> > into a secondary queue: He wants email to flow 24/z for little memos,
> > but attachments above a threshold must wait until off-peak.
>
> I'm using the qmail-hold patch, so I can create a control/holdremote (with
> 1), send HUP the qmail-send and the queue is paused. But at this time, all
> messages will be stopped. I would like to stop only the big one.
[EMAIL PROTECTED] wrote, but did not CC everyone:
>
> On Tue, 14 Dec 1999 01:57:59 +0000 , "David L. Nicol" writes:
> > Looking at the the qmail-remote.c program, I suppose the patch would
> > first define an error handler like all the other error handlers :
> >
> > void temp_policy_size() { out("Z\
> > Message is too large to send during peak time. (#4.3.0)\n"); zerodie();
> > }
> >
> > Then, find a place where we can stat the message text.... No, we can't
> > at all because qmail-remote reads stdin -- although we could read stdin
> > until we have enough, and issue the error the same place djb issues the
> > "out of memory" temporary system error --
>
> Actually, you could just use fstat() on stdin. That
> would give you the file size, since qmail-remote's
> stdin should be a regular file.
>
> I like the idea of modifying external state from a
> cron job -- that makes it much more flexible.
>
> The one gotcha is that qmail-send's back-off might
> skip the "big message window," so you should probably
> ALRM qmail-send when you switch policy.
>
> --
> Chris Mikkelson | Setting delivery schedules is easy enough using the
> [EMAIL PROTECTED] | I Ching, astrology, psychic hotlines, or any of the
> | well-known scatomantic and necromantic methodologies.
> | Meeting your prophetic deadlines, though, is another
> | bowl of entrails. -- Stan Kelly-Bootle
Is there any documentation or a sample/example
on how to setup a pop client with tcpserver.
I am specifically looking for eudora qpopper
example.
Any information relating to tcpserver
documentation, web sites, etc. (other than
www.qmail.org) will be appreciated. I am
having a hard time following the man pages
(its me!).
I would also like to setup a way to disallow
certain IPs, hosts, from accessing the pop,
smtp server, etc. Thanks in advance!
Dinesh
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
On Mon, 13 Dec 1999, Dinesh Punjabi wrote:
> Is there any documentation or a sample/example
> on how to setup a pop client with tcpserver.
> I am specifically looking for eudora qpopper
> example.
/usr/local/bin/tcpserver 0 110 /usr/local/bin/popper &
Handle any logging you have enabled in qpopper appropriately. If you
want to allow/disallow then use the -x parameter in tcpserver just like
you would when setting up qmail-smtpd.
tcpserver can be used for just about anything you can think of that might
otherwise be run from inetd. I'm even using it on a private network for
nightly backups. On FreeBSD I have it running telnetd, and since I run
a standalone ftpd I've been able to shut off inetd altogether. One word
of caution tho, I had absolutely NO luck running telnetd on hpux, it was
a good thing the console was close by.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
