getting qmail to retry
I got this back for a bounced bounce: | Hi. This is the qmail-send program at ipal.net. | I tried to deliver a bounce message to this address, but the bounce bounced! | | <[EMAIL PROTECTED]>: | 204.68.24.19 does not like recipient. | Remote host said: 552 <[EMAIL PROTECTED]>... User exceed storage quota | Giving up on 204.68.24.19. Is there a way to get qmail to not give up on such messages? Can it be done by configuration or does this require a hack? In cases of exceeding quota, I want outgoing mail to keep trying for just as long as it would in cases of not being able to reach the mail host at all. Yes, I want the mail servers of businesses that host spammers to have their mail servers persistently bounded on for days from all the various places the spammer spewed their filth. They can junk sink hole the box to stop 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]
Re: getting qmail to retry
Sam replied: > On Sun, 10 Oct 1999, Phil Howard wrote: > > > I got this back for a bounced bounce: > > > > | Hi. This is the qmail-send program at ipal.net. > > | I tried to deliver a bounce message to this address, but the bounce bounced! > > | > > | <[EMAIL PROTECTED]>: > > | 204.68.24.19 does not like recipient. > > | Remote host said: 552 <[EMAIL PROTECTED]>... User exceed storage quota > > | Giving up on 204.68.24.19. > > > > Is there a way to get qmail to not give up on such messages? > > Can it be done by configuration or does this require a hack? > > No. The remote server indicated that this is a permanent failure. > Permanent failures get bounced, period. > > > In cases of exceeding quota, I want outgoing mail to keep trying > > for just as long as it would in cases of not being able to reach > > the mail host at all. > > This is not up to you. The remote server responded with a permanent > failure code. The mail gets bounced. I understand that it is a permanent failure code. But clearly a full mailbox is not a true permanent situation (although a spammer case is probably one that not only will not be emptied, but likely to be cut off as well). What I was looking for is if there was a table of response codes and how to act when receiving them. Because of scattered documentation for qmail that means I haven't yet found everything, I'm trying to focus at the moment on what's important now. If it is the case that the answer is "no", then the answer is mapped into being "you'll have to make a hack to do that". I take it you are trying to say that the answer is "no". -- 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]
Re: getting qmail to retry
Sam replied: > On Sun, 10 Oct 1999, Phil Howard wrote: > > > Sam replied: > > > > > On Sun, 10 Oct 1999, Phil Howard wrote: > > > > > > > Is there a way to get qmail to not give up on such messages? > > > > Can it be done by configuration or does this require a hack? > > > > > > No. The remote server indicated that this is a permanent failure. > > > Permanent failures get bounced, period. > > > > > > > In cases of exceeding quota, I want outgoing mail to keep trying > > > > for just as long as it would in cases of not being able to reach > > > > the mail host at all. > > > > > > This is not up to you. The remote server responded with a permanent > > > failure code. The mail gets bounced. > > > > I understand that it is a permanent failure code. But clearly a full > > mailbox is not a true permanent situation (although a spammer case is > > This is not your call. It is the receiving mail server that gets to > decide what is a permanent failure, and what is a temporary failure. But my server can decide whether to bounce it now or requeue it and try again later as if it were a temporary error. > > probably one that not only will not be emptied, but likely to be cut > > off as well). > > > > What I was looking for is if there was a table of response codes and > > how to act when receiving them. > > Well, yes. It's called RFC 822. It specifies that all 4xx error codes > are temporary failures, and that all 5xx error codes are permanent > failures. I mean a programmed table in qmail, where it specifies the internal routines for the action. If such a table is in a config file, I could change it there. If it is in the code, I can change it there. If it's not organized that way, I guess I'll have to code explicit checks. > > Because of scattered documentation > > for qmail that means I haven't yet found everything, I'm trying to > > focus at the moment on what's important now. > > This has nothing to do with Qmail. This is the core definition of SMTP - > that all 5xx error codes are permanent failures, and there's nothing that > Qmail, or any other mail server out there, can do anything about. If > Qmail gets ANY 5xx error code from the remote mail server, it is obligated > to immediately return the message as undeliverable. To do otherwise would > violate RFC 822. My question was how make a change in qmail, not whether my change conformed to the standards. > All properly written mail servers will do that. Qmail is not an issue > here. Perhaps you can persuade usa.net to issue a 422 error instead of a > 522 error for this condition, but I don't think you'll have much success. > usa.net does not want repeated delivery attempts when one of their > mailboxes is full, and it is their call as far as that's concerned. So I'll map 522 to 422, perhaps only if the string "quota", "exceeded", or "full" is present. -- 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]
Re: getting qmail to retry
Sam replied: > On Mon, 11 Oct 1999, Phil Howard wrote: > > > Sam replied: > > > > > On Sun, 10 Oct 1999, Phil Howard wrote: > > > > > > > > This is not up to you. The remote server responded with a permanent > > > > > failure code. The mail gets bounced. > > > > > > > > I understand that it is a permanent failure code. But clearly a full > > > > mailbox is not a true permanent situation (although a spammer case is > > > > > > This is not your call. It is the receiving mail server that gets to > > > decide what is a permanent failure, and what is a temporary failure. > > > > But my server can decide whether to bounce it now or requeue it and try > > again later as if it were a temporary error. > > Then it wouldn't be a server that implements SMTP. In the purest sense, no, it would not be. > > > Well, yes. It's called RFC 822. It specifies that all 4xx error codes > > > are temporary failures, and that all 5xx error codes are permanent > > > failures. > > > > I mean a programmed table in qmail, where it specifies the internal routines > > for the action. If such a table is in a config file, I could change it > > there. If it is in the code, I can change it there. If it's not organized > > that way, I guess I'll have to code explicit checks. > > Of course it's not organized that way, because SMTP servers do not have > any need for that. They just look at the numeric code, 4xx or 5xx, and > take one of two possible actions. It is very possible to configure many server implementations in ways that do not precisely obey the standard protocols. It's then up to the system administrator to "do the right thing". I do know sendmail can be configured to "misbehave". Many server implementations have some aspects of the protocols entirely configurable. Conformance is done by means of the whole of the code and the configuration together. For example, a lookup table for actions to take for each different response code (but I think I mentioned it). Conceivably, a smart MUA could resend mail when it gets a bounce back that it thinks is a temporary condition. In most cases when I get errors trying to deliver mail to people, I don't always assume they have passed away. The difference would be doing this in the MUA vs the MTA. For mail sent by a user, doing it in the MUA makes sense. For bounce mail, there isn't really a separate MUA. The approach I speak of is just a simple hack to effect a similar behaviour. I'm not asking of this conforms to SMTP; I'm asking if it is easy or difficult. I'm now going to assume it's difficult. People who know me know I am not a standards purist. -- 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]
Re: getting qmail to retry
Sam wrote: > =?ISO-8859-1?Q?Claus_F=E4rber?= writes: > > > > On second thought, I really don't want to know what these people want to > > > do with SMTP. Ugh, what a frightening thought... > > > > It's not a new version of SMTP if that is what you're afraid of. It only > > collects some important extensions (such as Extended SMTP/EHLO) and > > clarifications. > > No, it does more than just that. I just read it. My initial suspicions > were correct. So what does it suggest doing that doesn't conform to the standard? -- 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]
Re: HELP - I can't shut off percenthack
Craig Shrimpton wrote: > In desperation I re-patched and re-compiled the server. Now all of a sudden > it's working like it's supposed to. I've seen that kind of weirdness with > DOS C programs but never with a "Unixoid" application. I have, many times. I usually attribute it to things like having applied the instructions slightly incorrectly, or applied my own changes inconsistently. This is why instead of manually installing things, I create a script that does the entire install, starting from untarring the tarball fresh each time it runs. That way I know I have a consistent compile/install each time. If I make changes, I won't "forget" something I did the last time. I installed qmail this way. -- 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]
Re: getting qmail to retry
Sam replied: > On Tue, 12 Oct 1999, Phil Howard wrote: > > > Sam wrote: > > > > > > It's not a new version of SMTP if that is what you're afraid of. It only > > > > collects some important extensions (such as Extended SMTP/EHLO) and > > > > clarifications. > > > > > > No, it does more than just that. I just read it. My initial suspicions > > > were correct. > > > > So what does it suggest doing that doesn't conform to the standard? > > For once thing, the explicit prohibition against content-based rejection > of messages. This is probably as far out of touch with reality as you can > possibly get. According to the draft, if some pissant decides to flood > your server with spam, or even mailbomb you, there's nothing that you can > do about it, according to the draft. > > I'm proud to announce that my mail server will violate this new "standard" > at every possible opportunity. Having not seen that "standard", but just on your description alone, I feel it's a good bet that I will ensure my server violates it, as well. My view of standards has always been that it is about communications and meaning ... syntax and semantics. The 552 code means that the sender is saying that the delivery has encountered a permanent error. It could be lying. Whether it is lying or not, I can take that meaning with a grain of salt, or disregard it altogether. Maybe I know it's a lie and maybe I don't. If I said "My hair is green", that would be an incorrect statement. That it is incorrect does not mean that it violates the conventions of English language to convey meaning. It was conveyed correctly; it's just that the original meaning is false or deceitful. Like English, any of the TCP/IP protocols can be used in potentially false and misleading ways. If I forge the "From:" header, have I violated the RFC822 standard? Some would say yes because the standard meant that it is my originating address. I would say no, because what the standard defines is how to convey a meaning of "This is my originating address" even if I am acting in a deceitful manner to convey false information. Even qmail selectively does such deceit in order to do things like making sure bounces don't loop. I see nothing wrong with it, and not even a violation of the standard. There are others that see it differently. To me, a standard is violated if I fail to convey, within the terms of how the standard said to convey it, the meaning I intended to convey. In HTML, the tag does not say "render this table". It says "this is a table". What to do with the table depends on how you want to be presented with the meaning of the information conveyed in the HTML body. It might be ignored. It might draw graphically. It might be rendered in a text hack. It might launch a spread sheet application. It might get downloaded into your brain. It's not a violation to choose something strange and unusual to do with it. Here's an example of another standard that some have insisted that I have violated. Yet, it works (with the standard browsers running on video modes with 16, 24, or 32 bit color). So far no one has shown a specific part of the standard that was violated, although several have indicated that I have violated certain intents or expectations they believe the designers had. You can see this violation (prepare for a 181779 byte download) at: http://phil.ipal.org/tc.html Actually, I won't announce my intent to violate this new "standard" you spoke of. Instead, I will covertly "violate" it in a "deceitful" way :-) -- 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]
Re: getting qmail to retry
Racer X wrote: > > Conceivably, a smart MUA could resend mail when it gets a bounce back that > > it thinks is a temporary condition. In most cases when I get errors > trying > > to deliver mail to people, I don't always assume they have passed away. > > The difference would be doing this in the MUA vs the MTA. For mail sent > > by a user, doing it in the MUA makes sense. For bounce mail, there isn't > > really a separate MUA. The approach I speak of is just a simple hack to > > effect a similar behaviour. > > you're missing the point. the remote side has already informed you that the > error is permanent and should generate a bounce message. is your MUA so > "smart" that it knows exactly when the error condition will be remedied? No, I have not missed the point. I am intentionally ignoring the point. I do know what the point is. > there are a lot of errors that could conceivably be considered "temporary," > but the determination of whether the error is temporary or permanent should > be determined by the server doing the mail delivery. to assume your client > is smarter than the server, despite the fact that your client knows nothing > about the server, is not only foolish, it defeats the purpose of having > return codes in the first place. I suggest that if it is a violation of the standard to disregard the meaning conveyed in a standardized form (such as SMTP), then it is likewise a violation to assert a false or incorrect meaning. If we are going to look beyond the communication itself and examine the behaviour behind the communication then we must be fair and examine it on both ends. That means that if the MTA receiving the mail conveys an error as permanent, when in fact it is not, then this must be a violation if we are considering that behavious is subject to these rules. I may not know in the instance that the violation has taken place, but I certainly can know (and do know) from actual experience that this violation does take place routinely. I see nothing wrong in conduction like violations in reverse to compensate. -- 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]
Re: getting qmail to retry
Sam wrote: > Here it is. I just went back and looked it up to be sure. Section 2.4.1: > > === >... In general, a relay SMTP SHOULD assume that the > message content it has received is valid and, assuming that the envelope > permits doing so, relay it without inspecting that content. > > === > > Well, this is stated right in the middle of a lengthy discussion on 8bit > message contents/transparency issues, so they might be referring to that > issue alone. Still, something like that just jumps up and grabs your > attention. It didn't say "MUST". So it would not be a violation to inspect the content. But don't expect all the MTAs to inspect the content. -- 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]
Re: getting qmail to retry
David Dyer-Bennet wrote: > Sam <[EMAIL PROTECTED]> writes on 13 October 1999 at 00:50:49 -0400 > > > Here it is. I just went back and looked it up to be sure. Section 2.4.1: > > > > === > >... In general, a relay SMTP SHOULD assume that the > > message content it has received is valid and, assuming that the envelope > > permits doing so, relay it without inspecting that content. > > > > === > > > > Well, this is stated right in the middle of a lengthy discussion on 8bit > > message contents/transparency issues, so they might be referring to that > > issue alone. Still, something like that just jumps up and grabs your > > attention. > > What leaps out at me is that it's about *relaying*, not about > accepting mail for local delivery. > -- > David Dyer-Bennet **Update your records, forwarding expires soon** [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! Good point! -- 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]
Re: Wow, It works! It really works!
Jennifer Tippens wrote: > pop works, qmail works and I love my job. Thank you Everybody for all the > help! (snoopy dance) > > -Jennifer Don't you also want to take some credit for having carefully followed the directions and installed everything right? I did find it to be easier than it initially came across to be. -- 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]
delivery to a directory
How can I tell qmail-local what directory (maildir format) to deliver to? I've got it set up so that for various virtual domains everything is going to a special userid. The .qmail-default file is set to run my program which determines what directory to put the mail in dynamically. Now how to I get it actually delivered there using the maildir logic? I'd like to be able to just CD there, or tell qmail-local where, and have it do it. But it apparently wants to just re-read the .qmail-default file again and loop (stopped by other means I'm sure). Is there a different program for actual final delivery that qmail-local calls that I could cal directly to bypass qmail-local? Please don't suggest lots of userids and/or lots of .qmail files. I'm dead set on making this easy to administer, so those are not options. That's why I'm running things through a program that figures it out. -- 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]
Re: delivery to a directory
Patrick Berry wrote:
> On 11/9/99 at 3:52 PM, [EMAIL PROTECTED] (Phil Howard) had the thought:
>
> > Please don't suggest lots of userids and/or lots of .qmail files. I'm
> > dead set on making this easy to administer, so those are not options.
> > That's why I'm running things through a program that figures it out.
>
> I could be way off base here, but it sounds like your dead set on
> reinventing the wheel. If you have to have a directory for the userid to
> hold the Maildir, what is the problem with having a .qmail file to tell
> qmail to deliver to that Maildir?
There will be hundreds of virtual domains and hundreds of userids in each.
No, make that thousands. Maybe more. What's more, the user names will
be created on the fly, so creating .qmail files in advance for every user
name just isn't possible.
I don't want to add the extra I/O overhead of creating a .qmail file for
each user. I'm trying to make this lean and mean. What I want to do is
divert the .qmail lookup for these virtuals (the ones in virtualdomains
naming this one single base user that handles this whole mess) so that
for each user@domain to be delivered there is _not_ a .qmail file there.
If I could code the master .qmail file like:
# note the single quotes here:
echo './Virtuals/${HOST}/${USER}/' > .qmail
and qmail-local would apply environment substitution, that would do the job.
But that doesn't work. So I'm trying:
echo '|./bin/delivery-to' > .qmail
where the program in bin/delivery-to examines the environment variables
and determines the directory to deliver to (all are owned by the one user
that all this is running under). The next step is to deliver the mail
there (which I'm wanting to avoid re-inventing, since something in qmail
can obviously do it).
There would be a corresponding logic for vchkpw authentication and finding
the directory under the pop3 server, plus a web based access facility to
be developed, too (I'll be doing this in PHP).
--
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]
Re: delivery to a directory
Giles Lean <[EMAIL PROTECTED]> wrote: giles> You've been referred to two programs that can write to maildirs. giles> Writing to maildirs is trivial; you might as well make your own giles> program that decides where the mail should go deliver it as well. ... giles> The maildir format is documented at: giles> giles> http://www.pobox.com/~djb/proto/maildir.html Actually that does look trivial. I guess this does show the virtue of KISS. So I may just write my own and use the same uniquness strategy I'm programming into a web site now, which is Julian Day based and good to 19 Dec 22666. Florian G. Pflug <[EMAIL PROTECTED]> wrote: fgp> There is an explanation for virtualdomains/multiple users with signed system fgp> user/uid on www.qmail.org. I'm not sure I find this or not. I didn't find something literally that, but I found many "virtual" things there. Part of the problem, I think, is that there isn't a precise meaning for "virtual". fgp> It is bases on the users/assign file (in /var/qmail/users/assign). This fgp> files tells qmail where mail to a certain user shall be delivered too (thus fgp> overiding /etc/passwd). This together with the virtualdomains files gives fgp> you excellent support for a _lot_ of domains and a _lot_ of users. Note that fgp> (as far as I remember) the user/assign file is _compiled_ into some sort of fgp> binary file, so it should be fast also with a lot of entries. If it uses /var/qmail/users/assign then it's not what I want, and not what I call virtual. To me, one of the attributes of virtual is that there is no table of mapping between a user e-mail address and where to deliver, but instead, the determination of where to deliver is a functional relation to the e-mail address. I want the very minimum of administrative work to manage it. This will require such things as automatically deriving the user authentication data from the customer account database. I expect to write something that will rebuild certain files (password CDB, rcpthosts, virtualdomains) from the data obtained from the database. fgp> I am using this setup, and things are quite fast. I still have a .qmail file fgp> for each user in his directory (/home/popuser/$DOMAIN/$USER), because you fgp> need this for forwarding, starting mail notifying scripts, etc. But if you fgp> just want to deliver to his Maildir/Mailbox you don´t need those .qmail fgp> files. I don't want a .qmail file for each user (except for local host users). If by leaving it out I can deliver to each users's maildir, that' what I want. At the same time there may be a catch. The default delivery for the local host (e.g. listed in locals, for users in /etc/passwd, with distinct uids), is not maildir, but "./Mailbox". I need to be able to leave local users as all "./Mailbox" by default (unless overridden in a .qmail file for each user individually), yet have maildirs used for all the virtualdomains users without creating zillions of .qmail files. Local users will NOT (at least we do not need to offer) have their e-mail available by POP3 (or IMAP4 when that gets added to the mix). If the address identifies the local host name, it goes to the shell account only, for shells on the same machine as the general POP3 service (these are just staff shells, anyway, not customer shell accounts, which would be on a separate machine with a more conventional non-virtual setup). fgp> I have writting a small webinterface for the administration of this (you can fgp> add domains, add users to domain, set their pop-password, add forwards to fgp> users,...). It is a quick and dirty hack (it´s a bunch of shell scripts!), fgp> but it works for me - you can have it, if you want to (maybe you want to do fgp> the necesary perl rewrite?? ;- ) We'll be doing the web interface for administration as an integral part of the whole internet service administration, working through a central database that records every service, not just e-mail. E-mail configuration will then be derived from that database much like web configuration, DNS configuration, and so forth. I will be able to add a new customer, specify domains, and let them add their own users and subdomains, and it will automatically set up their e-mail, radius for dialup, routing for dedicated DSL, web service, and whatever else (the exact system hasn't been chosen, yet). -- 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]
Re: delivery to a directory
Florian G. Pflug wrote: > > I'm not sure I find this or not. I didn't find something literally that, > > but I found many "virtual" things there. Part of the problem, I think, is > > that there isn't a precise meaning for "virtual". > Well.. you are right - but "virtualdomain" ist quite precise, if you stay in > the qmail context ;-) How about "virtualusers". What I am looking at doing will include fuzzy matching of existing users from a database, and optionally users don't need to exist to be delivered. > > If it uses /var/qmail/users/assign then it's not what I want, and not what I > > call virtual. To me, one of the attributes of virtual is that there is no > > table of mapping between a user e-mail address and where to deliver, but > > instead, the determination of where to deliver is a functional relation to > > the e-mail address. > It´s virtual, the same as you have "virtual" http-hosts... There's virtual by IP, virtual by Host, and I've twisted both concepts around using some CGI code, too. > But I guess I know what you want - from the address [EMAIL PROTECTED], you > want the mail to be stored in "/somepath/domain.com/user" - not a > "static" mapping, "calculated" from the address? Then you could think about > patching/rewriting qmail-local - altough maybe you should hink about writing > you own smtp-server/mda for that purpose. That's the point I want to start from. Then from there employ more ideas to change it even further. It looks like maildir is so simple I can just do the delivery right in my own code. I won't have to parse any headers. And presumebly, what qmail-local pipes to my program is exactly what goes in the file, so it should be trivial. > jes - create /users/assign from the database.. ;-)) There will be a many-to-one relationship in the address to mailbox mapping. So this is probably not scalable. > > At the same time there may be a catch. The default delivery for the local > > host (e.g. listed in locals, for users in /etc/passwd, with distinct uids), > > is not maildir, but "./Mailbox". I need to be able to leave local users as > > all "./Mailbox" by default (unless overridden in a .qmail file for each user > > individually), yet have maildirs used for all the virtualdomains users without > > creating zillions of .qmail files. > you could make .qmail files for local users, overiding the Maildir default > to Mailbox - or just take one machine for all those thousands of users and > "virtual"domains, and another one for the shell accounts. The shell accounts won't go through my delivery program. But if my program does the actual maildir create/write/link/delete steps, then it won't matter what the default is, which can stay Mailbox ... everything going through my program will be maildir anyway. I just need to make sure I'm not going to run into something unexpected. > > We'll be doing the web interface for administration as an integral part of > > the whole internet service administration, working through a central database > > that records every service, not just e-mail. E-mail configuration will then > > be derived from that database much like web configuration, DNS configuration, > > and so forth. I will be able to add a new customer, specify domains, and > > let them add their own users and subdomains, and it will automatically set > > up their e-mail, radius for dialup, routing for dedicated DSL, web service, > > and whatever else (the exact system hasn't been chosen, yet). > Wow.. Zero Administration ISP - sounds quite cool. Yeah ... put myself out of a job. -- 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]
Re: log rotation
I'd also kinda annoying for us cut&paste double clickers because the highlight stops at characters not commonly found in file names. When I get around to it, and I don't know how long that will be ... might be a while ... my intent is to make my own version of cyclog that names files by date/time or day/time, and cuts files on time frames instead of size. It will also be able to launch a child to compress/archive the closed file. Steve Kapinos wrote: > How about using file names that I can actually type without having to use '' > characters, etc? I'm confused why you'd pick a log name you can't easily > input. > > -Steve > > -- > >From: Russell Nelson <[EMAIL PROTECTED]> > >To: qmail <[EMAIL PROTECTED]> > >Subject: Re: log rotation > >Date: Fri, Nov 12, 1999, 11:54 AM > > > > > [EMAIL PROTECTED] writes: > > > Is there a way to make cyclog use a bit more intuitive file name? > > > @4937823749383 and @43948389393 just don't do it for me. > > > > No. Logfiles are rolled over based on their size, not their date. > > Write a front-end. > > > > -- > > -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! > > > -- 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]
Re: log rotation
waskita adijarto wrote: > On Fri, 12 Nov 1999 [EMAIL PROTECTED] wrote: > > > Date: Fri, 12 Nov 1999 11:48:09 -0500 (EST) > > From: [EMAIL PROTECTED] > > To: waskita adijarto <[EMAIL PROTECTED]> > > Cc: qmail <[EMAIL PROTECTED]>, Brian Estes <[EMAIL PROTECTED]> > > Subject: Re: log rotation > > > > Is there a way to make cyclog use a bit more intuitive file name? > > @4937823749383 and @43948389393 just don't do it for me. > > from 'man cyclog': > The name of a log file is the TAI timestamp when the file > was started. The mode of the file is 444 if it has been > safely written to disk, 644 otherwise. A log file that > has not been written to disk is not guaranteed to survive > a system crash. > > you can use 'tailocal' to make the filename a little bit more intuitive. > don't forget to remove the '@' first. Maybe what he really wanted was a different format of file name such as 1999-1112-2200 or some such thing. That way he can archive logs and go back and find a specific one by it's date and time. -- 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]
Mailbox and atime
I've found a small glitch between qmail and the way my system is tuned. The "noatime" feature is enabled for high volume filesystems, which has improved performance. Since going with qmail, this has also caused a problem with detecting new mail. The "noatime" was not used in /var/spool and I'd like to leave it turned on in /home. But obviously, it is needed wherever the mailbox files actually are. What is the feasibility of moving the mailboxes out of the home directory, maybe back to /var/spool, and just having a symlink in the home directory pointing to where the mail really goes? Would qmail have a problem with this for mailbox format? Would it be better to use .qmail files to point there instead? Is there a way to do this in the default specification so the path is formed in a way unrelated to the home directory, but formed from the username? -- 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]
pre-filtering mail before delivery
I would like to pre-filter mail before delivery. Since I want to do this both for mail to be locally delivered as well as mail to be relayed, it would seem I need to do that at qmail-send or earlier. I could live with locally originated mail not being filtered, so qmail-smtpd is not out of the question. I just don't know which would be the best place. The nature of the filtering will not be to alter the content nor to alter the delivery address. This will be anti-spam filtering, and will either allow the mail to pass, or reject it. If rejected, I'd like to cause it to send mail back to the apparent appropriate return address. Doing this as one procress per message would be best, I believe. Can someone suggest the best place to do this? I can modify source code and add what I need, but I don't know enough of the implications of the flow of activity in qmail to know if one place is better than another for some reason. -- | Phil Howard - KA9WGN | My current boycotts: Amazon.Com, DVDs, Mattel, Sony | [EMAIL PROTECTED] + | Dallas - Texas - USA | My current websites: linuxhomepage.com, ham.org
