qmail Digest 28 Sep 1999 10:00:01 -0000 Issue 773
Topics (messages 30892 through 30962):
Re: Sendmail ---> Qmail
30892 by: Claus Färber
30903 by: Russell Nelson
qmHandle: small error
30893 by: Franky Van Liedekerke
relaying question
30894 by: Edward Castillo-Jakosalem
30896 by: Anand Buddhdev
30897 by: Timothy L. Mayo
30898 by: Edward Castillo-Jakosalem
30899 by: Timothy L. Mayo
30901 by: Edward Castillo-Jakosalem
30902 by: Edward Castillo-Jakosalem
30905 by: Anand Buddhdev
30907 by: Edward Castillo-Jakosalem
Re: How can I send a vacation notice ?
30895 by: Anand Buddhdev
Re: qmail rc script won't run
30900 by: Dave Sill
Re: EZMLM and Return-Header
30904 by: Dave Sill
IMAP advice
30906 by: Mullen, Patrick
Re: "info" mailing list/responder with attachments?
30908 by: Dave Sill
Re: Grave Difficulties (lspawn, Maildir, etc)
30909 by: Dave Sill
30912 by: Dave Sill
Calling all qmail / mailman admins ...
30910 by: Joe D'Andrea
mini-announce: rblefftest -- simple RBL false-positive test
30911 by: David Harris
30914 by: Vince Vielhaber
30919 by: David Harris
Re: Sqwebmail and IMAP
30913 by: Chris Garrigues
30917 by: Fred Lindberg
30918 by: Chris Garrigues
30920 by: Fred Lindberg
30927 by: Russell Nelson
30943 by: Sam
30957 by: Jukka Zitting
QMail as open relay
30915 by: Bryan Ischo
30935 by: Bryan Ischo
30952 by: Robin Bowes
Re: Compile imap-4.5.vchkpw.new.tar.gz Problem for vpopmail-3.4.9 Problem on redhat
v6.0
30916 by: Eric Peters
Re: Strange open relay problem with qmail due to bad configuration.
30921 by: Chuck Milam
30928 by: Aaron L. Meehan
tcp log
30922 by: Tom Fishwick
30925 by: Dave Sill
Mass virtual hosting
30923 by: Mojahedul Hoque Abul Hasanat
30924 by: B. Engineer
30926 by: Patrick Berry
Re: please, some help to block spam
30929 by: farber.admin.f-tech.net
30932 by: Abel Lucano
30940 by: Asmodeus
30945 by: farber.admin.f-tech.net
Re: When will qmail back off to the next MX?
30930 by: Racer X
30931 by: phil.ipal.net
30933 by: David Dyer-Bennet
30934 by: David Dyer-Bennet
30936 by: Russell Nelson
30939 by: David Dyer-Bennet
30941 by: Russell Nelson
30944 by: Strange
30946 by: phil.ipal.net
30949 by: phil.ipal.net
number of qmail-remote processes
30937 by: Van Liedekerke Franky
qmail-pop newbie security
30938 by: Joshi, Vivek
30942 by: Patrick Berry
pop3d - Unable to scan $HOME/Maildir??
30947 by: Bill Rogers
30950 by: Patrick Berry
TCPServer looping
30948 by: farber.admin.f-tech.net
30953 by: Chris Johnson
30955 by: farber.admin.f-tech.net
30960 by: Jedi/Sector One
Bouncing all rcvd msgs with no explanation
30951 by: Joel Griffiths
30954 by: Russell Nelson
tcpserver won't allow incomming connections OR relay for clients
30956 by: Ryan Sharon
One user can't get her mail
30958 by: Barry Dwyer
30961 by: Andre Anneck
qmail-smtpd and recordio fails
30959 by: Thomas Foerster
Qmail and Maildir
30962 by: Jorge Mota
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Tony Wade <[EMAIL PROTECTED]> schrieb/wrote:
> This is what it looks like on sendmail
>
> owner-bugtraq-list: postmaster
> bugtraq-list-request: postmaster
> bugtraq-list: "|/usr/lib/sendmail -oi -fbugtraq-list-request
> bugtraq-list-outgoing"
> bugtraq-list-outgoing: "subscribers mail addresses."
>
> I need to know how to format the following line "|/usr/lib/sendmail -oi
> -fbugtraq-list-request bugtraq-list-outgoing"
You don't. You just need:
.qmail-bugtraq-list-owner:
&[EMAIL PROTECTED]
.qmail-bugtraq-list-request:
&[EMAIL PROTECTED]
.qmail-bugtraq-list:
&address1
&address2
&address3
#...
I think that is also mentioned in the FAQ.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
Tony Wade writes:
> Hi all,
>
> I am moving our Sendmail server to Qmail and am wondering how i would redo
> the following mail-exploders.
Move 'em to ezmlm. Handling bounces by hand is 80's technology. I
can't describe in words just how passe' it's become.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
There seems to be a small error in the qmHandle 4.0 program, causing
messages in subdir's 0 not to be seen. The error seems to be in the
checking of the local and remote queue at the beginning of the program
Below I added a small solution (pure perl) for the program for those who
use it.
A copy of this has been sent to the author of the program as well.
Franky
# Make list of messages in remote queue
opendir(DIR,"${queue}remote");
@dirlist = grep !/\./, readdir DIR;
closedir DIR;
foreach $dir (@dirlist) {
opendir (SUBDIR,"${queue}remote/$dir");
@files = grep !/\./, map "$dir/$_", readdir SUBDIR;
foreach $file (@files) {
push @msglist, "$file";
$type{"$file"} = 'R';
}
closedir SUBDIR;
}
# Make list of messages in local queue
opendir(DIR,"${queue}local");
@dirlist = grep !/\./, readdir DIR;
closedir DIR;
foreach $dir (@dirlist) {
opendir (SUBDIR,"${queue}local/$dir");
@files = grep !/\./, map "$dir/$_", readdir SUBDIR;
foreach $file (@files) {
push @msglist, "$file";
$type{"$file"} = 'L';
}
closedir SUBDIR;
}
Hi to all!
I recently configured our smtp to point to another machine running
qmail-1.03. No problem with that. Now, what I see in our log file is
that it says 'deny' to all the hosts except the 2 ip blocks I configured
to be relayclients. I just need some help if what I did in my tcp.smtp
file is correct.
xxx.xxx.xxx.:allow,RELAYCLIENT=""
yyy.yyy.yyy.:allow,RELAYCLIENT=""
:deny
Does this config mean that it will allow relaying from xxx and yyy
domains and deny from anywhere else? What about other hosts sending mail
to one of our handled domains? Is this the deny that I see in our log
files?
I hope I sent the complete details.
Thanks very much in advance for any help!
Edward Castillo-Jakosalem
On Mon, Sep 27, 1999 at 06:48:52PM +0800, Edward Castillo-Jakosalem wrote:
> Hi to all!
> I recently configured our smtp to point to another machine running
> qmail-1.03. No problem with that. Now, what I see in our log file is
> that it says 'deny' to all the hosts except the 2 ip blocks I configured
> to be relayclients. I just need some help if what I did in my tcp.smtp
> file is correct.
>
> xxx.xxx.xxx.:allow,RELAYCLIENT=""
This means allow connections from xxx.xxx.xxx AND let them relay to any
destination.
> yyy.yyy.yyy.:allow,RELAYCLIENT=""
Same as above for yyy.yyy.yyy
> :deny
This means don't let ANY OTHER host connect. What you want as your last
rule is ":allow". That will allow connections from all other hosts, but
will not let them relay.
--
See complete headers for more info
Remove your last line. It is what is causing your problem.
You want to allow but without setting the RELAYCLIENT environment variable
which is the default behavior.
On Mon, 27 Sep 1999, Edward Castillo-Jakosalem wrote:
>
> Hi to all!
> I recently configured our smtp to point to another machine running
> qmail-1.03. No problem with that. Now, what I see in our log file is
> that it says 'deny' to all the hosts except the 2 ip blocks I configured
> to be relayclients. I just need some help if what I did in my tcp.smtp
> file is correct.
>
> xxx.xxx.xxx.:allow,RELAYCLIENT=""
> yyy.yyy.yyy.:allow,RELAYCLIENT=""
> :deny
>
> Does this config mean that it will allow relaying from xxx and yyy
> domains and deny from anywhere else? What about other hosts sending mail
> to one of our handled domains? Is this the deny that I see in our log
> files?
>
> I hope I sent the complete details.
> Thanks very much in advance for any help!
>
>
> Edward Castillo-Jakosalem
>
>
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
>
> > :deny
>
> This means don't let ANY OTHER host connect. What you want as your last
> rule is ":allow". That will allow connections from all other hosts, but
> will not let them relay.
>
Yes but I already tried setting that to 'allow' and tested sending mail using
another ISP and it allowed relay. What am I still missing here?
Thanks again Anand!
--
Edward Castillo-Jakosalem
Did you remove your /var/qmail/control/rcpthosts file? This MUST be in
place!
On Mon, 27 Sep 1999, Edward Castillo-Jakosalem wrote:
> >
>
> > > :deny
> >
> > This means don't let ANY OTHER host connect. What you want as your last
> > rule is ":allow". That will allow connections from all other hosts, but
> > will not let them relay.
> >
>
> Yes but I already tried setting that to 'allow' and tested sending mail using
> another ISP and it allowed relay. What am I still missing here?
>
> Thanks again Anand!
>
> --
>
> Edward Castillo-Jakosalem
>
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
Yup. It's still there.
"Timothy L. Mayo" wrote:
> Did you remove your /var/qmail/control/rcpthosts file? This MUST be in
> place!
>
> On Mon, 27 Sep 1999, Edward Castillo-Jakosalem wrote:
>
> > >
> >
> > > > :deny
> > >
> > > This means don't let ANY OTHER host connect. What you want as your last
> > > rule is ":allow". That will allow connections from all other hosts, but
> > > will not let them relay.
> > >
> >
> > Yes but I already tried setting that to 'allow' and tested sending mail using
> > another ISP and it allowed relay. What am I still missing here?
> >
> > Thanks again Anand!
> >
> > --
> >
> > Edward Castillo-Jakosalem
> >
> >
> >
>
> ---------------------------------
> Timothy L. Mayo mailto:[EMAIL PROTECTED]
> Senior Systems Administrator
> localconnect(sm)
> http://www.localconnect.net/
>
> The National Business Network Inc. http://www.nb.net/
> One Monroeville Center, Suite 850
> Monroeville, PA 15146
> (412) 810-8888 Phone
> (412) 810-8886 Fax
--
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
Edward Castillo-Jakosalem
Systems Administrator
Access Net (Phils.), Inc.
http://www.access.net.ph/ecj
[EMAIL PROTECTED]
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
So now I removed that deny line in my tcp.smtp file, issued the tcprule
command, and restarted my tcpserver. Does it mean that hosts can now connect
to my server without using it as a relay?
Oh and do we still need the rcpthosts file eventhough we are running
tcpserver?
Sorry but am quite a newbie to qmail!
Thanks Timothy!
"Timothy L. Mayo" wrote:
> Remove your last line. It is what is causing your problem.
>
> You want to allow but without setting the RELAYCLIENT environment variable
> which is the default behavior.
>
> On Mon, 27 Sep 1999, Edward Castillo-Jakosalem wrote:
>
> >
> > Hi to all!
> > I recently configured our smtp to point to another machine running
> > qmail-1.03. No problem with that. Now, what I see in our log file is
> > that it says 'deny' to all the hosts except the 2 ip blocks I configured
> > to be relayclients. I just need some help if what I did in my tcp.smtp
> > file is correct.
> >
> > xxx.xxx.xxx.:allow,RELAYCLIENT=""
> > yyy.yyy.yyy.:allow,RELAYCLIENT=""
> > :deny
> >
> > Does this config mean that it will allow relaying from xxx and yyy
> > domains and deny from anywhere else? What about other hosts sending mail
> > to one of our handled domains? Is this the deny that I see in our log
> > files?
> >
> > I hope I sent the complete details.
> > Thanks very much in advance for any help!
> >
> >
> > Edward Castillo-Jakosalem
> >
> >
> >
> >
>
> ---------------------------------
> Timothy L. Mayo mailto:[EMAIL PROTECTED]
> Senior Systems Administrator
> localconnect(sm)
> http://www.localconnect.net/
>
> The National Business Network Inc. http://www.nb.net/
> One Monroeville Center, Suite 850
> Monroeville, PA 15146
> (412) 810-8888 Phone
> (412) 810-8886 Fax
--
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
Edward Castillo-Jakosalem
Systems Administrator
Access Net (Phils.), Inc.
http://www.access.net.ph/ecj
[EMAIL PROTECTED]
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
On Mon, Sep 27, 1999 at 09:32:07PM +0800, Edward Castillo-Jakosalem wrote:
> So now I removed that deny line in my tcp.smtp file, issued the tcprule
> command, and restarted my tcpserver. Does it mean that hosts can now connect
> to my server without using it as a relay?
Yes. Incidentally, you don't need to restart tcpserver. The rules
database is read afresh for every incoming connection.
> Oh and do we still need the rcpthosts file eventhough we are running
> tcpserver?
the rcpthosts file is still needed. This is so that non-relay clients
can only send mail to domains that you want to receive mail for.
--
See complete headers for more info
Thanks a lot Anand. You've been a great help!
Anand Buddhdev wrote:
> On Mon, Sep 27, 1999 at 09:32:07PM +0800, Edward Castillo-Jakosalem wrote:
>
> > So now I removed that deny line in my tcp.smtp file, issued the tcprule
> > command, and restarted my tcpserver. Does it mean that hosts can now connect
> > to my server without using it as a relay?
>
> Yes. Incidentally, you don't need to restart tcpserver. The rules
> database is read afresh for every incoming connection.
>
> > Oh and do we still need the rcpthosts file eventhough we are running
> > tcpserver?
>
> the rcpthosts file is still needed. This is so that non-relay clients
> can only send mail to domains that you want to receive mail for.
>
> --
> See complete headers for more info
--
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
Edward Castillo-Jakosalem
Systems Administrator
Access Net (Phils.), Inc.
http://www.access.net.ph/ecj
[EMAIL PROTECTED]
0o0o0o0o0o0o0o0o0o0o0o0o0o0o0o0
On Sat, Sep 25, 1999 at 04:23:47PM +0800, Emmanuel Nee wrote:
> Hi,
>
> I wish to send a vacation message to the sender but retaining the orginal
> message in my mailbox. Please teach me..
In your .qmail:
|/usr/bin/vacation [EMAIL PROTECTED]
./Mailbox
--
See complete headers for more info
Barry Dwyer <[EMAIL PROTECTED]> wrote:
>When I boot the system, qmail attempts to load last but fails with an
>error message: "no such file or directory". Ditto if I issue the command
>"/usr/sbin/qmail start" - I get "bash: /usr/sbin/qmail: No such file or
>directory".
>
>Everything's where it should be. What's the problem?
See:
http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/09/msg00927.html
-Dave
Andreas Fiedler <[EMAIL PROTECTED]> wrote:
>I've set up a mailing list with EZMLM. Everything works fine but one thing:
>I don't have an entire domain to catch returning (bounced) mail so I need
>to rewrite the Return-Path. For example from
>
>[EMAIL PROTECTED]
>
>to
>
>[EMAIL PROTECTED]
>
>Is there any option I can use or do I have to rewrite the Return-Path
>manually?
You don't need "an entire domain" to catch ezmlm bounces. In fact,
everything you need should have been set up by ezmlm.
Why don't you take this to the ezmlm list?
-Dave
I'm sure it's just the combination of my knowing
very little about IMAP and the IMAP structure, but
I was hoping if some of you could give me some
pointers on running an IMAP server.
I want to run IMAP, but I want my connection (or
at least the uname/password) to be be secure /
encrypted. On that note, I'd also like my POP
daemon to at least encrypt the uname/passwd.
What IMAP daemon is recommended? I use the
Maildir format. I want an IMAP daemon which is
safe and segmented, the way qmail is. With the
number of IMAP remote exploits handing out
rootshells, I'd like something that will be more
resistant to such attacks.
This brings up a question of mine, though. I know
I could look at the source, but how does qmail-smtp
access home directories when it's run user qmaild,
group qmail when the directory permissions are 700?
Thanks for your help!
~Patrick
Ruben van der Leij <[EMAIL PROTECTED]> wrote:
>On Sat, Sep 25, 1999 at 07:11:21PM +0100, Paul A. Cheshire wrote:
>
>> Is this possible with qmail and/or ezmlm?
>[send files on demand]
>
>Nope. And neither should it be. The way to go is procmail or another MDA.
Procmail or maildrop will make such things easier, but qmail's MDA is
sufficiently powerful to implement an autoresponder. But even if it
wasn't, you could always pipe messages to a shell script that parses
them and responds accordingly.
-Dave
"jarrid jeeby" <[EMAIL PROTECTED]> wrote:
>/var/qmail/rc reads:
>exec env - PATH="/var/qmail/bin:$PATH" \
> qmail-start " cat /var/qmail/control/defaultdelivery " \
> accustamp
I see two problems. First, you should have:
`cat /var/qmail/control/defaultdelivery`
note that those are back quotes (`) not single quotes (') or double
quotes (").
Second, you're sending qmail-start's output to accustamp, but
accustamp just timestamps standard input and writes it to standard
output. You should redirect accustamp's output to a file or logging
program, e.g.:
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start " cat /var/qmail/control/defaultdelivery " \
accustamp > /var/log/qmail.log &
or
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start " cat /var/qmail/control/defaultdelivery " \
accustamp | splogger qmail &
>I can send mail out through SMTP but the only way I can allow relaying is to
>rm rcpthosts. Putting the /etc/tcp.smtp values into a cdb with many
>different IP's specifying ,RELAYCLIENT="" is not working. Applying the
>relayclient patch to use control/relay* is not working. I am wide open for
>relay abuse until this is corrected. I am aware of the number of people
>with relay problems but I feel I have triple checked all of the most common
>problems.
What is tcpserver logging? What does you tcp.smtp look like?
>Although I (and everyone else!) can successfully send mail out through SMTP,
>any mail received is not processed.
Fix you logging, and the logs will show where the problem is.
-Dave
I wrote:
>I see two problems. First, you should have:
>
> `cat /var/qmail/control/defaultdelivery`
>
>note that those are back quotes (`) not single quotes (') or double
>quotes (").
Acutally you want:
"`cat /var/qmail/control/defaultdelivery`"
in case defaultdelivery contains whitespace.
-Dave
[previously posted to the "mailman users" list]
Try as I might, I still don't have qmail and mailman playing nice
together. If anyone has pulled this stunt off, or is currently
trying to figure it out (like I am), could you please contact me?
I'd like to discuss in an offline e-mail thread all the nuances
(above and beyond what's in README.QMAIL) and then post what will
hopefully be the definitive "steps to configure" for qmail/mailman.
Not that I object to discussing it here (I don't) but if it will
help keep the signal/noise ratio down ... :-)
--
Joe D'Andrea
AT&T Laboratories
Remember about a week ago I started a test to see how many false-positives
three RBL filters gave. I looked at the filtering done by rbl.maps.vix.com,
relays.radparker.com, and dul.maps.vix.com over a seven day period and 5,000
message accepted through SMTP. Well, that test is done now, and I've posted the
data along with the program up on a web page.
http://www.davideous.com/rblefftest/
- David Harris
Principal Engineer, DRH Internet Services
On Mon, 27 Sep 1999, David Harris wrote:
>
> Remember about a week ago I started a test to see how many false-positives
> three RBL filters gave. I looked at the filtering done by rbl.maps.vix.com,
> relays.radparker.com, and dul.maps.vix.com over a seven day period and 5,000
> message accepted through SMTP. Well, that test is done now, and I've posted the
> data along with the program up on a web page.
Does filtered 8 typical messages mean they were legit messages that
were filtered as spam, or does it mean something else?
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
==========================================================================
Vince Vielhaber [mailto:[EMAIL PROTECTED]] wrote:
> Does filtered 8 typical messages mean they were legit messages that
> were filtered as spam, or does it mean something else?
Yes, those eight messages were not spam -- just standard e-mails which did not
come from though list-serv. They were part of the total 26 non-spam messages
which were filtered as spam by relays.radparker.com. I've adjusted the web page
text to make this more clear.
- David Harris
Principal Engineer, DRH Internet Services
> From: Russell Nelson <[EMAIL PROTECTED]>
> Date: Sun, 26 Sep 1999 01:12:09 -0400 (EDT)
>
> Randy Harmon writes:
> > Is the concept of subfolders stupid? IMHO: no. Given: millions of
> > Microsoft users are wrong. But not on this point.
>
> The concept of being able to store both mail AND folders in a
> folder is stupid.
Just as being able to store both plain files and directories in directories is
stupid?
I've got exmh/nmh setup such that every one of my folders contains both
messages and an 'old' sub-folder which has messages more than 2 months old. I
find this to be a useful way to move older stuff out of the way. Certainly I
could have qmail and qmail.old instead of qmail and qmail/old, but I don't see
that it's necessarily stupid to have half as many folders at the level above.
Chris
--
Chris Garrigues virCIO
http://www.DeepEddy.Com/~cwg/ http://www.virCIO.Com
+1 512 432 4046 +1 512 374 0500
4314 Avenue C
O- Austin, TX 78751-3709
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
PGP signature
On Mon, 27 Sep 1999 10:02:37 -0500, Chris Garrigues wrote:
>find this to be a useful way to move older stuff out of the way. Certainly I
>could have qmail and qmail.old instead of qmail and qmail/old, but I don't see
>that it's necessarily stupid to have half as many folders at the level above.
Without folders and messages in the same folder, folders for folders
would be normal nodes, folders for messages would be leaves. A
tremendous gain for file system searches. No wading through piles of
files [with stat()] to see if there is a directory.
[this is more a [off-topic] qmail than a sqwebmail discussion, IMHO, so
I won't X-post].
-Sincerely, Fred
Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA
> From: "Fred Lindberg" <[EMAIL PROTECTED]>
> Date: Mon, 27 Sep 1999 10:42:44 -0500
>
> Without folders and messages in the same folder, folders for folders
> would be normal nodes, folders for messages would be leaves. A
> tremendous gain for file system searches. No wading through piles of
> files [with stat()] to see if there is a directory.
Very valid point, but in designing an email system, which is more
important: implementation efficiency or user intuition and flexibility?
I think as time goes by this scale tips further and further to the latter over
the former.
Chris
--
Chris Garrigues virCIO
http://www.DeepEddy.Com/~cwg/ http://www.virCIO.Com
+1 512 432 4046 +1 512 374 0500
4314 Avenue C
O- Austin, TX 78751-3709
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
PGP signature
On Mon, 27 Sep 1999 10:58:19 -0500, Chris Garrigues wrote:
>Very valid point, but in designing an email system, which is more
>important: implementation efficiency or user intuition and flexibility?
I was, based on your post, following up on Russell's comment on file
system design.
IMHO, Sam's scheme makes most sense. The obvious way to a Maildir is
the .qmail file. With his scheme, there is no name collision and no
extra config/index file is necessary since all info is within the
Maildir pointed to by .qmail. The alternative would require a index or
an outer container that houses the base Maildir. The latter is not
consistent with the most common ~/Maildir/. As there is no standard,
Sam will create the de-facto standard with sqwebmail and his IMAPd
anyway.
-Sincerely, Fred
Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA
Chris Garrigues writes:
> > From: Russell Nelson <[EMAIL PROTECTED]>
> > Date: Sun, 26 Sep 1999 01:12:09 -0400 (EDT)
> >
> > Randy Harmon writes:
> > > Is the concept of subfolders stupid? IMHO: no. Given: millions of
> > > Microsoft users are wrong. But not on this point.
> >
> > The concept of being able to store both mail AND folders in a
> > folder is stupid.
>
> Just as being able to store both plain files and directories in directories is
> stupid?
I suppose not, but it does rule out the possibility of using a
hierarchy of Mailboxes, unless you do something crufty like name the
Mailbox "Mailbox.mbox" and the subdirectory "Mailbox". But then to be
consistent, you should name all the other Mailboxes *.mbox.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Fred Lindberg writes:
> Maildir pointed to by .qmail. The alternative would require a index or
> an outer container that houses the base Maildir. The latter is not
> consistent with the most common ~/Maildir/. As there is no standard,
> Sam will create the de-facto standard with sqwebmail and his IMAPd
> anyway.
F.Y.I: ETA on the IMAP server should be about 3-4 weeks. Pine looks good.
Netscape Communicator looks good (although there are a couple of nasty
bugs in the Communicator's IMAP client that I don't feel like
accomodating). I'll have to put it on hold for a week or two, while I take
care of other things, but I don't have much work left to do there.
--
Sam
Hi all,
Fred Lindberg wrote:
> Without folders and messages in the same folder, folders for folders
> would be normal nodes, folders for messages would be leaves. A
> tremendous gain for file system searches. No wading through piles of
> files [with stat()] to see if there is a directory.
It would be, if the folders and messages were stored in the same
directory. But with maildir this is no problem as the messages are
stored in the "new" and "cur" subdirectories.
Another question is where (and how) the possible subfolders should be
stored.
Jukka Zitting -------------------------
The Midgard Project -------------------
http://www.midgard-project.org/ -------
Hi all.
I have a somewhat complicated situation for which the simplest solution
is
a mail relay. I want a completely open mail relay that will accept mail
to be delivered to any domain whatsoever BUT I want it to only relay
through
one destination SMTP host.
We are setting up a "temporary" mail relay which catches mail sent to
the address of a mail server which is no longer the MX for our site, but
which may have mail sent to it by sites whose DNS hasn't updated to our
new MX records yet. I simply want our relay system to accept any mail
whatsoever, destined for anybody whatsoever (in essense, an "open
relay")
but relay all mail directly to our real mail server. The real mail
server will handle the virtual domains, and bouncing mail, etc, all
itself.
Is there an easy way to set qmail up this way? I set the smtproutes
file
to route mail to the new mail server, and everything works for our
actual domain (plumbdesign.com) as I have plumbdesign.com in the "me"
file of the relay. The problem comes with virtual domains - I don't
want to have to
set up virtual domains on the relay server just to have it route mail
for those domains; I just want it to catch all mail destined for anybody
and relay the mail to the real mail server, letting the real mail server
handle virtual domains and bounces, etc.
In order to cause our qmail-smtpd to accept mail destined for any host
whatsoever, I set the "RELAYCLIENT" environment variable in the shell
that runs qmail-smtpd from inetd.
Here is an example bounce message:
Return-Path: <bji>
Received: by plumbdesign.com (SMI-8.6/SMI-SVR4) id KAA24448; Mon, 27 Sep
1999 10:39:40 -0400
Message-ID: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 24435 invoked by alias); 27 Sep 1999 14:39:39 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 24430 invoked for bounce); 27 Sep 1999 14:39:38 -0000
Date: 27 Sep 1999 14:39:38 -0000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice
Content-Type: text
Content-Length: 891
Hi. This is the qmail-send program at plumbdesign.com.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[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)
--- Below this line is a copy of the message.
Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 24428 invoked from network); 27 Sep 1999 14:39:38 -0000
Received: from kelvin.plumbdesign.com (HELO plumbdesign.com)
(209.116.169.97)
by level.plumbdesign.com with SMTP; 27 Sep 1999 14:39:38 -0000
Received: (qmail 2046 invoked from network); 27 Sep 1999 14:40:41 -0000
Received: from millennium.plumbdesign.com ([EMAIL PROTECTED])
by kelvin.plumbdesign.com with SMTP; 27 Sep 1999 14:40:41 -0000
This is a test.
So to distill my question down to something very simple:
How can I configure qmail to relay all mail, regardless of the
destination, to another mail host? Or is there a better way to
do what I am trying to do?
Thanks,
Bryan
--
--------------------------------------------------------------------
Bryan Ischo p l u m b d e s i g n
[EMAIL PROTECTED] http://www.plumbdesign.com
Bryan Ischo wrote:
>
> Hi all.
>
> I have a somewhat complicated situation for which the simplest solution
> is
> a mail relay. I want a completely open mail relay that will accept mail
> to be delivered to any domain whatsoever BUT I want it to only relay
> through
> one destination SMTP host.
>
> We are setting up a "temporary" mail relay which catches mail sent to
> the address of a mail server which is no longer the MX for our site, but
> which may have mail sent to it by sites whose DNS hasn't updated to our
> new MX records yet. I simply want our relay system to accept any mail
> whatsoever, destined for anybody whatsoever (in essense, an "open
> relay")
> but relay all mail directly to our real mail server. The real mail
> server will handle the virtual domains, and bouncing mail, etc, all
> itself.
>
> Is there an easy way to set qmail up this way? I set the smtproutes
> file
> to route mail to the new mail server, and everything works for our
> actual domain (plumbdesign.com) as I have plumbdesign.com in the "me"
> file of the relay. The problem comes with virtual domains - I don't
> want to have to
> set up virtual domains on the relay server just to have it route mail
> for those domains; I just want it to catch all mail destined for anybody
> and relay the mail to the real mail server, letting the real mail server
> handle virtual domains and bounces, etc.
>
> In order to cause our qmail-smtpd to accept mail destined for any host
> whatsoever, I set the "RELAYCLIENT" environment variable in the shell
> that runs qmail-smtpd from inetd.
Hi again. If anyone is interested, it is actually quite easy to
set up qmail to work this way if you hack the source a bit. The
source is very well-organized and easy to hack. I simply #if'ed
out the place where it checks the rcpthosts file, and the place
where it checks the locals file. Viola. Now I have a qmail
installation that will accept anything at all and just forward it
on to the host listed in the smtproutes file.
Thanks, and best wishes,
Bryan
--
--------------------------------------------------------------------
Bryan Ischo p l u m b d e s i g n
[EMAIL PROTECTED] http://www.plumbdesign.com
Bryan Ischo <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Bryan Ischo wrote:
> >
> > Hi all.
> >
> > I have a somewhat complicated situation for which the simplest solution
> > is
> > a mail relay. I want a completely open mail relay that will accept mail
> > to be delivered to any domain whatsoever BUT I want it to only relay
> > through> > one destination SMTP host.
[snip]
> Hi again. If anyone is interested, it is actually quite easy to
> set up qmail to work this way if you hack the source a bit. The
> source is very well-organized and easy to hack. I simply #if'ed
> out the place where it checks the rcpthosts file, and the place
> where it checks the locals file. Viola. Now I have a qmail
> installation that will accept anything at all and just forward it
> on to the host listed in the smtproutes file.
Hi Bryan,
There is a simpler way: just delete rcpthosts altogether!
However, RELAYCLIENT should work OK even with rcpthosts - it's what I do on
my home network. I have a Linux box running qmail under tcpserver and allow
relaying from any of the hosts on my internal network (192.168.0.*) by
setting RELAYCLIENT="" in the tcprules file for qmail-smtpd:
127.0.0.:allow,RELAYCLIENT=""
192.168.0.:allow,RELAYCLIENT=""
That, in conjunction with a suitable smtproutes entry should do what you
want.
I notice you're still using inetd; it's honestly worth moving to tcpserver.
There are some sample scripts on the qmail home page, and I believe Dave
Sill's "Living with Qmail" is useful reading.
R.
I am now just starting school (today in fact) - i believe i had the 3.4.9 with
the imap stuff on orbital ken in the directory - we'll hafta go through and
make any changes you've made recently - and see about releasing that all
together
Eric
On Mon, 27 Sep 1999, x wrote:
> hi, all
>
> my system: redhat v6.0 qmail-1.03 tcp-server vpopmail-3.4.9
> imap-4.5.vchkpw.new.tar.gz ( using Maildir format )
>
> According to README.maildir of imap-4.5, i compile imap-4.5,
>
> command: make slx, found error infomation,
>
> =====
> make build EXTRACFLAGS="" EXTRALDFLAGS="" EXTRADRIVERS="mbox"
> EXTRAAUTHENTICATORS="" PASSWDTYPE=std GSSDIR=/usr/local OS=slx
> make[1]: Entering directory `/usr/local/etc/vpopmail-3.4.9/imap-4.5'
> Rebuilding c-client for slx...
> touch c-client/EXTRASPECIALS
> cd c-client;make all CC=`cat CCTYPE` CFLAGS="`cat CFLAGS`" `cat
> EXTRASPECIALS`
> make[2]: Entering directory
> `/usr/local/etc/vpopmail-3.4.9/imap-4.5/c-client'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/usr/local/etc/vpopmail-3.4.9/imap-4.5/c-client'
> sh -c 'rm -rf rebuild || true'
> Building bundled tools...
> cd mtest;make
> make[2]: Entering directory `/usr/local/etc/vpopmail-3.4.9/imap-4.5/mtest'
> `cat ../c-client/CCTYPE` -I../c-client `cat ../c-client/CFLAGS` -o mtest
> mtest.o ../c-client/c-client.a `cat ../c-client/LDFLAGS`
> mtest.o: In function `mm_login':
> /usr/local/etc/vpopmail-3.4.9/imap-4.5/mtest/mtest.c:531: the `gets'
> function is dangerous and should not be used.
> ../c-client/c-client.a(osdep.o): In function `open_smtp_relay':
> //usr/local/etc/vpopmail-3.4.9/imap-4.5/c-client/../../opensmtp.c:55:
> undefined reference to `lock_it'
> /usr/local/etc/vpopmail-3.4.9/imap-4.5/c-client/../../opensmtp.c:83:
> undefined reference to `unlock_it'
> collect2: ld returned 1 exit status
> make[2]: *** [mtest] Error 1
> make[2]: Leaving directory `/usr/local/etc/vpopmail-3.4.9/imap-4.5/mtest'
> make[1]: *** [bundled] Error 2
> make[1]: Leaving directory `/usr/local/etc/vpopmail-3.4.9/imap-4.5'
> make: *** [slx] Error 2
> =====
>
> but on vpopmail-3.4.6, compile imap-4.5.vchkpw.new.tar.gz is ok.
>
> Any help to solve this problem would be very appreciated.
>
> B/G.
>
> xww
--
----------------------------------------------------------------------
Eric Peters
C/C++/Perl/PHP/VB/CGI/SQL/Shell/Win32 API - You name It I can do it -
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
----------------------------------------------------------------------
On Mon, 13 Sep 1999, Petr Novotny wrote:
> What I guess you describe is that: Somewhere inside your network, you
> have an open relay (addressable from internet). Your blacklisted
> machine is a smart host for that open relay. You can't do anything
> about that problem on the border qmail. You need to fix the smtp
> machine inside the network.
This happened to me over the weekend. We were planning on taking the
internal host down, so we did. Now, ORBS still insists that our SMTP
smart host is an open relay. Now what should I do? Take a look if you're
interested:
http://www.orbs.org/messagelookup.cgi?address=141.233.143.1
--
Chuck Milam - [EMAIL PROTECTED]
I.T. Division - Academic Computing
University of Wisconsin Oshkosh
Quoting Chuck Milam ([EMAIL PROTECTED]):
>
> On Mon, 13 Sep 1999, Petr Novotny wrote:
>
> > What I guess you describe is that: Somewhere inside your network, you
> > have an open relay (addressable from internet). Your blacklisted
> > machine is a smart host for that open relay. You can't do anything
> > about that problem on the border qmail. You need to fix the smtp
> > machine inside the network.
>
> This happened to me over the weekend. We were planning on taking the
> internal host down, so we did. Now, ORBS still insists that our SMTP
> smart host is an open relay. Now what should I do? Take a look if you're
> interested:
>
> http://www.orbs.org/messagelookup.cgi?address=141.233.143.1
Oops, but it is still an open relay -- in a sense. ORBS does a lot of
different types of tests. You'll see that the email they tried to
relay was addressed to manawatu.co.nz!orbs-relaytest@[141.233.143.1].
I did in fact successfully relay a message to myself using
"coinet.com!aaron@[141.233.143.1]" in RCPT TO:, so you do have a hole
somewhere. Perhaps in some sort of UUCP mail processing.. ?
Aaron
--
Aaron L. Meehan [EMAIL PROTECTED]
System Administrator Central Oregon Internet
http://www.coinet.com/
Hi Everyone,
Every 30 seconds or so I get this in my log file
938452598.679039 tcpserver: pid 8819 from 12.69.1.57
938452598.807091 tcpserver: ok 8817 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4037
938452598.835702 tcpserver: status: 4/40
938452598.836327 tcpserver: pid 8820 from 12.69.1.57
938452598.882569 tcpserver: status: 5/40
938452598.883661 tcpserver: pid 8821 from 12.69.1.57
938452598.883973 tcpserver: ok 8818 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4039
938452598.981531 tcpserver: ok 8819 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4041
938452599.074135 tcpserver: status: 6/40
938452599.074801 tcpserver: pid 8822 from 12.69.1.57
938452599.203219 tcpserver: status: 7/40
938452599.204369 tcpserver: pid 8823 from 12.69.1.57
938452599.224972 tcpserver: ok 8820 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4043
938452599.324194 tcpserver: ok 8821 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4045
938452599.352396 tcpserver: status: 8/40
938452599.353117 tcpserver: pid 8824 from 12.69.1.57
938452599.448430 tcpserver: ok 8822 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4047
938452599.501438 tcpserver: status: 9/40
938452599.502081 tcpserver: pid 8825 from 12.69.1.57
938452599.593579 tcpserver: ok 8823 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4049
938452599.748770 tcpserver: ok 8824 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4051
938452599.843773 tcpserver: ok 8825 :139.142.67.213:25
57.middletown-02.va.dial-access.att.net:12.69.1.57::4053
938452600.450562 tcpserver: end 8817 status 256
938452600.450647 tcpserver: status: 8/40
938452600.487000 tcpserver: end 8818 status 256
938452600.487062 tcpserver: status: 7/40
938452600.578999 tcpserver: end 8819 status 256
938452600.579061 tcpserver: status: 6/40
938452600.846009 tcpserver: end 8820 status 256
938452600.846124 tcpserver: status: 5/40
938452600.918916 tcpserver: end 8821 status 256
938452600.918976 tcpserver: status: 4/40
938452601.052387 tcpserver: end 8822 status 256
938452601.052452 tcpserver: status: 3/40
938452601.322522 tcpserver: end 8823 status 256
938452601.322582 tcpserver: status: 2/40
938452601.553313 tcpserver: end 8824 status 256
938452601.553377 tcpserver: status: 1/40
938452601.553646 tcpserver: end 8825 status 256
After digging around some I couldn't any docs on qmail-smtpd log format. I've
tried blocking 12.69.1.57 in /etc/tcp.smtp but after a few minutes the person
gets a different IP address... If someone could point me to someplace where I
could learn whats happening or explain it here that would be great, thanks,
Tom
[EMAIL PROTECTED] wrote:
>938452598.883661 tcpserver: pid 8821 from 12.69.1.57
>938452599.324194 tcpserver: ok 8821 :139.142.67.213:25
>57.middletown-02.va.dial-access.att.net:12.69.1.57::4045
tcpserver accepted a connection from 12.69.1.57 and spawned pid 8821
to handle it.
>938452599.352396 tcpserver: status: 8/40
At this point, 8 of the maximum 40 allowed connections are in use.
>938452600.918916 tcpserver: end 8821 status 256
pid 8821 exited with status 256, an error.
>After digging around some I couldn't any docs on qmail-smtpd log
>format.
This is tcpserver logging. qmail-smtpd does do logging.
>I've tried blocking 12.69.1.57 in /etc/tcp.smtp but after a few
>minutes the person gets a different IP address... If someone could
>point me to someplace where I could learn whats happening or explain
>it here that would be great, thanks,
It looks like someone's trying to send you something (could be spam,
of course) and it's not getting through. You could use recordio as
documented in the on-line FAQ to see the complete SMTP sessions:
http://pobox.com/~djb/qmail/faq.html
-Dave
Dear List,
I want to setup 30,000+ virtual domains. Is there any
performance problems with this large virtualdomains and rcpthosts
files?
Or is there any way to avoid using these files? The domains are
of the same format: *.mydomain.com.
--
Mojahed
On Mon, 27 Sep 1999, Mojahedul Hoque Abul Hasanat wrote:
> Dear List,
> I want to setup 30,000+ virtual domains. Is there any
> performance problems with this large virtualdomains and rcpthosts
> files?
> Or is there any way to avoid using these files? The domains are
> of the same format: *.mydomain.com.
Hello:
Yes, I am also interested in hearing the list's view on this. My
/var/qmail/users/cdb file is at 20M+. I have 200K+ virtual users and I am
wondering if I should move away from the file based approach.
Is there a patch that will use a database (postgres/mysql) for looking up
virtual users instead of the cdb file?
Anyone else facing the same issues??
Regards
--
Burzin
On 9/27/99 at 10:46 AM, [EMAIL PROTECTED] (B. Engineer) wrote:
> On Mon, 27 Sep 1999, Mojahedul Hoque Abul Hasanat wrote:
>
> > Dear List,
> > I want to setup 30,000+ virtual domains. Is there any
> > performance problems with this large virtualdomains and rcpthosts
> > files?
> > Or is there any way to avoid using these files? The domains are
> > of the same format: *.mydomain.com.
>
> Hello:
> Yes, I am also interested in hearing the list's view on this. My
> /var/qmail/users/cdb file is at 20M+. I have 200K+ virtual users and I am
> wondering if I should move away from the file based approach.
>
> Is there a patch that will use a database (postgres/mysql) for looking up
> virtual users instead of the cdb file?
>
> Anyone else facing the same issues??
You might want to check this message from the qmail archive:
http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/08/msg01079.html
It talks about using cbd database for storing this information.
Pat
--
Freestyle Interactive | http://www.freestyleinteractive | 415.778.0610
I would not think so. Filtering is based on a simple premise... don not
accept packets from a specific IP address or range of IP's. If you don't
know what IP 's to filter, then you must find a way to get that
information. Try netstat -n or grep your mail logs for the IP's in
question.... sooner or later you wil have a bunch of IP's to filter...
that's a good starting point.
Paul Farber
Farber Technology
[EMAIL PROTECTED]
Ph 570-628-5303
Fax 570-628-5545
On Sun, 26 Sep 1999, Abel Lucano wrote:
> On Sat, 25 Sep 1999 [EMAIL PROTECTED] wrote:
>
> > find out that ip address aol is using and
> > ipfwadm -I -a deny -S AOL.IP.ADDRESS.HERE -D YOUR.MAIL.SERVER.IP
> >
> > or use tcpserver.
>
> i believe that i'm doing so, but aol relays rotates and i'm receiving
> bounces from differents ip's (lot of aol's relays)
> Maybe i don't understand filtering fully;
> Perhaps there is an script or rule to stop mail bombing by subject or
> whatever else.
>
> Thanks again
>
> Abel Lucano
> email: [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> > On Sat, 25 Sep 1999, Abel Lucano wrote:
> >
> > > I'm receiving hundreds of mails bounced from aol.com, and i cannot put the
> > > right rule in badmailfrom to effective filtering
> > >
> > > Our main MX running qmail-1.03 with tcpserver is called ferro.ba.net at
> > > 200.41.130.3; it's NOT an open relay.
> > > ba.net is our domain.
> > >
> > > There's an spammer at ppp187.champaign.advancenet.net [206.221.224.187]
> > > sending mails "as from ba.net domain" to aol.com domain
> > >
> > > I'm receiving all the bounces. (a lot!!)
> > > Do I put in badmailfrom all the aol.com relays
> > > @rly-yc05.mail.aol.com, etc? (a lot)
> > >
> > > (putting @aol.com for a moment doesn't works neither)
> > >
> > > Please, i would appreciate very much any advice to stop this.
> > >
> > > Thanks (a lot) in advance
> > >
> > > Abel Lucano
> > > email: [EMAIL PROTECTED]
> > > [EMAIL PROTECTED]
> > >
> > >
> > >
> > > Below one copy of one bounce.
> > >
> > >
> > >
> > > Return-Path: <>
> > > Received: (qmail 27016 invoked from network); 25 Sep 1999 19:41:56 -0000
> > > Received: from aolmbd02.mx.aol.com (205.188.156.76)
> > > by ferro.ba.net with SMTP; 25 Sep 1999 19:41:56 -0000
> > > Received: from rly-yc05.mx.aol.com (rly-yc05.mail.aol.com [172.18.149.37])
> > > by aolmbd02.mx.aol.com (8.8.8/8.8.5/AOL-2.0.0)
> > > with ESMTP id SAA23285 for <[EMAIL PROTECTED]>;
> > > Sat, 25 Sep 1999 18:32:38 -0400 (EDT)
> > > Received: from localhost (localhost)
> > > by rly-yc05.mx.aol.com (8.8.8/8.8.5/AOL-4.0.0)
> > > with internal id SAB04911;
> > > Sat, 25 Sep 1999 18:32:38 -0400 (EDT)
> > > Date: Sat, 25 Sep 1999 18:32:38 -0400 (EDT)
> > > From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
> > > Message-Id: <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > MIME-Version: 1.0
> > > Content-Type: multipart/report; report-type=delivery-status
> > > boundary="SAB04911.938298758/rly-yc05.mx.aol.com"
> > > Subject: Returned mail: User unknown
> > > Auto-Submitted: auto-generated (failure)
> > >
> > > This is a MIME-encapsulated message
> > >
> > > --SAB04911.938298758/rly-yc05.mx.aol.com
> > >
> > > The original message was received at Sat, 25 Sep 1999 18:32:33 -0400 (EDT)
> > > from ppp187.champaign.advancenet.net [206.221.224.187]
> > >
> > >
> > > *** ATTENTION ***
> > >
> > > Your e-mail is being returned to you because there was a problem with its
> > > delivery. The AOL address which was undeliverable is listed in the
> > > section
> > > labeled: "----- The following addresses had permanent fatal errors -----".
> > >
> > > The reason your mail is being returned to you is listed in the section
> > >
> > > labeled: "----- The following addresses had permanent fatal errors -----".
> > >
> > > The reason your mail is being returned to you is listed in the section
> > > labeled: "----- Transcript of Session Follows -----".
> > >
> > > The line beginning with "<<<" describes the specific reason your e-mail
> > > could
> > > not be delivered. The next line contains a second error message which is
> > > a
> > > general translation for other e-mail servers.
> > >
> > > Please direct further questions regarding this message to your e-mail
> > > administrator.
> > >
> > > --AOL Postmaster
> > >
> > > <[EMAIL PROTECTED]>
> > > ----- Transcript of session follows -----
> > > ... while talking to air-yc01.mail.aol.com.:
> > > >>> RCPT To:<[EMAIL PROTECTED]>
> > > <<< 550 xena1948 IS NOT ACCEPTING MAIL FROM THIS SENDER
> > > 550 <[EMAIL PROTECTED]>... User unknown
> > >
> > > --SAB04911.938298758/rly-yc05.mx.aol.com
> > > Content-Type: message/delivery-status
> > >
> > > Reporting-MTA: dns; rly-yc05.mx.aol.com
> > > Arrival-Date: Sat, 25 Sep 1999 18:32:33 -0400 (EDT)
> > >
> > > Final-Recipient: RFC822; [EMAIL PROTECTED]
> > > Action: failed
> > > Status: 2.0.0
> > > Remote-MTA: DNS; air-yc01.mail.aol.com
> > > Diagnostic-Code: SMTP; 250 OK
> > > Last-Attempt-Date: Sat, 25 Sep 1999 18:32:38 -0400 (EDT)
> > > ast-Attempt-Date: Sat, 25 Sep 1999 18:32:38 -0400 (EDT)
> > >
> > > --SAB04911.938298758/rly-yc05.mx.aol.com
> > > Content-Type: message/rfc822
> > >
> > > Received: from ba.net (ppp187.champaign.advancenet.net [206.221.224.187])
> > > by
> > > rly-yc05.mx.aol.com (v61.9) with ESMTP; Sat, 25 Sep 1999 18:32:32 -0400
> > > From: <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Hey man
> > > Date: Sat, 25 Sep 1999 17:32:44
> > > Message-Id: <[EMAIL PROTECTED]>
> > > Reply-To: [EMAIL PROTECTED]
> > > Mime-Version: 1.0
> > > Content-Type: text/html; charset="us-ascii"
> > >
> > >
> > > <html>
> > > <HEAD>
> > >
> > > <HEAD>
> > > <TITLE>(Type a title for your page here)</TITLE>
> > >
> > > </HEAD>
> > >
> > > <BODY BACKGROUND="" BGCOLOR="#000000" TEXT="white" LINK="red" VLINK=""
> > > ALINK="#ff0000">
> > >
> > > <A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>>
> > > <B><A HREF="http://3470651298/barney/"><FONT SIZE="+1" color="cyan">Hi
> > > There...My names is Amber. My girlfriends Elaine and Louise came over
> > > this
> > > past weekend with their new digital camera, and after a little wine, and a
> > > lot
> > > of foolin' around, we got a little crazy...Anyways, now that the pictures
> > > are
> > > taken, we might as well show them to SOMEONE, so how about
> > > you?</FONT></a></B><BR>
> > > <A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>
> > >
> > > </BODY>
> > > </html>
> > >
> > >
> > >
> > >
> >
> >
>
>
On Sun, 26 Sep 1999 [EMAIL PROTECTED] wrote:
> I would not think so. Filtering is based on a simple premise... don not
> accept packets from a specific IP address or range of IP's. If you don't
> know what IP 's to filter, then you must find a way to get that
> information. Try netstat -n or grep your mail logs for the IP's in
> question.... sooner or later you wil have a bunch of IP's to filter...
> that's a good starting point.
>
Paul
thanks for your approach.
Finally i had to filter spammer with ipfwadm to prevent my mail server of
one denial of service.
But ipfwadm it's not a qmail topic.
Under qmail, i was able (until yesterday) to filter undesirable spam
mostly with /var/qmail/control/badmailfrom
The question here arises in one spammer (206.221.224.187)
who's spamming aol.com from one ppp session with a bogus domain "ba.net"
that doesn't belongs to him.
(from ba.net (ppp187.champaign.advancenet.net [206.221.224.187]))
AOL's DNS "resolves" ba.net (badly in my opinion) and the aol's
relays were sending tons of bounce emails to my mailserver. (the
real ba.net domain).
I'll try at first with @rly-yc04.mx.aol.com in badmailfrom.
If this interest you, see one of the bounces below.
Aol's relays rotates, then i tried (one domain by line obviously)
@[205.188.156.79], [EMAIL PROTECTED], @[205.188.156.78],@rly-bza01.mx.aol.com
@rly-yb05.mx.aol.com, @rly-yd01.mx.aol.com ,@rly-yc05.mail.aol.com
I've put the line @aol.com in badmailfrom; i couldn't stop the bombing
with this approach.
Finally i give up and i use ipfwadm (a UNIX tool, not an QMAIL tool) (as
you and other kind guys advise to me in this list);
that's the whole history; i'm remains filtering aol.com today until the
attack passes. It's not my desire and it's not a 'professional' solution
but..
Excuse me all for this maybe long email
Regards
Abel Lucano
email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
---------------------------------------------------------------------------
Return-Path: <>
Received: (qmail 19037 invoked from network); 26 Sep 1999 09:50:32 -0000
Received: from aolmbr03.mx.aol.com (198.81.17.131)
by ferro.ba.net with SMTP; 26 Sep 1999 09:50:32 -0000
Received: from rly-yc04.mx.aol.com (rly-yc04.mail.aol.com [172.18.149.36])
by aolmbr03.mx.aol.com (8.8.8/8.8.5/AOL-2.0.0)
with ESMTP id IAA15844 for <[EMAIL PROTECTED]>;
Sun, 26 Sep 1999 08:31:39 -0400 (EDT)
Received: from localhost (localhost)
by rly-yc04.mx.aol.com (8.8.8/8.8.5/AOL-4.0.0)
with internal id IAA16080;
Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
Date: Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="IAA16080.938349612/rly-yc04.mx.aol.com"
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
This is a MIME-encapsulated message
--IAA16080.938349612/rly-yc04.mx.aol.com
The original message was received at Sun, 26 Sep 1999 08:40:00 -0400 (EDT)
from ppp187.champaign.advancenet.net [206.221.224.187]
* ATTENTION ***
Your e-mail is being returned to you because there was a problem with its
delivery. The AOL address which was undeliverable is listed in the
section
labeled: "----- The following addresses had permanent fatal errors -----".
The reason your mail is being returned to you is listed in the section
labeled: "----- Transcript of Session Follows -----".
The line beginning with "<<<" describes the specific reason your e-mail
could
not be delivered. The next line contains a second error message which is
a
general translation for other e-mail servers.
Please direct further questions regarding this message to your e-mail
administrator.
--AOL Postmaster
----- The following addresses had permanent fatal errors -----
<[EMAIL PROTECTED]>
----- Transcript of session follows -----
... while talking to air-yc02.mail.aol.com.:
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 550 MAILBOX NOT FOUND
550 <[EMAIL PROTECTED]>... User unknown
--IAA16080.938349612/rly-yc04.mx.aol.com
Content-Type: message/delivery-status
Reporting-MTA: dns; rly-yc04.mx.aol.com
Arrival-Date: Sun, 26 Sep 1999 08:40:00 -0400 (EDT)
Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 2.0.0
Remote-MTA: DNS; air-yc02.mail.aol.com
Last-Attempt-Date: Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
--IAA16080.938349612/rly-yc04.mx.aol.com
Content-Type: message/rfc822
Received: from ba.net (ppp187.champaign.advancenet.net [206.221.224.187])
by
rly-yc04.mx.aol.com (v61.9) with ESMTP; Sun, 26 Sep 1999 08:39:55 -0400
From: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Hey man
Date: Sun, 26 Sep 1999 07:40:03
Message-Id: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
<HEAD>
<TITLE>(Type a title for your page here)</TITLE>
</HEAD>
<BODY BACKGROUND="" BGCOLOR="#000000" TEXT="white" LINK="red" VLINK=""
ALINK="#ff0000">
<A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>>
<B><A HREF="http://3470651298/barney/"><FONT SIZE="+1" color="cyan">Hi
There...My names is Amber. My girlfriends Elaine and Louise came over
this
past weekend with their new digital camera, and after a little wine, and a
lot
of foolin' around, we got a little crazy...Anyways, now that the pictures
are
taken, we might as well show them to SOMEONE, so how about
you?</FONT></a></B><BR>
<A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>
</BODY>
On Mon, 27 Sep 1999, Abel Lucano wrote:
> Under qmail, i was able (until yesterday) to filter undesirable spam
> mostly with /var/qmail/control/badmailfrom
>
> The question here arises in one spammer (206.221.224.187)
> who's spamming aol.com from one ppp session with a bogus domain "ba.net"
> that doesn't belongs to him.
> (from ba.net (ppp187.champaign.advancenet.net [206.221.224.187]))
>
> AOL's DNS "resolves" ba.net (badly in my opinion) and the aol's
> relays were sending tons of bounce emails to my mailserver. (the
> real ba.net domain).
>
> I'll try at first with @rly-yc04.mx.aol.com in badmailfrom.
> If this interest you, see one of the bounces below.
> Aol's relays rotates, then i tried (one domain by line obviously)
>
> @[205.188.156.79], [EMAIL PROTECTED], @[205.188.156.78],@rly-bza01.mx.aol.com
> @rly-yb05.mx.aol.com, @rly-yd01.mx.aol.com ,@rly-yc05.mail.aol.com
>
> I've put the line @aol.com in badmailfrom; i couldn't stop the bombing
> with this approach.
>
> Finally i give up and i use ipfwadm (a UNIX tool, not an QMAIL tool) (as
> you and other kind guys advise to me in this list);
If you can get their IP, which by my understanding you have, you can do
what I do.
I have my resolve.conf set up to look in my hosts file first, and then
DNS (order hosts,bind). I put their IP address in my /etc/hosts as:
206.221.224.187 zero.spammer.dom
and in my smtpd script (which checks incoming IPs against known bad ones),
I deny SMTP service to *.spammer.dom
Assigning our own internal name to the spammer's IP bypasses any DNS
checks.
But he's using a dialup, so this prolly won't work in your exact case
(dynamic ips). I'd bring the issue up with his provider, and get him cut
off.
.Shawn
By the time the packet hits badmail from you've already done a lot of work
to just reject the connection.
Filter it as soon as possible. BEFORE it get to you SMTP port.... so you
don't have to spawn an ident child, then a qmail-smtpd then reject the
packet. I'm not sure of exactly how far up the chain you would go to
finally get to the badmailfrom file..... but it has to be slower than
ipfwadm.
Paul Farber
Farber Technology
[EMAIL PROTECTED]
Ph 570-628-5303
Fax 570-628-5545
On Mon, 27 Sep 1999, Abel Lucano wrote:
> On Sun, 26 Sep 1999 [EMAIL PROTECTED] wrote:
>
> > I would not think so. Filtering is based on a simple premise... don not
> > accept packets from a specific IP address or range of IP's. If you don't
> > know what IP 's to filter, then you must find a way to get that
> > information. Try netstat -n or grep your mail logs for the IP's in
> > question.... sooner or later you wil have a bunch of IP's to filter...
> > that's a good starting point.
> >
>
> Paul
>
> thanks for your approach.
>
> Finally i had to filter spammer with ipfwadm to prevent my mail server of
> one denial of service.
> But ipfwadm it's not a qmail topic.
>
> Under qmail, i was able (until yesterday) to filter undesirable spam
> mostly with /var/qmail/control/badmailfrom
>
> The question here arises in one spammer (206.221.224.187)
> who's spamming aol.com from one ppp session with a bogus domain "ba.net"
> that doesn't belongs to him.
> (from ba.net (ppp187.champaign.advancenet.net [206.221.224.187]))
>
> AOL's DNS "resolves" ba.net (badly in my opinion) and the aol's
> relays were sending tons of bounce emails to my mailserver. (the
> real ba.net domain).
>
> I'll try at first with @rly-yc04.mx.aol.com in badmailfrom.
> If this interest you, see one of the bounces below.
> Aol's relays rotates, then i tried (one domain by line obviously)
>
> @[205.188.156.79], [EMAIL PROTECTED], @[205.188.156.78],@rly-bza01.mx.aol.com
> @rly-yb05.mx.aol.com, @rly-yd01.mx.aol.com ,@rly-yc05.mail.aol.com
>
> I've put the line @aol.com in badmailfrom; i couldn't stop the bombing
> with this approach.
>
> Finally i give up and i use ipfwadm (a UNIX tool, not an QMAIL tool) (as
> you and other kind guys advise to me in this list);
>
> that's the whole history; i'm remains filtering aol.com today until the
> attack passes. It's not my desire and it's not a 'professional' solution
> but..
>
> Excuse me all for this maybe long email
>
> Regards
>
> Abel Lucano
> email: [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------------
> Return-Path: <>
> Received: (qmail 19037 invoked from network); 26 Sep 1999 09:50:32 -0000
> Received: from aolmbr03.mx.aol.com (198.81.17.131)
> by ferro.ba.net with SMTP; 26 Sep 1999 09:50:32 -0000
> Received: from rly-yc04.mx.aol.com (rly-yc04.mail.aol.com [172.18.149.36])
> by aolmbr03.mx.aol.com (8.8.8/8.8.5/AOL-2.0.0)
> with ESMTP id IAA15844 for <[EMAIL PROTECTED]>;
> Sun, 26 Sep 1999 08:31:39 -0400 (EDT)
> Received: from localhost (localhost)
> by rly-yc04.mx.aol.com (8.8.8/8.8.5/AOL-4.0.0)
> with internal id IAA16080;
> Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
> Date: Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
> From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
> Message-Id: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> Content-Type: multipart/report; report-type=delivery-status;
> boundary="IAA16080.938349612/rly-yc04.mx.aol.com"
> Subject: Returned mail: User unknown
> Auto-Submitted: auto-generated (failure)
>
> This is a MIME-encapsulated message
>
> --IAA16080.938349612/rly-yc04.mx.aol.com
>
> The original message was received at Sun, 26 Sep 1999 08:40:00 -0400 (EDT)
> from ppp187.champaign.advancenet.net [206.221.224.187]
>
> * ATTENTION ***
>
> Your e-mail is being returned to you because there was a problem with its
> delivery. The AOL address which was undeliverable is listed in the
> section
> labeled: "----- The following addresses had permanent fatal errors -----".
>
> The reason your mail is being returned to you is listed in the section
> labeled: "----- Transcript of Session Follows -----".
>
> The line beginning with "<<<" describes the specific reason your e-mail
> could
> not be delivered. The next line contains a second error message which is
> a
> general translation for other e-mail servers.
>
> Please direct further questions regarding this message to your e-mail
> administrator.
>
> --AOL Postmaster
>
> ----- The following addresses had permanent fatal errors -----
> <[EMAIL PROTECTED]>
>
> ----- Transcript of session follows -----
> ... while talking to air-yc02.mail.aol.com.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 550 MAILBOX NOT FOUND
> 550 <[EMAIL PROTECTED]>... User unknown
>
> --IAA16080.938349612/rly-yc04.mx.aol.com
> Content-Type: message/delivery-status
>
> Reporting-MTA: dns; rly-yc04.mx.aol.com
> Arrival-Date: Sun, 26 Sep 1999 08:40:00 -0400 (EDT)
>
> Final-Recipient: RFC822; [EMAIL PROTECTED]
> Action: failed
> Status: 2.0.0
> Remote-MTA: DNS; air-yc02.mail.aol.com
> Last-Attempt-Date: Sun, 26 Sep 1999 08:40:12 -0400 (EDT)
>
> --IAA16080.938349612/rly-yc04.mx.aol.com
> Content-Type: message/rfc822
>
> Received: from ba.net (ppp187.champaign.advancenet.net [206.221.224.187])
> by
> rly-yc04.mx.aol.com (v61.9) with ESMTP; Sun, 26 Sep 1999 08:39:55 -0400
> From: <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Hey man
> Date: Sun, 26 Sep 1999 07:40:03
> Message-Id: <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Mime-Version: 1.0
> Content-Type: text/html; charset="us-ascii"
>
>
> <HEAD>
> <TITLE>(Type a title for your page here)</TITLE>
>
> </HEAD>
>
> <BODY BACKGROUND="" BGCOLOR="#000000" TEXT="white" LINK="red" VLINK=""
> ALINK="#ff0000">
>
> <A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>>
> <B><A HREF="http://3470651298/barney/"><FONT SIZE="+1" color="cyan">Hi
> There...My names is Amber. My girlfriends Elaine and Louise came over
> this
> past weekend with their new digital camera, and after a little wine, and a
> lot
> of foolin' around, we got a little crazy...Anyways, now that the pictures
> are
> taken, we might as well show them to SOMEONE, so how about
> you?</FONT></a></B><BR>
> <A HREF="http://3470651298/barney/"><FONT SIZE="+2">Click Here</FONT>
>
> </BODY>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
ok real quick let me say that i think we've beat this horse good and dead
into the ground. that said, however, i think there's been a lot of useful
discussion about an issue that really hasn't been researched in the light of
modern SMTP systems. that is, the whole notion of MX records started about
15 or so years ago, and maybe it's time to clarify some of the behaviors
we've been talking about. i would suggest that we form another list and
attempt to draft some sort of standard or RFC - not necessarily to decide on
fixed behaviors that are really issues of policy, but to better define the
various possible situations so that MTA developers can easily compare what
their MTA does in a certain situation. no, i'm not going to be the one to
lead that effort, but i'll gladly participate :)
> intend to converse SMTP. A configuration of firewalls that causes the
> connection to happen even though the destination is not willing (perhaps
at
> this time) to converse SMTP, is misleading at best. The firewall is
> certainly badly implemented, and I would consider it to be broken.
yes, in this particular case, the firewall is the issue - it's pretty
broken. but the discussion is over what qmail should do. qmail has no idea
that there's a firewall in between.
> > halfway done and then the connection times out. let's say you send
EHLO,
> > MAIL FROM, RCPT TO, and all is well, and you start your DATA but you
never
> > get an ok from the remote. does that mean you should fall back to the
next
> > MX?
>
> Does it mean you should not?
it would be nice to have a state diagram that shows what paths the program
might take depending on how far the SMTP transaction gets. at least then
you'd know what the program does and (i guess) you could modify its behavior
appropriately.
> A way to work around that failure is to try another MX host, if more than
> one is present, guided by the priority information given. It may not be
> mandatory to do so, but doing so is a way to work around failure. An
> implementation that does not fall back to another MX is an implementation
> that is not attempting to work around failure.
"failure" is a subjective term.
> Which scenario are you referring to when you say "the DNS configuration IS
> broken"? Are you referring to the scenario where the firewall is broken,
> and just tossing this in to confuse the issue? Since when is having more
> than one MX record for a host to be considered "broken" when one of the
> hosts might be down?
publishing an MX host that is never reachable seems pretty broken to me. it
may be technically permitted, i suppose it's not explicitly forbidden
anywhere, but publishing the record is like saying "what if 2 plus 2 equals
5?" interesting concept but pointless to bother with it. the firewall is
clouding the issue.
> Just because one scenario which Qmail could "work around" happens to be a
> scenario which is either configured or implemented broken, does not mean
> that no other scenarios can exist which would involve the same issue.
Just
> because one scenario represents a case which is not an interim failure
does
> not mean that every scenario is likewise.
agreed.
> Hosts do sometimes go down. They do sometimes fail. They do sometimes
have
> problems which, while not entirely crashing, do prevent the completion of
a
> protocol at ANY step along its defined path, including before and
> immediately after the TCP connection is established. Even Qmail could
fail
> in such a way when running on a machine which has an interim problem
> providing Qmail with the resources to complete execution (e.g. memory
> exhausted). It's a failure. You might call it "broken" if you want. The
> issue is whether or not it is worthwhile to attempt to work around the
> failure.
the issue is more than that - it's "to what lengths should qmail go to work
around the failure?"
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
Racer X wrote:
> publishing an MX host that is never reachable seems pretty broken to me. it
> may be technically permitted, i suppose it's not explicitly forbidden
> anywhere, but publishing the record is like saying "what if 2 plus 2 equals
> 5?" interesting concept but pointless to bother with it. the firewall is
> clouding the issue.
If a server was broken, and I had no intent to fix it, but published an MX
pointing to it anyway, I would agree that is broken. OTOH, servers break,
and DNS servers don't know to withdraw the MX, and MTAs don't know if the
time frame is "never" or "for a while".
> the issue is more than that - it's "to what lengths should qmail go to work
> around the failure?"
... and what are the costs of doing so versus the benefits. Choosing to
sometimes retry the 2nd MX in the same process that just tried the 1st
would only cost the additional connection attempt. If it makes the
difference between successful or failed delivery of the mail, it would
be worth it. If it makes mail arrive earlier it may still be worth it.
OTOH, adding an elaborate scheme to the MTA which requires adding new
information in the mail queue to make complex delivery and recovery
decisions would certainly be costly and probably not worth the effort.
OTTOMH, I would favor a randomized fallback scheme which does not depend
on queued message state. When a delivery failure occurs, choose a random
number, then decide whether to now try the next MX based on a probability
derived from the MX level, or the ratio of MX levels, then maybe or maybe
not retry the next level before requeueing.
Should MX entries of equal value be tried equally?
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Racer X <[EMAIL PROTECTED]> writes on 27 September 1999 at 12:19:57 -0700
> publishing an MX host that is never reachable seems pretty broken to me. it
> may be technically permitted, i suppose it's not explicitly forbidden
> anywhere, but publishing the record is like saying "what if 2 plus 2 equals
> 5?" interesting concept but pointless to bother with it. the firewall is
> clouding the issue.
Actually, I think the "permanently broken" MX host itself is clouding
the issue. I get the impression that some people have strong feelings
that we shouldn't change things to help out people with lazy "bad"
configurations; they should be punished for their sins. I'm even
capable of feeling that way myself with just a little encouragement
:-) .
So, suppose that the hypothetical host is in fact only broken for 1
month (they didn't update the DNS because they expected the new part
to arrive any day, and then it was DOA and they had to start over, and
because they believed that MTAs would fail over to their secondary MX,
and they didn't realize their firewall was accepting the connection
and then leaving it hanging). What is the appropriate MTA behavior in
this case? It seems clear to me that what everybody would want in
this situation is for an MTA to fail over to the secondary MX.
Should we be giving any consideration to the question of whether, on
the average, secondary MXs are less reliable than primary? I don't
think we should; I don't think we should warp the implementation to
accommodate incorrectly configured systems. (If we can accommodate
them with some change that *doesn't* warp things, then we should; "be
generous in what you accept").
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 27 September 1999 at 15:06:28 -0500
> OTTOMH, I would favor a randomized fallback scheme which does not depend
> on queued message state. When a delivery failure occurs, choose a random
> number, then decide whether to now try the next MX based on a probability
> derived from the MX level, or the ratio of MX levels, then maybe or maybe
> not retry the next level before requeueing.
>
> Should MX entries of equal value be tried equally?
I think attempting to make inferences about the relative priority of
MX records from the differences in their priorities is a BIG mistake
(other than the defined ordering). Many MX priority schemes are
historical, and involve fitting things into existing cracks, so the
intervals and values are random, except for ording. And it's a misuse
of the priority value, subject to massive breakage if somebody else
defines a competing misuse, or if a standard meaning is adopted. Just
don't go there!
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
David Dyer-Bennet writes:
> What is the appropriate MTA behavior in this case? It seems clear
> to me that what everybody would want in this situation is for an
> MTA to fail over to the secondary MX.
If their MX records are incorrectly configured, their email isn't
going to go through. Why should other hosts go through heroic hoops
just to get the mail to them?
> Should we be giving any consideration to the question of whether, on
> the average, secondary MXs are less reliable than primary? I don't
> think we should; I don't think we should warp the implementation to
> accommodate incorrectly configured systems.
Aren't you doing just that? Right now, qmail works fine for machines
which are correctly configured but sometimes inaccessible. Various
people (not you) are talking about warping the implementation to
accommodate incorrectly configured systems. There's a ton of
different ways you can configure your system so that email bounces.
Why should a remote system bother to work around any of them? I mean,
there's the chance that the SMTP server might be configured with the
wrong hostname, so the client should strip off the hostname for the
RCPT TO: lines, right??
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 16:44:19 -0400
> David Dyer-Bennet writes:
> > What is the appropriate MTA behavior in this case? It seems clear
> > to me that what everybody would want in this situation is for an
> > MTA to fail over to the secondary MX.
>
> If their MX records are incorrectly configured, their email isn't
> going to go through. Why should other hosts go through heroic hoops
> just to get the mail to them?
I would not describe the MX records as incorrectly configured; the
primary MX points to what's supposed to be their primary mail
exchanger, *but it's down for an unexpectedly long period*. Since
they have a secondary MX in place, they don't worry about updating the
DNS, expecting MTAs to fail over to the secondary DNS since the
primary is down.
Nor do I consider it jumping through "heroic hoops" to notice that you
can't connect to the primary MX, and decide to try the next one.
> > Should we be giving any consideration to the question of whether, on
> > the average, secondary MXs are less reliable than primary? I don't
> > think we should; I don't think we should warp the implementation to
> > accommodate incorrectly configured systems.
>
> Aren't you doing just that? Right now, qmail works fine for machines
> which are correctly configured but sometimes inaccessible.
It doesn't work fine in the scenario I outlined at the beginning of my
message. In that situation, the mail will sit on the qmail system
until it expires, when there's a perfectly good secondary MX system
sitting there waiting to accept it. This is not my definition of
"works fine".
> Various people (not you) are talking about warping the
> implementation to accommodate incorrectly configured systems.
> There's a ton of different ways you can configure your system so
> that email bounces. Why should a remote system bother to work
> around any of them? I mean, there's the chance that the SMTP
> server might be configured with the wrong hostname, so the client
> should strip off the hostname for the RCPT TO: lines, right??
The secondary MX exists to cover cases when the primary is down. It's
not an "incorrectly configured" DNS to have a primary MX listed that
happens to be down at the moment!
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
David Dyer-Bennet writes:
> Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 16:44:19 -0400
> > > Should we be giving any consideration to the question of whether, on
> > > the average, secondary MXs are less reliable than primary? I don't
> > > think we should; I don't think we should warp the implementation to
> > > accommodate incorrectly configured systems.
> >
> > Aren't you doing just that? Right now, qmail works fine for machines
> > which are correctly configured but sometimes inaccessible.
>
> It doesn't work fine in the scenario I outlined at the beginning of my
> message. In that situation, the mail will sit on the qmail system
> until it expires, when there's a perfectly good secondary MX system
> sitting there waiting to accept it. This is not my definition of
> "works fine".
Right, but you're suggesting that nobody will notice the lack of
reception of email for seven days. If they make configuration changes
without testing them (and I count leaving a down machine down as
such), and then don't notice that something is broken for a week, then
I'll wager that they'll be suited just as well without email.
You're also presuming that they have the ability to read email off the
"secondary" host. It would be very unusual for a host which functions
identically to another to be given a lower priority. Much more often,
the secondary host is one which is configured only to relay mail to
the primary.
> > Various people (not you) are talking about warping the
> > implementation to accommodate incorrectly configured systems.
> > There's a ton of different ways you can configure your system so
> > that email bounces. Why should a remote system bother to work
> > around any of them? I mean, there's the chance that the SMTP
> > server might be configured with the wrong hostname, so the client
> > should strip off the hostname for the RCPT TO: lines, right??
>
> The secondary MX exists to cover cases when the primary is down. It's
> not an "incorrectly configured" DNS to have a primary MX listed that
> happens to be down at the moment!
And a firewall which accepts connections for a down host is not
misconfigured or broken by design??
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
On Mon, 27 Sep 1999, Russell Nelson wrote:
> David Dyer-Bennet writes:
> > It doesn't work fine in the scenario I outlined at the beginning of my
> > message. In that situation, the mail will sit on the qmail system
> > until it expires, when there's a perfectly good secondary MX system
> > sitting there waiting to accept it. This is not my definition of
> > "works fine".
>
> Right, but you're suggesting that nobody will notice the lack of
> reception of email for seven days. If they make configuration changes
> without testing them (and I count leaving a down machine down as
> such), and then don't notice that something is broken for a week, then
> I'll wager that they'll be suited just as well without email.
Exactly. There seems to be some very odd ideas of what a higher-numbered
MX will do floating around in this discussion.
> You're also presuming that they have the ability to read email off the
> "secondary" host. It would be very unusual for a host which functions
> identically to another to be given a lower priority. Much more often,
> the secondary host is one which is configured only to relay mail to
> the primary.
Which is the defined behavior, and the default behavior in sendmail,
qmail, and most other mailers I know of.
Once the mail gets to the lowest-numbered MX, then any funny "local"
processing happens. If a host is configured as "fallback" but only for
use when the primary has a problem, yet the DNS is not changed to reflect
the seondary's new status when the primary does fail, then one is sending
the world mixed signals, and one gets what one deserves. The more typical
setup is to give them idenitical MXs, in which case even qmail will try
more than one given bad delivery problems.
> > The secondary MX exists to cover cases when the primary is down. It's
> > not an "incorrectly configured" DNS to have a primary MX listed that
> > happens to be down at the moment!
The secondary MX exists to receive mail for holding and requeuing to pass
onto the primary when the primary is not reachable by the sender and the
sender wants to unqueue the mail. If you're talking about failover, you
either need equal MX weights, or you need to have the DNS adjust when the
lower MX goes down. Anything else is a kludge, and an insistence thatthe
world support various kludges, when doing it right is quite simple.
As Russ noted, it may be not "incorrectly configured" DNS if the main mail
server is down, but it's certainly not correct if you have two hosts
acting as final mail destinations yet with differing MX weights, and you
expect there never to be a glitch if the lower-numbered one is acting
sort-of alive yet is unable to really receive mail.
-M
Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst
Mainlining Internet Connectivity for Fun and Profit
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Give me a compiler and a box to run it, and I can move the mail.
Russell Nelson wrote:
> David Dyer-Bennet writes:
> > What is the appropriate MTA behavior in this case? It seems clear
> > to me that what everybody would want in this situation is for an
> > MTA to fail over to the secondary MX.
>
> If their MX records are incorrectly configured, their email isn't
> going to go through. Why should other hosts go through heroic hoops
> just to get the mail to them?
Just because the primary MX-pointed host happens to be down does not
make the MX records incorrectly configured. There are scenarios where
MX records should indeed be changed. But there are also scenarios where
the MX records are correct as they stand and the difference cannot be
distinguished from the point of view of the MTA trying to send mail.
> > Should we be giving any consideration to the question of whether, on
> > the average, secondary MXs are less reliable than primary? I don't
> > think we should; I don't think we should warp the implementation to
> > accommodate incorrectly configured systems.
>
> Aren't you doing just that? Right now, qmail works fine for machines
> which are correctly configured but sometimes inaccessible. Various
I would disagree. At least you said "fine" as opposed to "conformant",
opening it to disagreement of opinion, since "fine" is subjective. The
reason I disagree is because of the scenario where it may take three
days or more to correct the problems in the 1st host while the 2nd host
is able to deliver the mail just fine.
> people (not you) are talking about warping the implementation to
> accommodate incorrectly configured systems. There's a ton of
And some are talking about warping it to accomodate situations of
failure that don't repressent a misconfiguration.
> different ways you can configure your system so that email bounces.
> Why should a remote system bother to work around any of them? I mean,
> there's the chance that the SMTP server might be configured with the
> wrong hostname, so the client should strip off the hostname for the
> RCPT TO: lines, right??
I'm not suggesting we bend over backwards, or even bend at all, to
accomodate incorrect configurations. However, I don't want to miss
an opportunity to work around a problem in a correctly configured
setup just because someone else may be able to produce identical
symptoms by means of incorrect configuration. If it happens that
a change intended to work around problems also happens to work around
misconfiguration, who of us will feel bad about that (raise hands)?
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Russell Nelson wrote:
> David Dyer-Bennet writes:
[snip]
> > It doesn't work fine in the scenario I outlined at the beginning of my
> > message. In that situation, the mail will sit on the qmail system
> > until it expires, when there's a perfectly good secondary MX system
> > sitting there waiting to accept it. This is not my definition of
> > "works fine".
>
> Right, but you're suggesting that nobody will notice the lack of
> reception of email for seven days. If they make configuration changes
> without testing them (and I count leaving a down machine down as
> such), and then don't notice that something is broken for a week, then
> I'll wager that they'll be suited just as well without email.
You're suggesting that all incoming mail reaches them by means of qmail
and that sendmail doesn't exist?
If the 1st MX host is down (any scenario, including dying in the middle
of receing SMTP DATA) and the 2nd MX host is up, they may well not notice
anything because there isn't enough problem to notice. And if they do
notice that some mail isn't arriving as expected, they could very easily
be misled to not blame the 1st MX host because most mail is arriving
just fine (via sendmail falling back to the 2nd MX host).
I'm sure the system administrator will notice something wrong when he
gets back from his vacation in Kuala Lampur.
> You're also presuming that they have the ability to read email off the
> "secondary" host. It would be very unusual for a host which functions
> identically to another to be given a lower priority. Much more often,
> the secondary host is one which is configured only to relay mail to
> the primary.
You're presuming that they read email off of either host. They may be
reading it off of an internal mail server on a private address LAN that
only hosts in the DMZ, acting as mail gateways, can reach.
And there is also a valid reason to prefer one server over another to
gateway the mail. If there are 2 servers in the DMZ, functionality may
be split by having one act as the web server and the other act as the
mail server, with failover being the other server. The 2nd MX host
would then be the web server. It would be undesired to put half of
the mail through it when the 1st is running fine and is dedicated to
the purpose.
> > The secondary MX exists to cover cases when the primary is down. It's
> > not an "incorrectly configured" DNS to have a primary MX listed that
> > happens to be down at the moment!
>
> And a firewall which accepts connections for a down host is not
> misconfigured or broken by design??
Such a firewall is broken.
Such a firewall is not the only scenario impacted by not falling back to
the 2nd MX.
Is it more important to punish broken configurations at the expense of
missing an opportunity to work around a problem in a valid configuration?
I know we hate misconfiguration, but is it necessary to be so obsessed
with it?
I'm arguing for the valid configurations, not that broken firewall
scenario. I've pointed out how without such a firewall you can still
have the same exact symptoms and many others like it.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
I have a weird problem here (long mail, I hope everybody understands what
I'm trying to say here...).
my system: qmail 1.03 on Solaris 2.6 (disks under control of disksuite,
mirrored disks are being used).
I saw this afternoon 5000 messages in my queue (most of the mails to one of
my own machines), and the "not yet processed" messages grew till about 500.
I have concurrency set to 120 (the max) but the number of remote processes
never came above an avarage of 10. When I shutdown the smtp part and gave a
alrm to qmail, it started spawning 120 processes, but not all the time:
10->120->90->60->30->30->30->20->120....
Why this falldown to 20 (or something like that)? Why does qmail not
continiously keep 120 qmail-remote processes running?
And from the moment I allowed smtp connections again, the number of
qmail-remote never came above 20 again. I even tried the big-concurrency
patch, but it didn't change anything. For the moment I have 140 messages
"not yet processed" and about 18 qmail-remote processes, with more than 200
messages in the queue to my other machine. Why doesn't it rises to 120 when
I give a alrm signal to qmail? I checked the permissions of
/var/qmail/queue/lock and everything seems ok there.
top and iostat are telling me that I have a big iowait...
Can anybody tell me what I can do to pump up the number of remote processes
so it has a high number all the time when mails are in the queue?
Do I need the big-todo patch (I thought this patch was when you have more
than 1000 messages per subdir, I have about 125 per subdir)?
Please help me!!! It's 10 o'clock in the evening and I'm tired of watching
disk stats and qmail logfiles...
Franky
Hi,
I am new to linux and have recently setup qmail on a Redhat(6.0
kernel-2.2.12) system. I followed the instructions in lwq and the system is
working fine. I use the qmail-pop server, the mail folder used is Maildir
For increased security i have commented out most of the services in
inetd.conf including telnet. I have also setup selective relaying using
Chris Johnson's document. However in the near future i would like to allow
telnet as well as web access. I now need advise on implementing a higher
level of security on the system
Q1. I read somewhere the pop3 clients don't use encrypted passwords, is
there a way to implement increased security in this case ?
Q2. What more do i need to install for increased security under telnet ?
Q3. What more do i need to install for increased security under webaccess?
Which one of the 3 webaccess programs is recommended and does it work with
the pop server?
Thanks for you advise and input,
Vivek
On 9/27/99 at 4:49 PM, [EMAIL PROTECTED] (Joshi, Vivek) wrote:
> Q1. I read somewhere the pop3 clients don't use encrypted passwords, is
> there a way to implement increased security in this case ?
Yes, but you need to make sure the clients can handle the kind of authentication
you want to use.
Check http://www.qmail.org for a number of checkpassword programs.
> Q2. What more do i need to install for increased security under telnet ?
Look into ssh (http://www.ssh.org). Which is far beyond the scope of this
list...
--
Freestyle Interactive | http://www.freestyleinteractive | 415.778.0610
Using Paul Gregg's howto setup Single UID based POP3 boxs.
I can't find what's wrong.
inetd.conf:
#Qmail pop daemon
pop-3 stream tcp nowait root /var/qmail/bin/qmail-popup qmail-popup
mailer.famvi
d.com /var/qmail/bin/checkpoppasswd /var/qmail/bin/qmail-pop3d Maildir &
( I've tried wtih and without the trailing '&', what's that for anyway?
)
My poppasswd entry looks like:
testid:DmIMm9e5Hc8ic:popuser:/var/qmail/popboxes/sadi-com/joe
My testid validates because syslog looks like:
Sep 27 17:31:06 mailer syslog: pop3checkpasswd: POP3 user testid :
/var/qmail/po
pboxes/sadi-com/joe logged in from unknown@ []
and virtual joe's directory looks like:
# l -aR /var/qmail/popboxes/sadi-com/joe
total 2
drwx------ 3 popuser qmail 96 Sep 27 17:40 .
drwx------ 3 popuser qmail 96 Sep 27 14:10 ..
-rw------- 1 popuser qmail 11 Sep 27 16:43 .qmail
drwx------ 2 popuser qmail 96 Sep 27 16:44 Maildir
/var/qmail/popboxes/sadi-com/joe/Maildir:
total 0
drwx------ 2 popuser qmail 96 Sep 27 16:44 .
drwx------ 3 popuser qmail 96 Sep 27 17:40 ..
#
This is also SCO Unixware 7.0.1 should that matter.
I hope I'm missing the obvious. Does someone else see a problem?
Thanks in advance,
Bill
On 9/27/99 at 5:55 PM, [EMAIL PROTECTED] (Bill Rogers) wrote:
>
> /var/qmail/popboxes/sadi-com/joe/Maildir:
> total 0
> drwx------ 2 popuser qmail 96 Sep 27 16:44 .
> drwx------ 3 popuser qmail 96 Sep 27 17:40 ..
> #
I think your Maildir has something wrong with it. Did you use
/var/qmail/bin/maildirmake to create the Maildir? You should see three folders
inside (cur, new, tmp).
Pat
--
Freestyle Interactive | http://www.freestyleinteractive | 415.778.0610
I find it hard to believe that I am getting mail bombed from
petopia.com but the logs show:
[root@mail log]# grep 216.33.225.124 maillog -c
195494
Sep 26 11:58:14 mail qmail-smptd: 938361494.243103 tcpserver: pid 2649 num
0 from 216.33.225.124
Sep 26 11:58:14 mail qmail-smptd: 938361494.253880 tcpserver: ok 2649
mail.f-tech.net:207.44.65.16:25 :216.33.225.124::1334
Sep 26 11:58:14 mail qmail-smptd: 938361494.775457 tcpserver: end 2649
status 256
Are there any known problema with tcpserver looping???
Paul Farber
Farber Technology
[EMAIL PROTECTED]
Ph 570-628-5303
Fax 570-628-5545
On Mon, Sep 27, 1999 at 07:01:34PM -0400, [EMAIL PROTECTED] wrote:
> I find it hard to believe that I am getting mail bombed from
> petopia.com but the logs show:
>
> [root@mail log]# grep 216.33.225.124 maillog -c
> 195494
>
> Sep 26 11:58:14 mail qmail-smptd: 938361494.243103 tcpserver: pid 2649 num
> 0 from 216.33.225.124
> Sep 26 11:58:14 mail qmail-smptd: 938361494.253880 tcpserver: ok 2649
> mail.f-tech.net:207.44.65.16:25 :216.33.225.124::1334
> Sep 26 11:58:14 mail qmail-smptd: 938361494.775457 tcpserver: end 2649
> status 256
>
> Are there any known problema with tcpserver looping???
What do you mean by "looping"?
It appears that 216.33.225.124 is connecting to you repeatedly. I'd bet that
the remote host is trying to send you a message with a bare linefeed,
qmail-smtpd is disconnecting, and then the remote host is connecting again
immediately to try to resend the message. I'd bet a zillion dollars that the
remote host is running a brain-dead Windows MTA.
My suspicions are confirmed:
[cjohnson@mail cjohnson]$ telnet 216.33.225.124 25
Trying 216.33.225.124...
Connected to petweb02.petopia.com.
Escape character is '^]'.
220-petweb02.petopia.com Microsoft SMTP MAIL ready at Mon, 27 Sep 1999 18:08:00 -0700
Version: 5.5.1877.977.9
220 ESMTP spoken here
I'd cut them off with a tcpserver rule.
Chris
Ok cool... the world dosen't hate me.
How can I limit my exposure to this in the future??? I'm sure this has to
have been discussed.... is there an archive / URL?
Paul Farber
Farber Technology
[EMAIL PROTECTED]
Ph 570-628-5303
Fax 570-628-5545
On Mon, 27 Sep 1999, Chris Johnson wrote:
> On Mon, Sep 27, 1999 at 07:01:34PM -0400, [EMAIL PROTECTED] wrote:
> > I find it hard to believe that I am getting mail bombed from
> > petopia.com but the logs show:
> >
> > [root@mail log]# grep 216.33.225.124 maillog -c
> > 195494
> >
> > Sep 26 11:58:14 mail qmail-smptd: 938361494.243103 tcpserver: pid 2649 num
> > 0 from 216.33.225.124
> > Sep 26 11:58:14 mail qmail-smptd: 938361494.253880 tcpserver: ok 2649
> > mail.f-tech.net:207.44.65.16:25 :216.33.225.124::1334
> > Sep 26 11:58:14 mail qmail-smptd: 938361494.775457 tcpserver: end 2649
> > status 256
> >
> > Are there any known problema with tcpserver looping???
>
> What do you mean by "looping"?
>
> It appears that 216.33.225.124 is connecting to you repeatedly. I'd bet that
> the remote host is trying to send you a message with a bare linefeed,
> qmail-smtpd is disconnecting, and then the remote host is connecting again
> immediately to try to resend the message. I'd bet a zillion dollars that the
> remote host is running a brain-dead Windows MTA.
>
> My suspicions are confirmed:
>
> [cjohnson@mail cjohnson]$ telnet 216.33.225.124 25
> Trying 216.33.225.124...
> Connected to petweb02.petopia.com.
> Escape character is '^]'.
> 220-petweb02.petopia.com Microsoft SMTP MAIL ready at Mon, 27 Sep 1999 18:08:00
>-0700 Version: 5.5.1877.977.9
> 220 ESMTP spoken here
>
> I'd cut them off with a tcpserver rule.
>
> Chris
>
[EMAIL PROTECTED] wrote:
> Ok cool... the world dosen't hate me.
> How can I limit my exposure to this in the future???
Use IPLimit (grab it from http://www.jedi.claranet.fr) .
--
Frank DENIS aka Jedi/Sector One aka DJ Chrysalis <[EMAIL PROTECTED]>
-> Software : http://www.jedi.claranet.fr <-
-> Music : http://www.mp3.com/chrysalis <-
Does anybody know how to get a more descriptive error message? Qmail was
working fine until last week and I was installing a imap, horde, imp, and a few
other things and my email broke. I could probably fix it if I had a more
descriptive message.
[root@ecove control]# echo to: griff | /home/qmail/bin/qmail-inject
[root@ecove control]# Sep 27 16:15:41 ecove qmail: 938474141.360884 new msg 55300
Sep 27 16:15:41 ecove qmail: 938474141.361930 info msg 55300: bytes 213 from
<[EMAIL PROTECTED]> qp 1718 uid 0
Sep 27 16:15:41 ecove qmail: 938474141.368037 starting delivery 1: msg 55300 to local
[EMAIL PROTECTED]
Sep 27 16:15:41 ecove qmail: 938474141.368849 status: local 1/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.398040 delivery 1: failure:
Sep 27 16:15:41 ecove qmail: 938474141.398900 status: local 0/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.412215 bounce msg 55300 qp 1721
Sep 27 16:15:41 ecove qmail: 938474141.413598 end msg 55300
Sep 27 16:15:41 ecove qmail: 938474141.416843 new msg 55301
Sep 27 16:15:41 ecove qmail: 938474141.419033 info msg 55301: bytes 717 from <> qp
1721 uid 508
Sep 27 16:15:41 ecove qmail: 938474141.424124 starting delivery 2: msg 55301 to local
[EMAIL PROTECTED]
Sep 27 16:15:41 ecove qmail: 938474141.425095 status: local 1/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.432094 delivery 2: failure:
Sep 27 16:15:41 ecove qmail: 938474141.434123 status: local 0/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.449423 bounce msg 55301 qp 1724
Sep 27 16:15:41 ecove qmail: 938474141.450541 end msg 55301
Sep 27 16:15:41 ecove qmail: 938474141.453395 new msg 55300
Sep 27 16:15:41 ecove qmail: 938474141.454868 info msg 55300: bytes 1135 from <#@[]>
qp 1724 uid 508
Sep 27 16:15:41 ecove qmail: 938474141.459823 starting delivery 3: msg 55300 to local
[EMAIL PROTECTED]
Sep 27 16:15:41 ecove qmail: 938474141.460785 status: local 1/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.467739 delivery 3: failure:
Sep 27 16:15:41 ecove qmail: 938474141.469739 status: local 0/10 remote 0/20
Sep 27 16:15:41 ecove qmail: 938474141.471645 triple bounce: discarding bounce/55300
Sep 27 16:15:41 ecove qmail: 938474141.472760 end msg 55300
--
Senior Internet Engineer Aver, Inc.
(760) 568-4351 Phone (760) 341-8694 Fax
"The world won't change just because I complain."
Martina McBride
Joel Griffiths writes:
> Does anybody know how to get a more descriptive error message? Qmail was
> working fine until last week and I was installing a imap, horde, imp, and a few
> other things and my email broke. I could probably fix it if I had a more
> descriptive message.
You're running a program delivery which is exiting with a non-zero
exit code, but which doesn't print a message.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Hey everyone,
I am having trouble getting tcpserver to behave. I can send from one
local user to another with no problems; it just doesn't want to let my
clients relay and it refuses SMTP connections from the outside world.
The error I get in my syslog is:
Sep 27 19:56:17 portal qmail: tcpserver: warning: dropping connection,
unable to read /etc/tcp.smtp.cdb: input/output error
Sep 27 20:01:02 portal qmail: tcpserver: warning: dropping connection,
unable to read /etc/tcp.smtp.cdb: input/output error
Sep 27 20:27:39 portal qmail: 220 my.server.com ESMTP^M
Sep 27 20:27:39 portal qmail: 938489259.613037 status: local 0/10 remote
0/20
Sep 27 20:27:46 portal qmail: 938489266.139605 status: exiting
Sep 27 20:30:11 portal qmail: 938489411.448918 status: local 0/10 remote
0/20
but I have my tcp.smtp.cdb compiled with the following data (and it IS
in /etc/):
127.0.0.1:allow,RELAYCLIENT=""
xxx.xxx.xxx.xxx-xxx:allow,RELAYCLIENT=""
:allow # <--That SHOULD allow the rest of the world to send me mail
shouldn't it?
I've read allot from the qmail-list and I am NOT going to try to set it
up as an open relay, but I would very much like to allow my client
workstations relay access for pop and, at the very least get allow the
rest of the world to send me mail. Any ideas?
Here's a snippet of my startup script if that will help:
sh -c "start-stop-daemon --start --quiet --user qmails \
--exec /usr/sbin/qmail-send \
--startas /usr/sbin/qmail-start -- \"$alias_empty\"
$logger &"
ulimit -v 2048
#If I run this from the command line, I can telnet to port 25, but that
is from my LAN...
sh -c "start-stop-daemon --start --quiet --user qmaild \
--exec /usr/bin/tcpserver -q -- \
-u 71 -g 65534 -x /etc/tcp.smtp.cdb 0 smtp \ #started:
'-S'
/usr/sbin/qmail-smtpd 2>&1 | logger -t qmail -p mail.notice
&"
# pop3 is obviously having a hard time...
sh -c "start-stop-daemon --start --user qmaild \
--exec /usr/bin/tcpserver -q -- \
0 pop-3 /usr/sbin/qmail-popup `hostname`.`dnsdomainname` \
/usr/bin/checkpassword /usr/sbin/qmail-pop3d Maildir &"
Many thanks to anyone who can help,
Ryan Sharon
[EMAIL PROTECTED]
Odd thing, this: of all my qmail users, only one can't get her mail. The
syslog shows the message being sent for delivery with the error message:
"unable_to_chdir_to_maildir_(#4.2.2)/"
I'm using Maildir delivery for all the users, all with the same $HOME
dir setup (ie. Maildir and .qmail file per qmail docs) and everyone
else's works.
What's wrong here?
Thanks,
Barry
Did you check the file permission?
Qmail is pretty picky about permission for a good reason.
The error complains about the fact that Qmail is not able to "chdir" -> go
into the directory.
This is usually the case if the permission a screwed up.
Another good catch is that it works with everyones else, but not with one
use.
Thus I blieve this one user has either permission problems, or the directory
does not exists at all ;-)
Cheers,
Andre
------------------------------------------------------
ICQ#: 1339921
Home: http://anneck.de
----- Original Message -----
From: Barry Dwyer <[EMAIL PROTECTED]>
To: qmail list <[EMAIL PROTECTED]>
Sent: Tuesday, September 28, 1999 8:45 AM
Subject: One user can't get her mail
> Odd thing, this: of all my qmail users, only one can't get her mail. The
> syslog shows the message being sent for delivery with the error message:
>
> "unable_to_chdir_to_maildir_(#4.2.2)/"
>
> I'm using Maildir delivery for all the users, all with the same $HOME
> dir setup (ie. Maildir and .qmail file per qmail docs) and everyone
> else's works.
>
> What's wrong here?
>
> Thanks,
> Barry
>
>
Hi there folks,
i tried to use recordio to log every SMTP-Actions, but there seems to
be no logging ..
My startup-line :
# smptp
supervise /var/lock/qmail-smtpd tcpserver -c400 -v -x/etc/tcp.smtp.cdb
-u$USERID -g$GROUPID 0 25 \
rblsmtpd -r rbl.maps.vix.com rblsmtpd -r dul.maps.vix.com recordio
qmail-smtpd 2>&1 | setuser qmaill accustamp | \
setuser qmaill cyclog -s5000000 -n5 /var/log/qmail/qmail-smtpd &
It would be great if i could log every SMTP-command to a seperate log
file, e.g. smtp.log and still have
my qmail-smtp log !
Thanks a lot !
Thomas
Hello,
I have qmail installed, but I have two problems:
1) I install the Maildir in all my users home dir, but the
mail is not stored in that dir, and I don't now where the mail is stored (note:
I change ./Mailbox to ./Maildir/ in rc file, and I can't retrieve the new
mail).
2) I can't send mail via smtp from another host in my network(
or outside my network), but I can connect via pop3. (note: I put the qmail-smtp
and qmail-pop3 in the inetd file).
Tia,
Jorge Mota
Sociedade Torreense de Informática,
Lda.
Av. Tenente Valadim 10 C
2560 Torres Vedras
Tel:351 61 316245
Fax:351 61 316239
|
