qmail Digest 23 Jul 2000 10:00:01 -0000 Issue 1071
Topics (messages 45269 through 45348):
Re: orbs.org accuses qmail of mailbomb relaying!
45269 by: Michael T. Babcock
45270 by: Michael T. Babcock
45271 by: Michael T. Babcock
45272 by: Michael T. Babcock
45273 by: Michael T. Babcock
45274 by: Michael T. Babcock
45275 by: Michael T. Babcock
45276 by: Michael T. Babcock
45278 by: Michael T. Babcock
45279 by: Russell Nelson
45280 by: Russell Nelson
45281 by: Russell Nelson
45285 by: Peter van Dijk
45294 by: Pavel Kankovsky
45297 by: Michael T. Babcock
45298 by: Michael T. Babcock
45307 by: John White
45312 by: Michael T. Babcock
45313 by: Peter van Dijk
45314 by: Michael T. Babcock
45319 by: Russ Allbery
45320 by: Michael T. Babcock
45321 by: Russ Allbery
45324 by: Eric Cox
45329 by: Joe Kelsey
45331 by: Joe Kelsey
45336 by: David Dyer-Bennet
45338 by: David Dyer-Bennet
45339 by: David Dyer-Bennet
45340 by: Russ Allbery
45344 by: Adam McKenna
45346 by: Eric Cox
45348 by: Russ Allbery
Attitude
45277 by: Michael T. Babcock
45289 by: markd.bushwire.net
45337 by: David Dyer-Bennet
45345 by: Adam McKenna
Duplicate Msgs
45282 by: Sumith Ail
Re: qmqpc load balancing
45283 by: Russell Nelson
45311 by: Michael T. Babcock
45333 by: Austad, Jay
Yet another /var/spool/mail questions
45284 by: David Bouw
"Filters have been made for Sendmail and Postfix to deal with this issue" : and qmail
???
45286 by: Olivier M.
45291 by: asantos
45292 by: Olivier M.
45293 by: asantos
45342 by: Bruce Guenter
45343 by: Bruce Guenter
some broken mailer [[EMAIL PROTECTED]: Returned mail: User unknown]
45287 by: Peter van Dijk
another broken mailer [[EMAIL PROTECTED]: Returned Mail: user
[EMAIL PROTECTED] unknown!]
45288 by: Peter van Dijk
45296 by: Aaron L. Meehan
45316 by: Michael T. Babcock
Re: another broken mailer
45290 by: asantos
Want to know your potential multiple recipient savings?
45295 by: markd.bushwire.net
45341 by: Bruce Guenter
Re: Unable to send a huge file
45299 by: Michael T. Babcock
Re: Permissions Dilemma?
45300 by: Michael T. Babcock
Re: [spam score 2.14/10.0 -pobox] qmqpc load balancing
45301 by: Michael T. Babcock
Re: minifaq
45302 by: Michael T. Babcock
Re: remote load management, was orbs.org nonsense
45303 by: John R. Levine
45318 by: Michael T. Babcock
procmail preline acting like a local user
45304 by: Jeff Gray
Re: Data in exel to Vpopmail
45305 by: Michael T. Babcock
45306 by: John R. Levine
Re: procmail preline acting like a local user (fwd)
45308 by: Jeff Gray
Re: Returned mail: User unknown]
45309 by: Michael T. Babcock
Re: Alan @ ORBS
45310 by: Michael T. Babcock
Re: procmail preline acting like a local user - again, sorry
45315 by: Jeff Gray
45322 by: asantos
45330 by: Jeff Gray
Re: another broken mailer - #2
45317 by: Michael T. Babcock
qmail: cannot mail to root
45323 by: jandeluyck.gmx.net
45325 by: John L. Fjellstad
45326 by: wolfgang zeikat
45327 by: jandeluyck.gmx.net
45328 by: Ricardo Cerqueira
Re: pop3 outgoing config issue
45332 by: Charles Cazabon
Re: qmail died again... 3x in 3 weeks
45334 by: Eric Cox
pop3 won't die
45335 by: Jeff Jones
Re: problem with virtual user
45347 by: Eric Cox
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
If I say 'sendmail', you'll say 'see, you should've used qmail' ... but I'll
say 'and how many other sites are using sendmail that will appreciate it?'.
Just telll me the first time someone finds a really cool porn AVI on some
site and E-mails it to all of his collegues at a different office and the 25
or 30 copies all show up in parallel to the remote site.
PS, 2 months ago.
Petr Novotny wrote:
> On 21 Jul 00, at 11:17, Michael T. Babcock wrote:
>
> > > While you ponder the answer to those questions, qmail will have
> > > delivered the mail.
> >
> > Or crashed a mailserver.
>
> Please stop that. When was the last time you saw a crashed
> mailserver due to getting too many mails? And what was the
> software?
John White wrote:
> On Fri, Jul 21, 2000 at 11:20:00AM -0400, Michael T. Babcock wrote:
> > No, but if qmail is making the deliveries to another MTA, that MTA doesn't
> > have much choice about whether its going to accept deliveries from Qmail or
> > not, so why not make Qmail a nice neighbour while we're at it?
>
> > There's nothing wrong with using intelligent queuing to reorder messages and
> > reduce session #'s.
>
> Sure there is. It creates overhead.
So does opening simultaneous connections -- in the kernel, just not in
user-space. Silly argument. SCSI command queues with reordering and elevator
sorting add a lot of overhead ... and happen to increase performance
dramatically. There are trade-offs in writing software. I'm not saying my way is
perfect. I'm saying I think I have valid concerns (that others on this list have
also stated) and they shouldn't be written off with 'it creates overhead'.
> > If just getting the mail out FAST is all that matters,
> > fine. But that's NOT all that matters.
>
> To be blunt, I don't mind taking a look at the code changes you're
> proposing. Where are they?
(Sarcasm:) What, you don't know how to code?
I'm sick of that response. If I'm a part of three different OSS projects and work
60 hours a week for a living on top of that, am I expected to give you a
demonstration of my thoughts in code just so you can say they suck? If I had the
time to write my modifications, I wouldn't propose them. I'd have written them,
posted the patch and let everyone who agrees with me just use it (like other
patches at qmail.org that aren't in the distro).
I don't have that time, so I gave my observations and opinions instead for the
sake of intelligent discussion. Ideas are equally valuable to working solutions.
The latter usually doesn't appear without the former.
I'd love to. Read my previous message.
If I see some discussion about it, and enough people are actually interested, I
may end up investing enough time to get this off the ground. I may not. I have
four other pieces of software to write (from scratch) over the next week.
John White wrote:
> That's nice. Where's your implementation? I don't mind testing your
> patches to qmail if you'll send them to me.
Incidentally, is there a discussion in the past that I've missed about 'void
main' declarations? :-)
To help you out with that comment:
http://web.infoave.net/~dsill/lwq.html#multi-rcpt
I'm not sure if that's the best discussion on the issue, but its there
(that section and the next).
The quick version is:
VERP was proposed by DJB as a way to identify bounce recipients. VERP
requires that each recipient have their own From: as well as To:. Being
able to identify bouncing addresses is important on large mailing lists.
There are scenarios, however, that are ignored by the original thinkers,
I believe.
For instance, multiple MTAs for one organisation that handle different
protocols for speed of queuing, etc. (SMTP on one machine, POP3 on
another). If the MTA is used for internal domain traffic (in one case I
administer, 97% or so is internal), the message-splitting can be a
definate aggrevation.
Now, the page above mentions that changing the delivery method would
require a lot of work. Because of that, this discussion will probably
end up going nowhere eventually, but having the opinions of many out in
the open is 'a good thing'. That said, it would be wonderful for those
of us who feel it to be a good idea, to have the delivery system offer
the option of either "always massively parallel" ;-) or "limited" (by
adding a value to 'control/maxsmtpsessions' or something -- with queuing
as I proposed) or "multi recipient" ... the way that destroys VERP.
At any rate, I'm going to see if I can grab some stats on the types of
messages I'm speaking of off a few servers and put some stats together.
(PS, its been an interesting clash here ... nice to have a list full of
severely opinionated people) :)
Paul Jarc wrote:
> Mark Mentovai <[EMAIL PROTECTED]> writes:
> > If an MTA receives a message with 100 recipients with the same MX,
> > there is no reason to transfer the message to the remote mail
> > exchanger 100 times.
>
> Yes, there is: per-recipient VERPs. You may not see this as
> outweighing the bandwidth issue, but it's still a reason in favor of
> individual transfers, given the limits of SMTP.
[EMAIL PROTECTED] wrote:
> I'm not really going to re-enter this recurring fray, but it is
> amusing to note that web browsers open multiple connections at once
> in an effort to speed up their perceived performance. I don't see
> much push to stop that sort of greedy behaviour.
I do. HTTP 1.1 was proposed as a way to send all that data down a single
TCP link instead of opening a new connection for each object. HTTP 1.1
browsers may still open multiple links, but those links are "reused" not
opened and closed, to avoid the SYN, etc. overhead inherent in TCP. This
was well studied and put into practice.
> They also repeatedly fetch exactly the same data. Does anyone
> care to calculate how many times the exact same stream of bits, let's
> say the home page of amazon.com, has been sent down their connection
> over the last six months?
Yes. Read up on http://www.squid-cache.org/ ... a lot of major ISPs and
organisations run caching proxy servers, etc. to eliminate undue
bandwidth use. In house, we have a 25% hit rate on HTTP use.
> A greedy ant maybe, but rarely relevant compared to that
> 800lb gorilla/hydra combo, we call web-browsing.
And web browsing technology has changed to help ... now it might be 'our'
turn.
> As others have repeatedly said, if you're in that rare situation that
> demands something different, use it, or write it. qmail was never
> designed to meet every requirement out their and the author has made
> it abundantly clear which ones are important to him.
Understood.
I would be really interested in seeing those numbers in the FAQ somewhere ...
Charles Cazabon wrote:
> A few people have done the math; MTAs which aggregate recipients to save
> bandwidth tend to have more overhead network bandwith (additional MX lookups,
> etc), and the savings is not as great as a first guess might make it look.
> It has to be a pretty pathological case (large mail, many recipients at
> one MX) for it to be consistently faster.
Ok then, on an honest note, the point would then be to have an MTA regulate its
incoming connections in an 'intelligent' manner so as to allow mail to actually
get through from non-qmail MTAs within a reasonable time frame? If I allow 20
simultaneous connections (hypothetically) and mail is delivered from 5 different
hosts at once, two of which are running qmail with mailing lists, odds are that
the other three hosts won't be able to connect and may bounce the message back
to the sender because the qmail sites used all my connections.
Is this correct?
Jon Rust wrote:
> > To be friendly to your neighbours ...
>
> Why is the onus on qmail here? If I'm an MTA dropping off mail to
> another MTA, I'm going to send the mail as fast as the other MTA accepts
> it. If Other MTA needs to slow it down, it should do so. There's no
> reason for me to make assumptions about how many SMTP connections and
> messages I can send to another MTA.
David Dyer-Bennet wrote:
> > I would have to agree with the multiple connections == bad neighbour behaviour
> > (if this is true).
> >
> > I might encourage re-ordering of sends to have parallel, per-MX queues ...
>
> This is very hard to do, and expensive. And it would slow down mail
> delivery, both overall and to each destination. And it would increase
> disk IO. Why would one want to do this?
I said why. I just wanted to have the concept evaluated outside the 'its simply a
stupid
idea' crowd if at all possible.
3) Opening M connections (where M < N) and sending the messages down those M
pipes without marking the message as having gone through a "could not connect to
mail server" situation but queuing it for that MX instead.
??
Dave Sill wrote:
> Mark Mentovai <[EMAIL PROTECTED]> wrote:
>
> >Why not? You can have your cake and eat it too. Efficient network
> >utilization doesn't mean delayed or slow delivery.
>
> Say you have 100 different messages to deliver to various users at
> AOL. Which will be faster:
>
> 1) Opening one connection to a single AOL MX and feeding them through
> single-file, or
>
> 2) Opening N connections to M AOL MX's and feeding one message to
> each?
>
> Answer: 2
Greg Owen writes:
> No, ORBS is talking about a different thing.
>
> If I want to mailbomb foo.com, and bar.com is running qmail, then I
> can connect to bar.com's mail and say:
No you can't, not like that. Try it.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Tornadoes, earthquakes,
521 Pleasant Valley Rd. | +1 315 268 1925 voice | hurricanes and government:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | uncontrollable forces
Greg Owen writes:
> Yup. If you have one qmail box forwarding to a second qmail box
> which is the mail store, you get this amplification.
No, you don't get any amplification. You only get amplification if
you can get someone else's machine to expend resources that you
didn't. Yes, you can get one message to expand into N, but you have
to send those N messages yourself. The only effect you get by forging
the envelope sender and using a bouncing envelope recipient is that
the attack comes from many hosts instead of just yours. But any MTA
will do that, not just email.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Tornadoes, earthquakes,
521 Pleasant Valley Rd. | +1 315 268 1925 voice | hurricanes and government:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | uncontrollable forces
Philip, Tim (CNBC Asia) writes:
> orbs.org recently tested our qmail server, I mailed them and they advised
> that our server could be used as a "proxy mailbomb relay". By this they
> mean that a message with a forged FROM: address and multiple bad
> RCPT TO: addresses will generate multiple non-delivery reports being
> sent to the forged FROM: address. Is it possible to stop this?
No. It's an artifact of the SMTP protocol. Anybody who claims that
qmail will do this but sendmail will not is just blowing smoke.
> ------------ HERE IS WHAT ORBS.ORG SAID ABOUT QMAIL: ------------
>
> Kick Qmail's author.
Alan is the south end of a horse going north. Given the way he runs
orbs.org and the accusations he makes of people, I'm amazed that
anyone uses ORBS.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Tornadoes, earthquakes,
521 Pleasant Valley Rd. | +1 315 268 1925 voice | hurricanes and government:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | uncontrollable forces
On Sat, Jul 22, 2000 at 08:32:24AM -0400, Michael T. Babcock wrote:
> Ok then, on an honest note, the point would then be to have an MTA regulate its
> incoming connections in an 'intelligent' manner so as to allow mail to actually
> get through from non-qmail MTAs within a reasonable time frame? If I allow 20
> simultaneous connections (hypothetically) and mail is delivered from 5 different
> hosts at once, two of which are running qmail with mailing lists, odds are that
> the other three hosts won't be able to connect and may bounce the message back
> to the sender because the qmail sites used all my connections.
Ofcourse not. A 'connection refused' will not cause a bounce unless some
involved software is *severly* broken.
Also, the other hosts will get into the connection-backlog and get their
turn. That's the beauty of qmail using one connection per message - message
done, connection closed, next in connection queue gets it's turn. A qmail
box delivering to another qmail box will never chew up all it's incoming
connections for a long time, they will nicely rotate. A sendmail box *is*
able to cause that DoS.
Greetz, Peter.
--
[EMAIL PROTECTED] - Peter van Dijk [student:developer:ircoper]
On Fri, 21 Jul 2000, Petr Novotny wrote:
> I really suggest you to sift through the archives first. My MTA really
> does faster, even in this situation: The round-trip times around here
> are too long. The less round-trips, the faster the mail gets through.
> Easy as that.
Hmm...RSET needs one roundtrip (C: RSET, S: OK). A new SMTP connection
needs 3 roundtrips: 1. C:TCP(SYN), S:TCP(SYN+ACK), 2. C:TCP(ACK), S:server
hello, 3. C:HELO, S:OK. Moreover a typical TCP implementation will open
every new connection with most parameters (such as rtt, window, mtu) set
to some default values and it takes a while to adjust them. Your claim
(less roundtrips, better performance) is at least misleading...what is
meant by "roundtrips" in that context anyway?
The real reasons why qmail-style multiple connections are very likely to
outperform sendmail-or-whatever-style single connections are:
(Please note that the following explanations are intentionally
simplified for the sake of clarity and brevity.)
1. There are several "synchronization points" per one SMTP transaction,
let's say N (e.g. N=7 for qmail-remote and a server without pipelining:
TCP(SYN) & TCP(SYN+ACK), TCP(ACK) & server hello, HELO, MAIL, RCPT, DATA,
end of DATA (".")). At each of those points, there is one roundtrip wait
on the client's side. Let's say an average roundtrip is R seconds long,
the link can transmit B bytes per second, the client needs to transmit M
bytes per message and the traffic from the server to the client is
negligible. This means an average SMTP transaction is M/B + NR seconds
long, and an average link utilization during a single transaction is
U = M / (M + NRB). It is obvious that U < 1. If U << 1, the client spends
more of its time waiting for the server's responses than sending data. In
such a case, the performance grows less or more linearly with the number
of simultaneously running clients, as does the link utilization. Up to a
point: when the link is saturated, the performance cannot grow anymore,
and it even decreases gradually due to the congestion-induced overhead and
increased per-message latencies.
2. Even when the link is congested, it might still be possible to
increase the amount of data you send...if there are other users using the
link you can steal some bandwidth from them. Let's assume the link can
transmit B bytes per second and the router on its end receives Y b/s
to be transmitted from you and O b/s from other users. A typical Internet
router will transmit a less or more randomly chosen set of cca. B incoming
bytes per second and drop the rest, i.e approx. Y / (Y + O) of the
bandwith will be allocated to you, and O / (Y + O) to others. If O remains
fixed and Y grows, Y / (Y + O) grows as well. This is similar to the
"communistic" behaviour of the traditional unix CPU scheduler: the more
processes you run, the more CPU time you get...at the other user's
expense. Today, it pays off to be aggressive (OTOH, I am not sure it
will pay off tomorrow in the more QoS-aware Internet).
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
If, however, you admit that it causes problems for sendmail installations, and
you admit that a lot of sites use sendmail, then you'll probably agree that
defining "good netizen" would include "limiting outgoing connections to a
particular MX" ... to some reasonable number (heck, you can detect what the
foreign MTA is when you connect usually ... )
Adam McKenna wrote:
> What it does is make sendmail look bad. qmail can easily handle a flood of
> incoming connections (if it is being run through tcpserver). It will coolly
> defer all incoming connections until a slot opens up. IMHO this is an
> important feature, and the fact that sendmail doesn't handle incoming
> connections as gracefully is not an excuse to bash qmail.
You've just missed a point of Qmail though. If a major point of Qmail's existence is
to provide reliable E-mail delivery, then this _must_ include cooperating with other
MTAs (without violating standards) at least enough to keep from crashing / giving
them headaches so that we don't 'encourage' them to lose mail ... (through failures
of their own).
If we're the 'intelligent' ones and the secure ones, we should probably be working
around their failures where we can, to keep _mail_ secure, not just mail on Qmail
servers.
Adam McKenna wrote:
> On Fri, Jul 21, 2000 at 11:17:32AM -0400, Michael T. Babcock wrote:
> > And DJB has already proposed other protocol solutions that don't handle this
> > issue either. That said, your comment is moot. SMTP has lots of problems, why
> > _not_ solve them?
>
> This isn't a problem with SMTP -- It's a problem with MTA's that don't handle
> lots of incoming connections very well. The fact that a majority of people
> on the Internet are running such MTA's is not a concern of mine and it
> shouldn't be a concern of Dan's. If they want better connection handling,
> they should either request the feature in sendmail or upgrade to something
> better.
>
> --Adam
On Sat, Jul 22, 2000 at 08:07:11AM -0400, Michael T. Babcock wrote:
> John White wrote:
>
> > To be blunt, I don't mind taking a look at the code changes you're
> > proposing. Where are they?
>
> (Sarcasm:) What, you don't know how to code?
No, but I'm skeptical about ideas that are so good that someone
else should code them.
John
I understand the point you're correcting (of mine) but I would like a clarification on
Qmail's behaviour when a given message is about to be delivered and the foreign host
refuses the connection because it has too many incoming sessions open.
Peter van Dijk wrote:
> Also, the other hosts will get into the connection-backlog and get their
> turn. That's the beauty of qmail using one connection per message - message
> done, connection closed, next in connection queue gets it's turn. A qmail
> box delivering to another qmail box will never chew up all it's incoming
> connections for a long time, they will nicely rotate. A sendmail box *is*
> able to cause that DoS.
On Sat, Jul 22, 2000 at 04:58:04PM -0400, Michael T. Babcock wrote:
> I understand the point you're correcting (of mine) but I would like a clarification
>on
> Qmail's behaviour when a given message is about to be delivered and the foreign host
> refuses the connection because it has too many incoming sessions open.
It tries again later. Only if after 7 days (by default) it bounces because
it has been trying too long.
Greetz, Peter.
--
[EMAIL PROTECTED] - Peter van Dijk [student:developer:ircoper]
Well written.
Pavel Kankovsky wrote:
> Hmm...RSET needs one roundtrip (C: RSET, S: OK). A new SMTP connection
> needs 3 roundtrips: 1. C:TCP(SYN), S:TCP(SYN+ACK), 2. C:TCP(ACK), S:server
> hello, 3. C:HELO, S:OK. Moreover a typical TCP implementation will open
> every new connection with most parameters (such as rtt, window, mtu) set
> to some default values and it takes a while to adjust them. Your claim
> (less roundtrips, better performance) is at least misleading...what is
> meant by "roundtrips" in that context anyway?
And I'm very glad you brought up "round trips" because I'm getting the feeling
that not very many people are considering how TCP works in an IP context vs.
how SMTP works over TCP. That is to say, you gain quite a bit initially by
opening parallel TCP connections, but opening them in sequence (closing one,
opening a new one) is inherently expensive. Cutting down the number of
open+closes is a 'good thing'.
> The real reasons why qmail-style multiple connections are very likely to
> outperform sendmail-or-whatever-style single connections are:
Comments given once ... read them in the list archives ... cut for brevity.
> This is similar to the
> "communistic" behaviour of the traditional unix CPU scheduler: the more
> processes you run, the more CPU time you get...at the other user's
> expense. Today, it pays off to be aggressive (OTOH, I am not sure it
> will pay off tomorrow in the more QoS-aware Internet).
QoS is something I spend quite a bit of time working with, especially with VPN
links I'm running and trying to make the most of clients' access bandwidth when
running multiple 56k analog modems (2 or 3 aggregate).
Michael T Babcock <[EMAIL PROTECTED]> writes:
> If, however, you admit that it causes problems for sendmail
> installations, and you admit that a lot of sites use sendmail, then
> you'll probably agree that defining "good netizen" would include
> "limiting outgoing connections to a particular MX" ... to some
> reasonable number (heck, you can detect what the foreign MTA is when you
> connect usually ... )
This is all nice and good in theory, but you should be aware that you're
going down a rathole with this particular discussion. The only person
who's going to be able to modify this behavior of qmail and make it stick
is Dan, Dan has heard all of these arguments before, and so far he doesn't
seem to be buying it. You're rather far from making any *new* arguments
here, regardless of whether any of the rest of us find them persuasive or
not.
If you really want to have separate queues and streaming of mail through a
single connection per peer rather than qmail's behavior, you may seriously
want to consider using Postfix instead of qmail. I personally prefer
qmail, but trying to use a software package against the express design
intention of its primary author is rather like banging one's head
repeatedly against a brick wall.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Considering the number of useful patches that aren't part of the qmail
distribution that the average qmail admin seems to be using, I disagree.
Russ Allbery wrote:
> If you really want to have separate queues and streaming of mail through a
> single connection per peer rather than qmail's behavior, you may seriously
> want to consider using Postfix instead of qmail. I personally prefer
> qmail, but trying to use a software package against the express design
> intention of its primary author is rather like banging one's head
> repeatedly against a brick wall.
Michael T Babcock <[EMAIL PROTECTED]> writes:
> Considering the number of useful patches that aren't part of the qmail
> distribution that the average qmail admin seems to be using, I disagree.
I disagree with the contention that the *average* qmail admin is using any
patches at all, if by average you mean the mode, and possibly even the
median.
I'm running qmail on a half-dozen different machines and I've never used a
third-party patch to qmail for anything. I've never needed to.
If your qmail installation is dependent on patches not written by Dan, I
will echo my same recommendation: Seriously consider using another MTA.
My opinion as a system administrator is that attempting to use and support
packages plus third-party patches not blessed by the package maintainer is
a recipe for disaster. With all due respect to the qmail-ldap people, for
example, I'd be much more confident in Postfix's LDAP support because it's
part of the main distribution.
I'd make an exception for ezmlm-idx, given that Dan has all but blessed it
as a good third-party product to use for people doing more than
non-trivial mailing lists, but last I'd heard, he was rather annoyed at
the qmail patches, not welcoming them. That means that he's likely to be
willing to break them without giving them a second thought in later
releases, whereas he may work closer with the ezmlm-idx folks if he
releases a new version of ezmlm.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
"Michael T. Babcock" wrote:
>
> You've just missed a point of Qmail though. If a major point of Qmail's existence is
> to provide reliable E-mail delivery, then this _must_ include cooperating with other
> MTAs (without violating standards) at least enough to keep from crashing / giving
> them headaches so that we don't 'encourage' them to lose mail ... (through failures
> of their own).
As long as qmail is going to be expected to handle connection-management
for remote MTAs, shouldn't we also handle security on the client, rather
than the server, as well?
In my view, if an MTA crashes, for any reason, it's the MTA's fault - no
discussion about it. Doesn't matter how many connections were opened to
it, or how fast. If it can't handle more connections, it should start
refusing them, period.
Another point is that if qmail "fixes" this "problem", it leaves the
flawed MTAs alone to be crashed by a attacker - they need not fix their
connection-management problems - they're left in, silently waiting for
and attacker to exploit.
Eric
Michael T. Babcock writes:
> You've just missed a point of Qmail though. If a major point of
> Qmail's existence is to provide reliable E-mail delivery, then this
> _must_ include cooperating with other MTAs (without violating
> standards) at least enough to keep from crashing / giving them
> headaches so that we don't 'encourage' them to lose mail ... (through
> failures of their own).
You *REALLY* don't understand the point of Qmail. Qmail is designed to
be standards compliant, fast, reliable and secure. Your belief seems to
be that the designer of Qmail only cared about reliability. That is
demonstrably false, by DJB's own admission.
Nothing in the design or implementation of Qmail was there ever
consideration given to causing or preventing broken implementations of
SMTP from crashing. They are broken, therefore they *should* crash.
> If we're the 'intelligent' ones and the secure ones, we should
> probably be working around their failures where we can, to keep
> _mail_ secure, not just mail on Qmail servers.
Now you have gone and changed the subject to secure e-mail. There is no
such thing in the defined SMTP protocol. Security is an add-on and has
nothing to do with Qmail.
/Joe
Russ Allbery writes:
> Michael T Babcock <[EMAIL PROTECTED]> writes:
>
> > Considering the number of useful patches that aren't part of the qmail
> > distribution that the average qmail admin seems to be using, I disagree.
>
> I disagree with the contention that the *average* qmail admin is using any
> patches at all, if by average you mean the mode, and possibly even the
> median.
I agree with Russ. I have never felt the need to install or even
consider a patch to the main Qmail code. I feel that there is a small
minority of list members who cannot resist trying every third-party
patch that comes along without understanding how it will *break* Qmail.
Then they complain about broken behavior caused by ill-considered
patches.
/Joe
Michael T. Babcock <[EMAIL PROTECTED]> writes on 22 July 2000 at 08:32:24
-0400
> Ok then, on an honest note, the point would then be to have an MTA regulate its
> incoming connections in an 'intelligent' manner so as to allow mail to actually
> get through from non-qmail MTAs within a reasonable time frame? If I allow 20
> simultaneous connections (hypothetically) and mail is delivered from 5 different
> hosts at once, two of which are running qmail with mailing lists, odds are that
> the other three hosts won't be able to connect and may bounce the message back
> to the sender because the qmail sites used all my connections.
>
> Is this correct?
Certainly not! The sender should simply back off and try again later
-- what they all do now if they fail to connect on the first try, in
fact.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
Russell Nelson <[EMAIL PROTECTED]> writes on 22 July 2000 at 09:15:45 -0400
> Alan is the south end of a horse going north. Given the way he runs
> orbs.org and the accusations he makes of people, I'm amazed that
> anyone uses ORBS.
I'm really annoyed at the degree of uncivility that's developed in the
spam-fighting community. I'm running selected spams through spamcop
(more curious about their analysis than anything else), and nearly
everything reaching me is marked as already blocked by ORBS. It's not
blocked by RBL or RSS, unfortunately, so it's still reaching me. And
either ORBS is blowing *amazing* clouds of smoke or MAPS is really
putting the boot in in their private way, in ways I can't approve of.
Ugly all around.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
Joe Kelsey <[EMAIL PROTECTED]> writes on 22 July 2000 at 16:03:00 -0700
> Russ Allbery writes:
> > Michael T Babcock <[EMAIL PROTECTED]> writes:
> >
> > > Considering the number of useful patches that aren't part of the qmail
> > > distribution that the average qmail admin seems to be using, I disagree.
> >
> > I disagree with the contention that the *average* qmail admin is using any
> > patches at all, if by average you mean the mode, and possibly even the
> > median.
>
> I agree with Russ. I have never felt the need to install or even
> consider a patch to the main Qmail code. I feel that there is a small
> minority of list members who cannot resist trying every third-party
> patch that comes along without understanding how it will *break* Qmail.
> Then they complain about broken behavior caused by ill-considered
> patches.
I'm running the big-todo on one system, though I'm not sure it's
really necessary there; I'm quite sure it is for people with more
volume. And the verh patch is definitely needed for anybody doing
mailing lists seriously.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
David Dyer-Bennet <[EMAIL PROTECTED]> writes:
> And either ORBS is blowing *amazing* clouds of smoke or MAPS is really
> putting the boot in in their private way, in ways I can't approve of.
ORBS is blowing *amazing* clouds of smoke. Either that, or Alan Brown has
literally no clue whatsoever how Internet routing works. This is one of
the things that's rather annoying those of us who have heard a lot of the
story from various sides.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
On Sat, Jul 22, 2000 at 04:18:21PM -0400, Michael T. Babcock wrote:
> You've just missed a point of Qmail though. If a major point of Qmail's existence is
> to provide reliable E-mail delivery, then this _must_ include cooperating with other
> MTAs (without violating standards) at least enough to keep from crashing / giving
> them headaches so that we don't 'encourage' them to lose mail ... (through failures
> of their own).
Sorry, but no.
Reliability is preserved. If the remote mailer is not available, for
whatever reason, qmail will queue the mail and retry again later.
--Adam
Russ Allbery wrote:
>
> David Dyer-Bennet <[EMAIL PROTECTED]> writes:
>
> > And either ORBS is blowing *amazing* clouds of smoke or MAPS is really
> > putting the boot in in their private way, in ways I can't approve of.
>
> ORBS is blowing *amazing* clouds of smoke. Either that, or Alan Brown has
> literally no clue whatsoever how Internet routing works. This is one of
> the things that's rather annoying those of us who have heard a lot of the
> story from various sides.
Hi Russ!
I can't comment on this latest battle of wills between MAPS and
ORBS, because I know nothing of BGP routing. But in the last one,
when ORBS listed in the RBL, ORBS was totally in the right. I saw
grown men, (admins!) trying to defend the position that by ORBS
sending up to 16 messages through their servers a few times a _year_,
ORBS was abusing the email system. Mind you, these were servers
that relayed 200K to a million messages a day - the ORBS tests
amounted to a tiny fraction a of fraction of the spam it would
have prevented.
And, as a result of above.net blocking ORBS, I find myself having
to play whack-a-mole with spammers within above.net more and more
each week - just reported one yesterday.
I suppose neither side is right, they're both being very childish
about all this.
(My apologies to the list for keeping this OT thread going - I'll
shut up now)
Eric
Eric Cox <[EMAIL PROTECTED]> writes:
> I can't comment on this latest battle of wills between MAPS and ORBS,
> because I know nothing of BGP routing.
Short version: ORBS's upstream ISP is intentionally asking AboveNet to
advertise a netblock that includes ORBS despite AboveNet making it clear
precisely what will happen when they do that. AboveNet is just obeying
their contract with their customer, essentially. ORBS's upstream is
trying to solve the problems they're creating themselves by not dealing
with this some other way by advertising separate routes to ORBS space,
which should work fine, except that they can't seem to do it competently.
The contention that AboveNet is somehow intentionally attracting ORBS
traffic is hogwash; they're advertising what their customer is asking them
to advertise and have made very public precisely what their internal
blocks are. The even more outrageous claim is that AboveNet is somehow
making the separate routes flap, which from all the available independent
evidence appears to be nothing more than either a pure lie or complete
ignorance.
ORBS has plenty to complain about with their immediate upstream, and in
fact the list of addresses on their web page to complain at (said web page
otherwise being full of horribly distorted misinformation) includes a
bunch of people at their immediate upstream. But they're all bundled
under the category of MAPS people, when of course they have nothing to do
with MAPS at all, or AboveNet either for that matter.
And, of course, there's the minor point that I'm pretty sure AboveNet has
been blocking ORBS since long before they bought MIBH and aquired Vixie as
a VP.
> But in the last one, when ORBS listed in the RBL, ORBS was totally in
> the right. I saw grown men, (admins!) trying to defend the position
> that by ORBS sending up to 16 messages through their servers a few times
> a _year_, ORBS was abusing the email system.
You're aware that some machines *which didn't relay* were being tested by
ORBS as frequently as once a *day*, aren't you? Or are you just going by
Alan Brown's account of what he does, which tends to be a little...
sanitized?
You're also aware that ORBS continues to spam the postmasters of machines
which have never relayed in their entire existence?
You're also aware that ORBS provides a service to spammers, providing a
downloadable database of open relays and essentially inviting spammers to
please use them? That, all by itself, is entirely and completely within
the domain of spam support services and should get them put directly on
the RBL. I think it's actually rather inconsistent of the RBL that
they're *not* on it for doing that, although I can understand the
political reasons for not doing so given that Alan Brown seems to have an
endless capacity for duping people like yourself who aren't looking at
what's actually going on and are buying his stories hook, line, and
sinker.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
I think a large number of people on this list need to spend more time actually
listening to and considering people's concerns than simply saying 'thats not
how we do things here'. Anyone else read DJB's discussions about being on the
nameserver mailing list? I'm not being moderated out (I appreciate that), but
the number of slams vs. useful responses to proposals is staggering.
If all you have to say is "not my MTA, thank-you" then you may as well not
bother. Silence does not mean consent. Especially in OSS.
David Dyer-Bennet wrote:
> John R. Dunning <[EMAIL PROTECTED]> writes on 21 July 2000 at 15:40:59 -0000
>
> > I like qmail a lot. It's way easier to deal with than sendmail, and
> > does a good job for my purposes. There are some things which I wish
> > it did differently. This business of not bothering to consolidate
> > deliveries of recipients at a common host (or mx) into a common
> > connection is one of them.
>
> How would you suggest that this be performed without destroying the
> simple, secure, structure of qmail? And what would the cost in
> increased DNS traffic and increased disk bandwidth be?
>
> That is, have you considered this carefully enough to be able to make
> an actual proposal on how to do it, or are you just blowing smoke and
> assuming it's easy and cheap?
On Sat, Jul 22, 2000 at 08:38:47AM -0400, Michael T. Babcock wrote:
> I think a large number of people on this list need to spend more time actually
> listening to and considering people's concerns than simply saying 'thats not
> how we do things here'. Anyone else read DJB's discussions about being on the
Actually they have. A couple of us even implemented patches to do some of
the things that people suggest. The multiple recipient issue came up
and was discussed when qmail was in beta. I recall raising it with others
around the 0.76 release which was almost four years ago. Throttling the
number of connections to a given site was another issue discussed very
early on and at least one person on the list at the time made patches
available to do that.
What happened with me is that I worried about it for years and even saw
some of the pathological situations that people refer to (and having worked
on the mail systems of numerous non-US ISPs that pay and charge by the bit
only exacerbates that concern). But time and observations eased those
concerns and in the end the cost/benefit to make the changes have never
materialized.
Regards.
Michael T. Babcock <[EMAIL PROTECTED]> writes on 22 July 2000 at 08:38:47
-0400
> I think a large number of people on this list need to spend more time actually
> listening to and considering people's concerns than simply saying 'thats not
> how we do things here'. Anyone else read DJB's discussions about being on the
> nameserver mailing list? I'm not being moderated out (I appreciate that), but
> the number of slams vs. useful responses to proposals is staggering.
>
> If all you have to say is "not my MTA, thank-you" then you may as well not
> bother. Silence does not mean consent. Especially in OSS.
You're bringing up an old, old, argued-to-death, topic, and displaying
ignorance of that history. People *do* hear what you're saying.
We've heard it all before. We've heard various responses before.
We've thought about it a lot. Our failure to accept your ideas is not
because we have not heard them; it's because we *have* heard them;
repeatedly. And the responses to them.
Probably our responses are by now somewhat cryptic, encoded in local
language that's completely clear to those of us who've been through
the argument umpteen times before. And which is probably NOT clear to
you; sorry about that!
Meanwhile, you're asking us to do all the work, *again*, to disprove
some claims that have been repeatedly disproved in the past. Sorry,
most of us are confident in our positions and don't feel a need to do
that much work.
Plus there's the DJB factor :-). Doesn't matter if you convince *us*
or not; qmail is not, in fact, open source software.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
On Sun, Jul 23, 2000 at 12:37:55AM -0500, David Dyer-Bennet wrote:
> Probably our responses are by now somewhat cryptic, encoded in local
> language that's completely clear to those of us who've been through
> the argument umpteen times before. And which is probably NOT clear to
> you; sorry about that!
Yes, let me translate for David:
"Shut Up and Go Away"
--Adam
Hi All...
My Setup qmail+vpopmail. I'd like to eliminate
duplicate msgs... so I installed eliminate-dup package
and made the necessary .qmail file under
/home/vpopmail/domains/test.com/sumith/
now instead of only the duplicate msgs getting deleted
all the messages are getting deleted... Any IDEA whats
going wrong....
Sumith
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/
Austad, Jay writes:
> Instead of having qmqpc picking the first available server, I would like it
> to load balance between all servers I have listed as QMQP servers.
Do it the other way around. If a server thinks its load is too high,
it should shut down its qmqpc service.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Tornadoes, earthquakes,
521 Pleasant Valley Rd. | +1 315 268 1925 voice | hurricanes and government:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | uncontrollable forces
True, but its quite valid to round-robin several servers to keep any one from ever
getting a high load in the first place. eg. the way load-balancing HTTP usually
works.
Russell Nelson wrote:
> Austad, Jay writes:
> > Instead of having qmqpc picking the first available server, I would like it
> > to load balance between all servers I have listed as QMQP servers.
>
> Do it the other way around. If a server thinks its load is too high,
> it should shut down its qmqpc service.
It would probably be much more efficient to round-robin them. Otherwise you
end up banging on one until it's buried (or at it's set limit), then banging
on the next, and so on. What happens when they all decide their load is too
high and shut down qmqpd? Isn't it much easier to code round-robin into it
anyway?
Would it be easier to just make it so I could put a hostname into the
qmqpservers file and do round robin dns for it? Wouldn't that just be a
simple addition of gethostbyname()?
I have to say though, I really like the way qmail is laid out. Lots of small
programs with specific functions, it makes it very easy to do modifications.
Jay
-----Original Message-----
From: Michael T. Babcock [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 22, 2000 3:55 PM
To: Russell Nelson
Cc: '[EMAIL PROTECTED]'
Subject: Re: qmqpc load balancing
True, but its quite valid to round-robin several servers to keep any one
from ever
getting a high load in the first place. eg. the way load-balancing HTTP
usually
works.
Russell Nelson wrote:
> Austad, Jay writes:
> > Instead of having qmqpc picking the first available server, I would
like it
> > to load balance between all servers I have listed as QMQP servers.
>
> Do it the other way around. If a server thinks its load is too high,
> it should shut down its qmqpc service.
Hi Everyone..
I have setup Qmail according to the LWQ document, and also installed the
scripts which are used in this document to start qmail..
Everything works nicely, but I would like to have all mail be delivered in
the the /var/spool/mail directory instead of $HOME/$USER/Mailbox..
I read the INSTALL files, but I can't figure out something..
You run the command 'qmail-start ./Mailbox splogger qmail' to deliver to
Mailbox file
When I read the documentation what you need to change in order to get the
delivery in your /va/spool directory they tell you, you need to use Procmail
(or binmail) to deliver your mail to /var/spool/mail..
Is this correct? Isn't there a easier way?
Bascially I am very happing how everything is working, I only would like to
change the delivery directory..
I am running Redhat 6.2 and removed all sendmail files before doing the
Qmail install..
What in my situation would I need to install/change to get it to work..
Sorry if this is a dumb question..
Bye Bye
David
Hi,
Again a security problem with outlook : look at the announce
on securityfocus:
http://www.securityfocus.com/vdb/bottom.html?section=solution&vid=1481
On the solution page, it is written:
> Workaround:
>
> Filters have been made for Sendmail and Postfix to deal with this issue. See the
>Bugtraq posts in
> the Credit section for more information.
Well, these filters are quite simple : but how could I setup such a workaround
on my old qmail server ? What about a /var/qmail/regexpreject ? What do you
think ? Could be a feature for a qmail 1.04... :)
Regards,
Olivier
--
_________________________________________________________________
Olivier Mueller - [EMAIL PROTECTED] - PGPkeyID: 0E84D2EA - Switzerland
From: Olivier M. <[EMAIL PROTECTED]>
>Well, these filters are quite simple : but how could I setup such a
workaround
>on my old qmail server ? What about a /var/qmail/regexpreject ? What do
you
>think ? Could be a feature for a qmail 1.04... :)
Probably ofmipd from the mess822 package repairs the date field...
Armando
On Sat, Jul 22, 2000 at 06:00:30PM -0000, asantos wrote:
> From: Olivier M. <[EMAIL PROTECTED]>
> >Well, these filters are quite simple : but how could I setup such a workaround
> >on my old qmail server ? What about a /var/qmail/regexpreject ? What do
> > you think ? Could be a feature for a qmail 1.04... :)
> Probably ofmipd from the mess822 package repairs the date field...
is it an add-on to qmail-smtpd, or something to add in the .qmail-xxx ?
It should be something system-wide...
Olivier
--
_________________________________________________________________
Olivier Mueller - [EMAIL PROTECTED] - PGPkeyID: 0E84D2EA - Switzerland
From: Olivier M. <[EMAIL PROTECTED]>
>is it an add-on to qmail-smtpd, or something to add in the .qmail-xxx ?
>It should be something system-wide...
It replaces qmail-smtpd. Check http://cr.yp.to/mess822.html , download the
package and read ofmipd.8 inside. Note that this does not prevent the MIME
version of the exploit, and that that unforeseen problems (not security, its
djb's work) may arise, re bandwidth, speed, too much filtering of the
headers, and so on.
Armando
On Sat, Jul 22, 2000 at 05:49:51PM +0200, Olivier M. wrote:
> Again a security problem with outlook : look at the announce
> on securityfocus:
>
> http://www.securityfocus.com/vdb/bottom.html?section=solution&vid=1481
>
> Well, these filters are quite simple : but how could I setup such a workaround
> on my old qmail server ? What about a /var/qmail/regexpreject ? What do you
> think ? Could be a feature for a qmail 1.04... :)
Check out qmail-qfilter, and write a filter that looks for date lines
longer than 80 characters while copying the message. Reject any message
that contains them. In Perl (untested):
perl -p 'exit 31 if /^Date: .{80,}/oi'
And I didn't even need to patch qmail :-) (although qmail-qfilter works
best used with the rather trivial QMAILQUEUE patch).
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
On Sun, Jul 23, 2000 at 12:27:36AM -0600, Bruce Guenter wrote:
> On Sat, Jul 22, 2000 at 05:49:51PM +0200, Olivier M. wrote:
> > http://www.securityfocus.com/vdb/bottom.html?section=solution&vid=1481
>
> Check out qmail-qfilter, and write a filter that looks for date lines
> longer than 80 characters while copying the message. Reject any message
> that contains them. In Perl (untested):
>
> perl -p 'exit 31 if /^Date: .{80,}/oi'
Just to correct myself, the following Perl is more correct:
while(<>) {
print;
last if /^\n$/o;
exit 31 if /^Date: .{80,}/oi;
}
while(<>) {
print;
}
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
Somebody is using a *very* broken mailer.
----- Forwarded message from [EMAIL PROTECTED] -----
Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 17992 invoked from network); 22 Jul 2000 15:33:24 -0000
Received: from leeuwarden.vuurwerk.nl (194.178.232.16)
by winschoten.vuurwerk.nl with SMTP; 22 Jul 2000 15:33:24 -0000
Received: from ns.albertsons.com ([167.234.1.10])
by leeuwarden.vuurwerk.nl (8.9.2/8.9.1) with ESMTP id RAA31786
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 17:33:23 +0200 (CEST)
Received: from S7352c.7000.albertsons.com (S7352c.7000.albertsons.com
[167.234.12.204]) by ns.albertsons.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id JAA14290
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 09:30:48 -0600
Received: from dubs0001.amstr.com (roll.mcit.com [162.120.128.9])
by S7352c.7000.albertsons.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA131978
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 09:30:10 -0600
X-Internal-ID: 3973070E000158DE
Received: from amstr.com (162.120.128.9) by dubs0001.amstr.com (NPlex 2.0.119) for
[EMAIL PROTECTED]; Sat, 22 Jul 2000 08:30:11 -0700
Message-ID: <[EMAIL PROTECTED]>
Date: 22 Jul 2000 08:30:11 -0700
From: [EMAIL PROTECTED]
Subject: Returned mail: User unknown
To: [EMAIL PROTECTED]
*** This message originated by GCS Client Services ***
----- Delivery could not be made to the following recipients -----
Invalid Recipient: MichaelG <[EMAIL PROTECTED]> (unrecoverable error)
Invalid Recipient: qmail <[EMAIL PROTECTED]> (unrecoverable error)
RFC822 Header may follow:
X-Env-Sender: [EMAIL PROTECTED]
X-Env-Recipient: [EMAIL PROTECTED]
X-End-of-Envelope:
X-Internal-ID: 3973070E000158DD
Received: from amstr.com (162.120.128.9) by dubs0001.amstr.com (NPlex 2.0.119) for
[EMAIL PROTECTED]; Sat, 22 Jul 2000 08:30:06 -0700
Message-ID: <[EMAIL PROTECTED]>
Date: Sat, 22 Jul 2000 17:29:04 +0200
From: (Peter van Dijk) <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: orbs.org accuses qmail of mailbomb relaying!
----- End forwarded message -----
Greetz, Peter.
--
[EMAIL PROTECTED] - Peter van Dijk [student:developer:ircoper]
And my previous message about a broken mailer generated a bounce from
*another* broken mailer...
----- Forwarded message from Mail Delivery Subsystem <[EMAIL PROTECTED]> -----
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 23018 invoked from network); 22 Jul 2000 16:15:31 -0000
Received: from leeuwarden.vuurwerk.nl (194.178.232.16)
by winschoten.vuurwerk.nl with SMTP; 22 Jul 2000 16:15:31 -0000
Received: from mta1.infoteen.com (media1.infoteen.com [216.35.114.216] (may be forged))
by leeuwarden.vuurwerk.nl (8.9.2/8.9.1) with ESMTP id SAA01713
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 18:15:30 +0200 (CEST)
Received: (from mail@localhost)
by mta1.infoteen.com (8.9.3/8.8.7) id JAA12144;
Sat, 22 Jul 2000 09:06:51 -0700
Date: Sat, 22 Jul 2000 09:06:51 -0700
Message-Id: <[EMAIL PROTECTED]>
From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
Subject: Returned Mail: user [EMAIL PROTECTED] unknown!
To: Peter van Dijk <[EMAIL PROTECTED]>
Action: failed
Status: 5.0.0
Dagnostic-Code: SMTP; 550 No such user here
Content-Type: text/plain
The following email has been returned to you.
Error 550: User [EMAIL PROTECTED] is not an existing InfoTeen.com
account. Please make sure that the email address you specified,
[EMAIL PROTECTED]@infoteen.com is valid.
Email Message Follows
---------------------
>From [EMAIL PROTECTED] Sat Jul 22 09:06:51 2000
Received: from muncher.math.uic.edu (koobera.math.uic.edu [131.193.178.181])
by mta1.infoteen.com (8.9.3/8.8.7) with SMTP id JAA12140
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 09:06:50 -0700
Received: (qmail 13465 invoked by uid 1002); 22 Jul 2000 16:14:10 -0000
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 12106 invoked from network); 22 Jul 2000 16:14:09 -0000
Received: from envy.vuurwerk.nl ([EMAIL PROTECTED])
by muncher.math.uic.edu with SMTP; 22 Jul 2000 16:14:09 -0000
Received: (qmail 40488 invoked from network); 22 Jul 2000 16:13:45 -0000
Received: from kesteren.vuurwerk.nl (HELO daemon.vuurwerk.nl) (194.178.232.59)
by envy.vuurwerk.nl with SMTP; 22 Jul 2000 16:13:45 -0000
Received: (nullmailer pid 23406 invoked by uid 11109);
Sat, 22 Jul 2000 16:13:44 -0000
Date: Sat, 22 Jul 2000 18:13:44 +0200
From: Peter van Dijk <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: some broken mailer [[EMAIL PROTECTED]: Returned mail: User unknown]
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
Somebody is using a *very* broken mailer.
----- Forwarded message from [EMAIL PROTECTED] -----
Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 17992 invoked from network); 22 Jul 2000 15:33:24 -0000
Received: from leeuwarden.vuurwerk.nl (194.178.232.16)
by winschoten.vuurwerk.nl with SMTP; 22 Jul 2000 15:33:24 -0000
Received: from ns.albertsons.com ([167.234.1.10])
by leeuwarden.vuurwerk.nl (8.9.2/8.9.1) with ESMTP id RAA31786
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 17:33:23 +0200 (CEST)
Received: from S7352c.7000.albertsons.com (S7352c.7000.albertsons.com
[167.234.12.204]) by ns.albertsons.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id JAA14290
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 09:30:48 -0600
Received: from dubs0001.amstr.com (roll.mcit.com [162.120.128.9])
by S7352c.7000.albertsons.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA131978
for <[EMAIL PROTECTED]>; Sat, 22 Jul 2000 09:30:10 -0600
X-Internal-ID: 3973070E000158DE
Received: from amstr.com (162.120.128.9) by dubs0001.amstr.com (NPlex 2.0.119) for
[EMAIL PROTECTED]; Sat, 22 Jul 2000 08:30:11 -0700
Message-ID: <[EMAIL PROTECTED]>
Date: 22 Jul 2000 08:30:11 -0700
From: [EMAIL PROTECTED]
Subject: Returned mail: User unknown
To: [EMAIL PROTECTED]
*** This message originated by GCS Client Services ***
----- Delivery could not be made to the following recipients -----
Invalid Recipient: MichaelG <[EMAIL PROTECTED]> (unrecoverable error)
Invalid Recipient: qmail <[EMAIL PROTECTED]> (unrecoverable error)
RFC822 Header may follow:
X-Env-Sender: [EMAIL PROTECTED]
X-Env-Recipient: [EMAIL PROTECTED]
X-End-of-Envelope:
X-Internal-ID: 3973070E000158DD
Received: from amstr.com (162.120.128.9) by dubs0001.amstr.com (NPlex 2.0.119) for
[EMAIL PROTECTED]; Sat, 22 Jul 2000 08:30:06 -0700
Message-ID: <[EMAIL PROTECTED]>
Date: Sat, 22 Jul 2000 17:29:04 +0200
From: (Peter van Dijk) <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: orbs.org accuses qmail of mailbomb relaying!
----- End forwarded message -----
Greetz, Peter.
--
[EMAIL PROTECTED] - Peter van Dijk [student:developer:ircoper]
----- End forwarded message -----
Greetz, Peter.
--
[EMAIL PROTECTED] - Peter van Dijk [student:developer:ircoper]
Quoting Peter van Dijk ([EMAIL PROTECTED]):
> And my previous message about a broken mailer generated a bounce from
> *another* broken mailer...
>
> ----- Forwarded message from Mail Delivery Subsystem <[EMAIL PROTECTED]>
>-----
My mail to [EMAIL PROTECTED] bounced, so I malleted them into
badmailfrom--they are kind enough to send their bounces with a
non-null return-path :) I think it would be nice if Mr. Bernstein
could unsub these dweebs from the list.
Aaron
> The following email has been returned to you.
> Error 550: User [EMAIL PROTECTED] is not an existing InfoTeen.com
> account. Please make sure that the email address you specified,
> [EMAIL PROTECTED]@infoteen.com is valid.
I think unsubscribing them is probably unnecessary, but blocking their 'bounce'
messages at
the list server would probably be smart.
"Aaron L. Meehan" wrote:
> My mail to [EMAIL PROTECTED] bounced, so I malleted them into
> badmailfrom--they are kind enough to send their bounces with a
> non-null return-path :) I think it would be nice if Mr. Bernstein
> could unsub these dweebs from the list.
Yep, same thing here. I think someone (probably <[EMAIL PROTECTED]>,
since it appears in the bounces tough the original message was no addressed
to said individual) has a mail forwarder that gags with semicolon separated
addresses in the To: field.
Armando
I've written a little perl script to analyze a qmail log.
This scripts gives a hint as to what you might save in bandwidth
if qmail supported multiple recipients.
This results is indicative at best - here are some caveats:
o only messages sizes as recorded in the log are counted
o SMTP overhead is not counted
o DNS overhead is not counted
o TCP overhead is not counted
o failed deliveries are not counted
o Aggregation is by FQDN, not MX target
o Assumes no VERP (which makes each message unique and this not countable)
(grep these out if it's a problem)
o The incremental costs of subsequent deliveries via multiple recipients
is assumed to be zero.
So if you feed it a log that has one message inserted for 2 remote
recipients to the same domain it will show a potential saving of
50%.
Since the script is only lightly tested, I'm soliciting a few volunteers
who are willing to run this script on their log files and send the results
back to me (and/or the list if you so desire).
You must be able to run a perl script and devise a preprocessing command
such as cut or awk (as the script only wants the qmail output, not
timestamps and such). You must understand the caveats, and giving me
feedback would be nice. IOW, no beginners please.
Email me if you can help.
Mark.
On Sat, Jul 22, 2000 at 12:45:57PM -0700, [EMAIL PROTECTED] wrote:
> I've written a little perl script to analyze a qmail log.
Have you looked at qmailanalog? Could it help you if it does not
already do what you want?
> This scripts gives a hint as to what you might save in bandwidth
> if qmail supported multiple recipients.
The zoverall script in qmailanalog will give you a maximum bound to this
number. On my SMTP proxy (450MB over 9.5 days, not that big yet), a
maximum of 20% could have been saved.
> This results is indicative at best - here are some caveats:
>
> o failed deliveries are not counted
Reasonable, since nearly all failed deliveries will fail before the
"DATA" command.
> o Aggregation is by FQDN, not MX target
Which is the only reasonable way to do it. If you aggregate based on MX
target, you need to do (and wait for!) DNS lookups on all recipients of
each message. This is a good way of slowing things down for no real
gain.
> o The incremental costs of subsequent deliveries via multiple recipients
> is assumed to be zero.
Which is one of the contentious points in the whole discussion. This
one *REALLY* needs some real-world measurements, which would be quite
difficult to do. There will likely be a point (in terms of message
size) where the time cost of opening up more connections (in parallel,
remember) will be less than the cost of issuing another RCPT.
You could simulate this by producing a test message, and (1) forking off
N copies of qmail-remote with a single recipient, and (2) forking off 1
copy of qmail-remote with N recipients, and time how long it takes for
the qmail-remotes to exit. Repeat with a series of message sizes. On
my proxy again, the median size is around 3000 bytes (including
headers), just as a guide for how to distribute the sizes. Make sure
the system you benchmark with is far enough remote to cause significant
latencies (100ms or worse), or try various systems with various
latencies.
> Since the script is only lightly tested, I'm soliciting a few volunteers
> who are willing to run this script on their log files and send the results
> back to me (and/or the list if you so desire).
I'd be willing to do this, I'm somewhat curious myself.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
Yes, I've seen this too. I can almost guarantee that the user on the
remote server has exceeded their storage allocation. They've probably
received a message from the server telling them they should delete some
mail.
Incidentally, in RFC 821, that is the exact text for error 552. Hotmail
et. al. tend to rewrite it otherwise ... so it might be a sendmail site or
something.
"Aaron L. Meehan" wrote:
> Quoting Ismal Hisham Darus ([EMAIL PROTECTED]):
> > I don't know where the problem is .. but in my my case, we have two
> > qmail servers server0 and server1 (not using inetd.. of course :)).
> > When somebody send files exceeding 2.5mb, he get a bouce mail stating
> > that :
> >
> > Remote host said: 552 Requested mail action aborted: exceeded storage
> > allocation.
>
> Anyway, as others stated, that message isn't output by qmail. I
> _have_ seen that particular annoying message before: it's output by
> hotmail.com's mail servers when you send an email to someone there
> that has exceeded their mail quota.
>
> The quota is quite small at hotmail and other free mail providers, and
> they outright *bounce* mail when it's exceeded.
You might just be running into chown user.group problems ... try escaping the
'.' or wrapping the username in quotes. That failing, does al.koch have an
entry in /etc/passwd? Your final question makes me believe that none of your
users are in /etc/passwd at all. You might want to convert to vpopmail, which
wouldn't require adding users to /etc/passwd.
Tony Campisi wrote:
> When I set up my Sendmail box last year I added all of my users in
> 'userconf' as POP accounts (mail only). Approx 250. As I'm attempting to add
> Maildir folders under their /home/name directories, I cannot chown Maildir.
> For example:
>
> drwx------ 5 root popusers 1024 Jul 21 11:22 Maildir
> [root@mail2 /home/al.koch]# chown -R al.koch /home/al.koch/Maildir
> chown: al.koch: invalid user
>
> Will I have to remove all my users and add them as regular users?
Wouldn't you just rotate the mailservers? Go from A to B to C instead of
picking one randomly? I don't see how random distribution is going to be less
balanced than a simple round-robin, and generating random numbers tends to take
more computation than incrementing a variable.
"Austad, Jay" wrote:
> Instead of having qmqpc picking the first available server, I would like it
> to load balance between all servers I have listed as QMQP servers. In
> qmail-qmqpc.c on line 153, it says:
> i = 0;
> for (j = 0;j < servers.len;++j)
> if (!servers.s[j]) {
> doit(servers.s + i);
> i = j + 1;
> }
>
> Would it work if I change it to:
> i = 0;
> for (j = 0;j < servers.len;++j)
> i = (servers.len*1.0)*rand()/(RAND_MAX+1.0);
> if (!servers.s[j]) {
> doit(servers.s + i);
> }
>
> This way, "i" will be a random number from 0 to (servers.len-1).
>
> ----------
> Jay Austad
> Network Administrator
> CBS Marketwatch
> 612.817.1271
> [EMAIL PROTECTED]
> http://cbs.marketwatch.com
> http://www.bigcharts.com
"John van V." wrote:
> I am building a site to toot the horn of public domain products that have
> industrial strength.
I'm not aware of Qmail being public domain ... I see a public domain statement in
sgetopt and subgetopt ... but that is all. (please correct me if I'm wrong --
and the licensing should be easier to find ... at the top of the README, for
instance).
> Its actually becoming free portal w/o banners and such combining the features
> of yahoo! and dejanews, for instance w/ developer support as well.
>
> I'd like to find readers-digest versions of all the uscpi tools, daemontools,
> the kind of stuff that resides under the qmail type apps.
>If, however, you admit that it causes problems for sendmail installations, and
>you admit that a lot of sites use sendmail, then you'll probably agree that
>defining "good netizen" would include "limiting outgoing connections to a
>particular MX" ... to some reasonable number (heck, you can detect what the
>foreign MTA is when you connect usually ... )
I've been thinking for quite a while of some sort of hack to qmail to
do remote load management, the idea being that we want to open almost
but not quite enough connections to each remote system to make the
remote fall over.
Possibilities for guessing the appropriate limit per remote might include:
- sniff the SMTP banner for known lame MTAs
- measure the round trip time, for the response to HELO, stop connecting
when it becomes "too much", either an absolute limit or N times more than
it used to be
- pay more attention to "421 come back later" type messages
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
For your #1: this would be similar to the Linux kernel approach to DMA on hard
drives ... enable by default, except on those drives we have in database of broken
drives.
As for #2 and #3: this adds overhead, of course, but could inherently reduce
overhead down the road, as long as the algorithm is simple. Something like a
simple:
(pseudo:)
if (hosts[current].connections < hosts[current].max_connections)
{
/* ... open connection ...
... read response ...
... record response latency as current_latency ... */
if (response_val == 421
|| current_latency > best_latency * (1 + latency_percentage))
{
hosts[current].max_connections = hosts[current].connections;
/* could be connections -1 but this will keep trying to up the # */
} else {
best_latency = min(best_latency, current_latency);
/* ... do delivery ... */
}
}
I hope this satisfies someone ... :-P
"John R. Levine" wrote:
> I've been thinking for quite a while of some sort of hack to qmail to
> do remote load management, the idea being that we want to open almost
> but not quite enough connections to each remote system to make the
> remote fall over.
>
> Possibilities for guessing the appropriate limit per remote might include:
>
> - sniff the SMTP banner for known lame MTAs
>
> - measure the round trip time, for the response to HELO, stop connecting
> when it becomes "too much", either an absolute limit or N times more than
> it used to be
>
> - pay more attention to "421 come back later" type messages
Hi,
Just installed qmail and procmail on a FreeBSD 4.0 box. qmail works
fine if I delete .qmail
With .qmail containing
less .qmail
| /var/qmail/bin/preline /usr/local/bin/procmail
I find in /var/log/maillog
local _|_/var/qmail/bin/preline_/usr/local/bin/procmail@adsl-6etc. etc
later I get no_mailbox as to be expected.
That is, procmail is attemting to deliver to a local address, clearly a
non-existant local address, on my box.
It is as if preline is not being executed but is being treated as an
address.
Advice please.
Thanks
Jeff
Export to CSV format, then you can import them into MySQL with very
little difficulty (LOAD DATA ... see MySQL manual). If you're not using
MySQL authentication, sorry.
"Javier Vino R." wrote:
> I have a big table in MS exel with de login and pass, How can I do to
> import from VPOPMAIL all the users ? I hope so u can help me
Another possibility is to install the MySQL ODBC driver which works quite
well and use that to upload the data directly from Excel into MySQL.
>Export to CSV format, then you can import them into MySQL with very
>little difficulty (LOAD DATA ... see MySQL manual). If you're not using
>MySQL authentication, sorry.
>
>> I have a big table in MS exel with de login and pass, How can I do to
>> import from VPOPMAIL all the users ? I hope so u can help me
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
I tried the suggestion [thanks John] below but alas.
Jul 22 13:46:42 adsl-63-201-55-218 qmail: 964298802.949315 starting
delivery 86: msg 79379 to local
_|[EMAIL PROTECTED]
Jeff
>local _|_/var/qmail/bin/preline_/usr/local/bin/procmail@adsl-6etc. etc
>later I get no_mailbox as to be expected.
>
>Advice please.
Try deleting the space in front of the vertical bar.
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
Why am I getting bounces when the message is indeed getting to the list?
Also, who is GCS Client Services?
-------- Original Message --------
Subject: Returned mail: User unknown
Date: 22 Jul 2000 05:29:39 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
*** This message originated by GCS Client Services ***
----- Delivery could not be made to the following recipients -----
Invalid Recipient: MichaelG <[EMAIL PROTECTED]> (unrecoverable
error)
Invalid Recipient: qmail <[EMAIL PROTECTED]> (unrecoverable
error)
Invalid Recipient: qmail <[EMAIL PROTECTED]> (unrecoverable error)
RFC822 Header may follow:
X-Env-Sender: [EMAIL PROTECTED]
X-Env-Recipient: [EMAIL PROTECTED]
X-End-of-Envelope:
X-Internal-ID: 3973070E00015629
Received: from amstr.com (162.120.128.9) by dubs0001.amstr.com (NPlex
2.0.119) for [EMAIL PROTECTED]; Sat, 22 Jul 2000 05:29:26 -0700
Message-ID: <[EMAIL PROTECTED]>
Date: Sat, 22 Jul 2000 08:29:08 -0400
From: (Michael T Babcock) <[EMAIL PROTECTED]>
To: (Charles Cazabon) <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: orbs.org accuses qmail of mailbomb relaying!
I'd have to agree. I'm using ORBS ... but it was a lot of internal arguing (my
head :-)
At some point I need to rewrite the ORBS interface software to both bounce the
messages and deliver them to a temporary store where I can review them.
Russell Nelson wrote:
> Alan is the south end of a horse going north. Given the way he runs
> orbs.org and the accusations he makes of people, I'm amazed that
> anyone uses ORBS.
My apologies for sending this again but I could not receive mail responses
for a bit because.... silly me,.... I forgot to remove the .qmail before
sending the note below.
If anyone was good enought to repsond as yet please also be so good as to
send again.
Thanks
Jeff
---
I tried the suggestion [thanks John] below but alas.
Jul 22 13:46:42 adsl-63-201-55-218 qmail: 964298802.949315 starting
delivery 86: msg 79379 to local
_|[EMAIL PROTECTED]
Jeff
>local _|_/var/qmail/bin/preline_/usr/local/bin/procmail@adsl-6etc. etc
>later I get no_mailbox as to be expected.
>
>Advice please.
Try deleting the space in front of the vertical bar.
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
From: Jeff Gray <[EMAIL PROTECTED]>
>I tried the suggestion [thanks John] below but alas.
>
>_|[EMAIL PROTECTED]
>
Ah, the Americisms... :)
Jeff, note the underline before the pipe ( _| ). Delete the space at the
*start* of the line, *before* the pipe.
Armando
Thanks, this was, of course, the fix. This post is now mostly for
the archives so another will not fall into the 'American whitespace
hole" <g>.
With appreciation to a list that responds professionally and
quickly. Hopefully in a bit I too will be able to contribute.
Jeff
On Sat, 22 Jul 2000, asantos wrote:
> From: Jeff Gray <[EMAIL PROTECTED]>
> >I tried the suggestion [thanks John] below but alas.
> >
> >_|[EMAIL PROTECTED]
> >
>
>
> Ah, the Americisms... :)
>
> Jeff, note the underline before the pipe ( _| ). Delete the space at the
> *start* of the line, *before* the pipe.
>
> Armando
>
>
>
Scratch previous comment -- bounces are going to individual senders, not to list
(because
headers are not rewritten, which is a good thing, I suppose). I'll add a filter
myself for
my host.
"Aaron L. Meehan" wrote:
> My mail to [EMAIL PROTECTED] bounced, so I malleted them into
> badmailfrom--they are kind enough to send their bounces with a
> non-null return-path :) I think it would be nice if Mr. Bernstein
> could unsub these dweebs from the list.
Hi all,
I'm probably not the first one to stumble over this 'problem'. I've
recently installed Q-Mail (yesterday), and found 1 problem rather 'annoying'. I
can't send any mail to root. Anyone else works fine, but not root. The qmail
daemon tells me (in /var/log/messages)
cannot chdir to maildir
what does this mean?
I'm using the Maildir configuration (as it is most safe - and security &
safety come first here).
If anyone has got an answer... Please let me know.
(as detailed as possible)
Thanks!
--
Jan De Luyck <[EMAIL PROTECTED]>
Webmaster of http://www.blindguardian.org
ICQ: 8453612
Public PGP key at http://www.blindguardian.org/txt/pgp_public.asc
Geekcode: GCS/IT/TW/MC d- s+:+ a-- C++>++++$ UL++>++++$ P+>+++
L++>++++ E---- W++>+++$ N++ o? K? w-- O- M- V? PS+ PE+ Y+>++ PGP++ t+
5-- X R+>+++ tv- b++ DI+ D G e* h! !r-- y!
Sent through Global Message Exchange - http://www.gmx.net
On Sun, Jul 23, 2000 at 12:21:52AM +0200, [EMAIL PROTECTED] wrote:
> can't send any mail to root. Anyone else works fine, but not root. The qmail
> daemon tells me (in /var/log/messages)
Check out INSTALL.alias file in your qmail/doc directory. It explains why
and what to do.
--
John______________________________________________________________________
email: [EMAIL PROTECTED] Quis custodiet ipsos custodes
icq: thales @ 17755648
Also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> on 23.07.2000:
from the qmail-1.0.3/INSTALL file:
5. Read INSTALL.alias. Minimal survival command:
# (cd ~alias; touch .qmail-postmaster .qmail-mailer-daemon
qmail-root)
# chmod 644 ~alias/.qmail*
from qmail-1.0.3/INSTALL.alias:
* root. Under qmail, root never receives mail. Your system may generate
mail messages to root every night; if you don't have an alias for root,
those messages will bounce. (They'll end up double-bouncing to the
postmaster.) Set up an alias for root in ~alias/.qmail-root. .qmail
files are similar to .forward files, but beware that they are strictly
line-oriented---see dot-qmail.0 for details.
# end of quotes
so you should set up an alias root either as ~alias/.qmail-root
or in /etc/aliases if you use that.
and that alias should redirect mails for root to one or more persons in
charge ...
wolfgang
> Also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> on 23.07.2000:
> >from the qmail-1.0.3/INSTALL file:
> 5. Read INSTALL.alias. Minimal survival command:
> # (cd ~alias; touch .qmail-postmaster .qmail-mailer-daemon
> qmail-root)
> # chmod 644 ~alias/.qmail*
>
> >from qmail-1.0.3/INSTALL.alias:
> * root. Under qmail, root never receives mail. Your system may generate
> mail messages to root every night; if you don't have an alias for root,
> those messages will bounce. (They'll end up double-bouncing to the
> postmaster.) Set up an alias for root in ~alias/.qmail-root. .qmail
> files are similar to .forward files, but beware that they are strictly
> line-oriented---see dot-qmail.0 for details.
>
> # end of quotes
> so you should set up an alias root either as ~alias/.qmail-root
> or in /etc/aliases if you use that.
>
> and that alias should redirect mails for root to one or more persons in
> charge ...
>
> wolfgang
>
Ic. Thanks!
--
Jan De Luyck <[EMAIL PROTECTED]>
Webmaster of http://www.blindguardian.org
ICQ: 8453612
Public PGP key at
http://www.blindguardian.org/txt/http://www.blindguardian.org/txt/publ
ic_key.asc
Geekcode: GCS/IT/TW/MC d- s+:+ a-- C++>++++$ UL++>++++$ P+>+++
L++>++++ E---- W++>+++$ N++ o? K? w-- O- M- V? PS+ PE+ Y+>++ PGP++ t+
5-- X R+>+++ tv- b++ DI+ D G e* h! !r-- y!
Sent through Global Message Exchange - http://www.gmx.net
On Sun, Jul 23, 2000 at 12:21:52AM +0200, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I'm probably not the first one to stumble over this 'problem'. I've
> recently installed Q-Mail (yesterday), and found 1 problem rather 'annoying'. I
It's qmail :-) not Q-Mail, nor Qmail.
> can't send any mail to root. Anyone else works fine, but not root. The qmail
> daemon tells me (in /var/log/messages)
>
You can't do it now, and you probably never will while using qmail. It refuses to
deliver to root. That's mentioned in the documentation, somewhere. Set up a
.qmail-root in ~alias, and deliver it to some other user.
RC
--
+-------------------
| Ricardo Cerqueira
| PGP Key fingerprint - B7 05 13 CE 48 0A BF 1E 87 21 83 DB 28 DE 03 42
| Novis - Engenharia ISP / Rede T�cnica
| P�. Duque Saldanha, 1, 7� E / 1050-094 Lisboa / Portugal
| Tel: +351 21 3166700 (24h/dia) - Fax: +351 21 3166701
Bruce Edge <[EMAIL PROTECTED]> wrote:
> I can send a message to a remote host using:
>
> echo to: [EMAIL PROTECTED] | /var/qmail/bin/qmail-inject
>
> but I cannot do so from a pop3 MUA, netsacpe.
>
> When I try I get a dialog:
> Sorry that's not in my list of rtpchosts (#5.7.1)
You're testing two different things; qmail-inject injects directly into the
queue. Netscape uses SMTP to connect to the machine and talk to its smtpd.
> If I add remote.com to rtpchosts it works, but I should not have to add every
> possible mail host on the 'net in this file.
>
> Is this a qmail-pop3d issue? If so where do I tell it to forward mail to
> unknown hosts.
qmail-smtpd is denying relaying, as it's not configured to accept mail for the
recipient domain, as you found out. Check the file
/var/qmail/control/rcpthosts. It should contain (along with whatever other
_local_ domains you've got (plus virtuals)), plus localhost.
If you're trying to run Netscape on a different machine and inject mail, you'll
have to set up selective relaying. Dave Sill's "Life with qmail" does a
good job of covering this topic.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
Paul Farber wrote:
>
> telnetting to port 25 and 110 just timed out.
This usually means (when it has happened to me anyway) that the
server is listening on the port you're telnetting to, but is
stalled doing a reverse DNS lookup of the client's IP address.
Perhaps a munged reverse DNS zonefile?
> DNS was fine... it means
> just that, I could ping via hostname and the dns logs show it was running.
That could still happen under the above scenario...
Eric
I have a question many of you have probably answered before.
Let me give you some info about my setup first:
qmail,vpopmail,daemontools,ucspi-tcp
I followed "Life with qmail" concerning the setup of the
/var/qmail/supervise/qmail-send and
/var/qmail/supervise/qmail-smtpd directories and they
seem to be working fine.
However, pop3d is another situation. I created a
/var/qmail/supervise/qmail-pop3d directory and added
the run file and log directory. When I issue a
/etc/rc.d/init.d/qmail start, everything seems to work
fine including pop3. When I issue a /etc/rc.d/init.d/qmail stop,
pop3 still continues on about it's business.
Below is some misc code:
/var/qmail/supervise/qmail-pop3d/run:
-------------------------------------
#!/bin/sh
/usr/local/bin/tcpserver 0 pop3 /var/qmail/bin/qmail-popup pop.linux-perl.com \
/home/vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d Maildir 2>&1
/etc/rc.d/init.d/qmail (snippet):
---------------------------------
...
start)
echo -n "Starting qmail: svscan"
cd /var/qmail/supervise
env - PATH="$PATH" svscan &
echo $! > /var/run/svscan.pid
echo "."
;;
stop)
echo -n "Stopping qmail: svscan"
kill `cat /var/run/svscan.pid`
echo -n " qmail"
svc -dx /var/qmail/supervise/*
echo -n " logging"
svc -dx /var/qmail/supervise/*/log
echo "."
;;
...
I hope someone can help me with this.
Thanks,
Jeff Jones
Jens Georg wrote:
>
> hi,
>
> i have a little confusing problem with qmail:
>
> i can send email to [EMAIL PROTECTED] (where bob is a real user), but i cannot
> send email to i.e. [EMAIL PROTECTED] where bobby is a virtual user. somebody
> can help me please ? this works sometimes, but after rebooting the machine
> i.e. sometimes i get a "sorry, no mailbox ...." message.
What does your config look like?
Eric
