qmail Digest 4 May 2001 10:00:01 -0000 Issue 1354
Topics (messages 61880 through 61964):
Bug? in qmail-inject: QMAILINJECT=f ruins resent mails
61880 by: Jost.Krieger.ruhr-uni-bochum.de
Re: [ezmlm] lock: file does not exist
61881 by: peter green
61886 by: Karsten W. Rohrbach
strange behaviour at (some) virtual domains..
61882 by: Anton Pirnat
Re: adresses
61883 by: Hans Sandsdalen
Can MX record be CNAME?
61884 by: Peter Peltonen
61890 by: Charles Cazabon
61893 by: q question
61894 by: q question
61896 by: Charles Cazabon
61897 by: James Raftery
61901 by: Markus Stumpf
61902 by: Kris von Mach
61905 by: Charles Cazabon
61908 by: Kris von Mach
61910 by: Charles Cazabon
61911 by: Greg White
61913 by: q question
61918 by: q question
61920 by: Charles Cazabon
61924 by: Charles Cazabon
61925 by: Henning Brauer
61928 by: Kris von Mach
61937 by: Charles Cazabon
61938 by: Peter van Dijk
61939 by: Colin Palmer
61940 by: Timothy Mayo
61943 by: Aaron Goldblatt
61945 by: Tim Legant
61946 by: q question
61947 by: q question
61948 by: q question
61949 by: Markus Stumpf
61950 by: Scott D. Yelich
61961 by: Henning Brauer
61962 by: Peter Peltonen
61963 by: Henning Brauer
autoresponder inter7.com again
61885 by: Flavio Alberto
Re: timeout downloading mail while connecting to the server using dial-up
61887 by: Charles Cazabon
Re: how to run two qmail-smtpd
61888 by: Charles Cazabon
Re: Qmail as only relay
61889 by: Charles Cazabon
Re: SPAM Patches recomendations.
61891 by: q question
61892 by: Charles Cazabon
61895 by: q question
61898 by: Chris Garrigues
61903 by: Charles Cazabon
61907 by: Greg White
61912 by: Alan Clegg
61914 by: q question
61915 by: q question
61916 by: q question
61919 by: Charles Cazabon
error with sqwebmail
61899 by: Brendan McAlpine
R: Qmail as only relay
61900 by: Andrea Cerrito
qmail and multiple MX records
61904 by: Van Liedekerke Franky
EMail to all my users
61906 by: Fares Gianluca
61923 by: Stephen Berg
forwarding to a dynamic / variable address ??
61909 by: Kim Chr. Hvidkjaer
61917 by: Charles Cazabon
61922 by: Wagner Teixeira
61931 by: Brett
concurrency and bccs
61921 by: Brett
61927 by: Charles Cazabon
FromMail.pl
61926 by: Flavio Alberto
61934 by: Brett
61935 by: Olivier M.
R: error with sqwebmail
61929 by: Andrea Cerrito
61941 by: Henning Brauer
Re: Limit outbound connections but not for all domains
61930 by: Puneet Narang
61933 by: Charles Cazabon
Re: Both system account and virtual account of one domain.
61932 by: Keary Suska
Re: Strange Bounce
61936 by: Marco Calistri
Re: open BSD
61942 by: Stefan Laudat
qmail-smtpd, qmail-send and multiple IP addresses
61944 by: Darcy Buskermolen
How to increase the qmail "concurrency"?
61951 by: Chris
61953 by: Chris Johnson
61954 by: Jason Brooke
61956 by: Dan Phoenix
61957 by: Jason Brooke
Missing step in qmail+mysql! pls help!
61952 by: Foo Ji-Haw
Huge Maildirs?
61955 by: List Monkey
61958 by: Robin S. Socha
manually run queue
61959 by: henrik.troeng.ekakan.com
61960 by: Sean Chittenden
R: manually run queue
61964 by: Andrea Cerrito
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]
----------------------------------------------------------------------
As old unix "MUA"s have the habit of providing a from line of "[EMAIL PROTECTED]" and, even with new MUAs, user can't be bothered to configure them correctly, we set up the following environment variables in /etc/profile and such: QMAILHOST QMAILUSER QMAILINJECT=f This usually works nicely for the vintage MUAs, and doesn't do anything bad with sensible MUAs like mutt or Gnus. But: If you are resending a message to someone else with a sensible MUA, it will add Resent-From: etc. headers. Then qmail-inject goes ahead and removes the original From: header (beacuse of QMAILINJECT=f) and looks if it must add a new Resent-From: header (it doesn't need to) and the mail is sent without any From: header at all. So: 1. If you are using a sensible client, be smart enough to unset QMAILINJECT. 2. qmail-inject could be enhanced by making the process of removing and adding headers more symmetrical. 3. It could be termed a bug because qmail-inject shouldn't produce a non-RFC 2?822 message, with no regard to the setting of QMAILINJECT. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
* Peter Peltonen <[EMAIL PROTECTED]> [010503 04:41]: > > If you do not have the ezmlm-idx patch applied you may try > > xargs ezmlm-sub /path/to/list <adress.txt > > This works! But none of the examples mentioned before. And I *have* the idx > patch: > > $ rpm -qa |grep ezmlm > ezmlm-idx-mysql-0.53.324-1 > > Strange...? Expected. The xargs is required for ezmlm-idx < 0.400 and not for >= 0.400. (This is, of course, a good argument for why you should submit version numbers when reporting a ``bug''.) /pg -- Peter Green : Architekton Internet Services, LLC : [EMAIL PROTECTED] --- >You know you are "there" when you are known by your first name, and >are recognized. >Lemmie see, there is Madonna, and Linus, and ..... help me out here! Bill ? ;-) (From some postings on comp.os.linux.misc)
Markus Stumpf([EMAIL PROTECTED])@2001.05.02 21:16:32 +0000: > On Wed, May 02, 2001 at 08:30:12PM +0200, Karsten W. Rohrbach wrote: > > Peter Farmer([EMAIL PROTECTED])@2001.05.02 15:50:13 +0000: > > 1) > > thats the same like 'ezmlm-sub /path/to/list <adress.txt' but wastes > > more system resources by creating the process environment for cat. > > This will *NOT* work (neither of both commands) with a vanilla ezmlm. > You need the ezmlm-idx patch for that. > If you do not have the ezmlm-idx patch applied you may try > xargs ezmlm-sub /path/to/list <adress.txt yup, i read about that one after writing the mail. i use -idx 0.40 and it worked ;-) > > In any case ezmlm-sub will stop processing the bulk if it encounters an invalid > email address (e.g. addresses containing spaces which will result in > email addresses withou an '@' sign). yup, that's what i wrote. > As "xargs" may start "ezmlm-sub" more than one time you may encounter > the problem that only a portion of the bulk is missing (i.e. the one > that contained an invalid address). let's call that an improvement. actually seeing a nonfatal error would be a good thing[tm]. /k -- > "The path of excess leads to the tower of wisdom." -- W. Blake KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de [Key] [KeyID---] [Created-] [Fingerprint-------------------------------------] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
we are using a qmail, vpopmail server (default install, no locals only virtual domains and roaming users enabled) and some of our customers do have more than one domain. In this cases our last sysadmin made a symlink instead of using the virtualdomains control file. He just added the domain using vadddomain, then deleted the domain dir and made a ln -s .. This way it was working well. rcpthosts did contain some like.. -- domain1.tld domain2.tld -- and virtualdomains did contain.. -- domain1.tld:domain1.tld domain2.tld:domain2.tld --- Now i wanted to remove this links and add the domains in my virtualdomains file instead, but it only works for some of the domains!!! so i did remove the ln and did change the virtualdomaisn file it now shows some like.. -- domain1.tld:domain1.tld domain2.tld:domain1.tld --- This is made for umm..4-5 main domains, and in near all cases it works. Even not in all of them!!! In two cases it does not work, and i have no clue why it doesnīt work! I also did check our NS, and a lookup works well for all domains. I all cases it point to the main domain IP. However qmail wont accept mails and bounces them back.. ..a part of the failure message i get back.. --- Hi. This is the qmail-send program at mail.pop-stuttgart.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: lange:blueflame.com:blueflame.de --- Below this line is a copy of the message. --- in this case i had blueflame.de and blueflame.com in my rcpthosts.. and blueflame.com:blueflame.com and blueflame.de:blueflame.com in my virtualdomains file. The strange part is, it works for other domains, even not for this and a 2.nd one. Maybe there is someout out i am missing? Any hints/tips out there? regards from South Germany Anton Pirnat
Frank Tegtmeyer wrote: > Hans Sandsdalen <[EMAIL PROTECTED]> writes: > > Also, how can I make qmail modify aTo address without @ sign the same > > way? > > Have a look at new-inject and ofmipd from the mess822 package. > > Regards, Frank Thank you. Seem ok. -- / hans - http://www.spacetec.no/~hans / http://www.spacetec.no/~hans/dfood.htm /--------------------------------------------- / HANS = High Availability No Superman
I have a mail server with A record a.b.c and PTR record 1.2.3.4. The MX record says naturally a.b.c too. I want to change the servers dns name to mail.b.c. Unfortunately I do not control my PTR records so I have to do the dns name change with CNAME. My questions are: Can MX record point to a CNAME? Or maybe I should use multiple A records? In both cases, what do I put in /var/qmail/control/me? The same name as in the MX record? Peter
Peter Peltonen <[EMAIL PROTECTED]> wrote: > > I have a mail server with A record a.b.c and PTR record 1.2.3.4. The MX record > says naturally a.b.c too. > > I want to change the servers dns name to mail.b.c. This would have been easier if you'd used real names. However... > Unfortunately I do not control my PTR records so I have to do the dns name > change with CNAME. > > My questions are: > > Can MX record point to a CNAME? No, never. > Or maybe I should use multiple A records? Yes. > In both cases, what do I put in /var/qmail/control/me? The same name as in the > MX record? Sure. 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. -----------------------------------------------------------------------
>This would have been easier if you'd used real names. However... Charles, Why did you tell Peter this would have been easier if he had used real names? I found it very clear and frankly I prefer a.b.c and 1.2.3.4 to reading full domain names and ip numbers when the shorthand can convey the point clearly. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
>This would have been easier if you'd used real names. However... Charles, Why did you tell Peter this would have been easier if he had used real names? I found it very clear and frankly I prefer a.b.c and 1.2.3.4 to reading full domain names and ip numbers when the shorthand can convey the point clearly. * * * | 1) It's SLOW! --> "man tcpserver" - especially -R,-H,-l qmail | 2) Roaming users --> http://www.lifewithqmail.org/lwq.html#relaying FAQS | 3) Secondary MX --> list in rcpthosts, NOT in locals/virtualdomains * * * | 4) Discard mail --> "#" line ONLY, in appropriate .qmail file _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
q question <[EMAIL PROTECTED]> wrote: > >This would have been easier if you'd used real names. However... > > Why did you tell Peter this would have been easier if he had used real > names? Because I believe that it would have been clearer if he had used real names? My eyes quickly get tired of trying to distinguish "a.b.c" and "foo.b.c" and "foo.a.b.c", etc, etc... 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. -----------------------------------------------------------------------
On Thu, May 03, 2001 at 10:14:38AM -0500, q question wrote: > Why did you tell Peter this would have been easier if he had used real > names? I found it very clear and frankly I prefer a.b.c and 1.2.3.4 to > reading full domain names and ip numbers when the shorthand can convey the > point clearly. Because giving real information is *always* right. Giving mangled information is *rarely* right. james -- James Raftery (JBR54) "It's somewhere in the Red Hat district" -- A network engineer's freudian slip when talking about Amsterdam's nightlife at RIPE 38.
What Charles said is totally correct, however I do not understand: On Thu, May 03, 2001 at 08:34:04AM -0600, Charles Cazabon wrote: > Peter Peltonen <[EMAIL PROTECTED]> wrote: > > Unfortunately I do not control my PTR records so I have to do the dns name > > change with CNAME. What do - in this context - have PTR records to do with CNAMEs?? Just to make it clear, a MX record MAY NOT point to a CNAME nor to an A record, it always has to be a FQDN (which points to an A record). Speaking bind config it is invalid to have: blubb IN MX 100 1.2.3.4 blubb IN MX 100 mail mail IN CNAME exa exa IN A 1.2.3.4 \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
At 08:34 AM 5/3/2001 -0600, you wrote: > Unfortunately I do not control my PTR records so I have to do the dns name > change with CNAME. > > My questions are: > > Can MX record point to a CNAME? No, never. Charles, Why can't it be a CNAME? Is there a reason for this? I am currently using it as a CNAME and it's been working fine for a year or so... If there is a good reason for it, I sure would like to know so I can make changes. Thanks, __ Kris.
Kris von Mach <[EMAIL PROTECTED]> wrote: > > > Unfortunately I do not control my PTR records so I have to do the dns > > > name change with CNAME. My questions are: Can MX record point to a > > > CNAME? > > No, never. > Why can't it be a CNAME? Because it is forbidden by the RFCs. > Is there a reason for this? There are several technical reasons for this; read RFC2821 for some brief explanations, or possibly RFC821. Although I've read the recently released 2821, I do not specifically recall if they left that part of 821 in. 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. -----------------------------------------------------------------------
At 08:34 AM 5/3/2001 -0600, you wrote: > > Unfortunately I do not control my PTR records so I have to do the dns name > > change with CNAME. > > > > My questions are: > > > > Can MX record point to a CNAME? > >No, never. Charles, Why can't it be a CNAME? Is there a reason for this? I am currently using it as a CNAME and it's been working fine for a year or so... If there is a good reason for it, I sure would like to know so I can make changes. Oh I have this currently: IN NS ns1.webgoku.com. IN NS ns2.webgoku.com. IN MX 10 mail.swishmail.com. $ORIGIN swishmail.com. ; ; Setup forward DNS for all hosts IN A 63.165.246.3 www IN A 63.165.246.3 ftp IN CNAME swishmail.com. mail IN CNAME swishmail.com. Or did you mean that you can't have something like this: IN MX 10 mail IN A 63.165.246.3 www IN A 63.165.246.3 mail IN CNAME swishmail.com. Thanks, __ Kris.
Kris von Mach <[EMAIL PROTECTED]> wrote: > > > Can MX record point to a CNAME? > >No, never. > Oh I have this currently: > > IN NS ns1.webgoku.com. > IN NS ns2.webgoku.com. > IN MX 10 mail.swishmail.com. > $ORIGIN swishmail.com. > ; > ; Setup forward DNS for all hosts > IN A 63.165.246.3 > mail IN CNAME swishmail.com. Nope, "mail.swishmail.com" cannot be a CNAME if you want to point your MX record at it. It's forbidden. And please don't post BIND zonefiles to Dan's lists -- they're meaningless to anyone who doesn't do BINDthink. Instead, tell us what's happening ("mail.foo.net is an MX record which points to mail.bar.org with distance 10, which has an A record of 10.20.30.40"). That at least means something to everyone who understands a little about DNS. 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. -----------------------------------------------------------------------
On Thu, May 03, 2001 at 12:53:44PM -0400, Kris von Mach wrote: > At 08:34 AM 5/3/2001 -0600, you wrote: > > Unfortunately I do not control my PTR records so I have to do the dns name > > change with CNAME. > > > > My questions are: > > > > Can MX record point to a CNAME? > CC --> No, never. > > Charles, > > Why can't it be a CNAME? Is there a reason for this? I am currently using it > as a CNAME and it's been working fine for a year or so... If there is a good > reason for it, I sure would like to know so I can make changes. It's not actually a _violation_, as such, but RFC1034 (one of the DNS specification RFCs) says that: "If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types." This means that pointing MX, NS, and SOA (at least) at a CNAME is not recommended. Personally, I hate CNAME, and I almost never use it. I can think of only one specialized use where CNAME comes in handy (third-party hosting). Nearly everything else can be done more efficiently with multiple A records IMHO. P.S. If someone has a reference to an RFC which says 'must not' rather than 'should not', I'll be happy to use it from now on. :)
Charles and James, Some people may have private domains that they don't wish to disclose. These people are usually advanced enough to do a clear job with generic a.b.c notation. I agree that novices probably should stick to the full domain names because they are probably too confused to translate correctly into generic a.b.c notation. >From: James Raftery <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Can MX record be CNAME? >Date: Thu, 3 May 2001 16:45:27 +0100 > >On Thu, May 03, 2001 at 10:14:38AM -0500, q question wrote: > > Why did you tell Peter this would have been easier if he had used real > > names? I found it very clear and frankly I prefer a.b.c and 1.2.3.4 to > > reading full domain names and ip numbers when the shorthand can convey >the > > point clearly. > >Because giving real information is *always* right. Giving mangled >information is *rarely* right. > >james >-- >James Raftery (JBR54) > "It's somewhere in the Red Hat district" -- A network engineer's > freudian slip when talking about Amsterdam's nightlife at RIPE 38. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
>Nope, "mail.swishmail.com" cannot be a CNAME if you want to point your MX >record at it. It's forbidden. > >And please don't post BIND zonefiles to Dan's lists -- they're meaningless >to >anyone who doesn't do BINDthink. Instead, tell us what's happening >("mail.foo.net is an MX record which points to mail.bar.org with distance >10, >which has an A record of 10.20.30.40"). That at least means something to >everyone who understands a little about DNS. 1) I appreciated Kris's short excerpt from his BIND zonefiles. They were exactly what I needed to see to understand what Kris was saying about his CNAMES. 2) I find the sentence format that describes what is happening "mail.foo.net is an MX record which points to ..." to be more confusing than seeing the exact records. 3) The people that don't do BINDthink aren't going to understand either the sentence format or the exact record layout. I think people either know or don't know DNS, and they don't fall into a middle ground that can be addressed by the sentence layout. 4) You have stated repeatedly that people must provide detailed information in their emails to this list. Kris did so, and you protest that it is too detailed. You really can't have it both ways. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
q question <[EMAIL PROTECTED]> wrote: > Charles and James, > > Some people may have private domains that they don't wish to disclose. These > people are usually advanced enough to do a clear job with generic a.b.c > notation. Which is pointless. You can't receive mail without advertising the domain in the DNS, so trying to hide the information here achieves precisely nothing. Hiding the domain here just makes the job of list members tougher. I encourage everyone to ignore messages with falsified domain information or logs. 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. -----------------------------------------------------------------------
q question <[EMAIL PROTECTED]> wrote: > > > > And please don't post BIND zonefiles to Dan's lists -- [...] > > Instead, tell us [the contents of the DNS records] > 4) You have stated repeatedly that people must provide detailed information > in their emails to this list. Kris did so, and you protest that it is too > detailed. You really can't have it both ways. I didn't mean "don't give us the DNS information". I meant "give us the DNS information in a format that does not require an intimiate knowledge of BIND zonefile format". After all, you don't need to know anything about BIND to be a knowledgable mail admin. You just need to understand some DNS basics. I, unfortunately, have had to learn a bit here and there about BIND zonefiles, but I still prefer the information in a non-proprietary format. BINDthink is painful, and in this list, completely unnecessary. 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. -----------------------------------------------------------------------
On Thu, May 03, 2001 at 02:04:55PM -0500, q question wrote: > 3) The people that don't do BINDthink aren't going to understand either the > sentence format or the exact record layout. I think people either know or > don't know DNS, and they don't fall into a middle ground that can be > addressed by the sentence layout. Knowing DNS does not necessary mean knowing BIND. qmail's autor has written a replacement using another (IMHO much better) format. Please stop this useless flaming. You aren't posting anything usefull, just flaming charles. This is a technical discussion list, no smalltalk. Either provide answers or participate in technical discussions or shut up. -- Henning Brauer | BS Web Services Hostmaster BSWS | Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
At 11:09 AM 5/3/2001 -0700, you wrote: >This means that pointing MX, NS, and SOA (at least) at a CNAME is not >recommended. Personally, I hate CNAME, and I almost never use it. I can >think of only one specialized use where CNAME comes in handy >(third-party hosting). Nearly everything else can be done more >efficiently with multiple A records IMHO. So, having multiple A records pointing to the same IP is ok then, when it comes to MX? like this: IN MX 10 mail.swishmail.com. $ORIGIN swishmail.com. ; Setup forward DNS for all hosts IN A 63.165.246.3 www IN A 63.165.246.3 mail IN A 63.165.246.3 ftp IN A 63.165.246.3 pop3 IN CNAME swishmail.com. Or should MX mail.swishmail.com point to an IP address that nothing else points to? like for example: IN MX 10 mail.swishmail.com. $ORIGIN swishmail.com. ; Setup forward DNS for all hosts IN A 63.165.246.3 www IN A 63.165.246.3 mail IN A 63.165.246.5 ftp IN A 63.165.246.3 pop3 IN CNAME swishmail.com. The reason why I am asking is would mail.swishmail.com be considered FQDN with the first example? Since mail.swishmail.com would resolve to 63.165.246.3, but 63.165.246.3 would resolve to swishmail.com. With the second example, forward and reverse would give you mail.swishmail.com -> 63.165.256.5 and 63.165.256.5 -> mail.swishmail.com __ Kris.
Kris von Mach <[EMAIL PROTECTED]> wrote: > > So, having multiple A records pointing to the same IP is ok then, when it > comes to MX? Yes. > Or should MX mail.swishmail.com point to an IP address that nothing else > points to? like for example: No, not necessary. > The reason why I am asking is would mail.swishmail.com be considered FQDN > with the first example? Yes. > Since mail.swishmail.com would resolve to 63.165.246.3, but 63.165.246.3 > would resolve to swishmail.com. With the second example, forward and reverse > would give you mail.swishmail.com -> 63.165.256.5 and 63.165.256.5 -> > mail.swishmail.com That doesn't matter for SMTP. Why don't you try it and see? 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. -----------------------------------------------------------------------
On Thu, May 03, 2001 at 04:39:32PM -0400, Kris von Mach wrote: > At 11:09 AM 5/3/2001 -0700, you wrote: > >This means that pointing MX, NS, and SOA (at least) at a CNAME is not > >recommended. Personally, I hate CNAME, and I almost never use it. I can > >think of only one specialized use where CNAME comes in handy > >(third-party hosting). Nearly everything else can be done more > >efficiently with multiple A records IMHO. > > So, having multiple A records pointing to the same IP is ok then, when it > comes to MX? Yes. > Or should MX mail.swishmail.com point to an IP address that nothing else > points to? like for example: Not necessary. Greetz, Peter.
On Thu, 3 May 2001, Kris von Mach wrote: > Why can't it be a CNAME? Is there a reason for this? I am currently using it > as a CNAME and it's been working fine for a year or so... If there is a good > reason for it, I sure would like to know so I can make changes. The CNAME RR means "this machine's function has now been replaced by this other machine", which is fine if you want to allow people to keep using the old name for a service, but you should update your MX records to point to its new one. Also chasing down CNAMEs increases the work that has to be done for each message. And, which qmail usually manages to handle them sensibly, they can cause it problems when it's talking to other popular MTAs that think CNAME records are illegal in all header lines > Oh I have this currently: <snip> > Or did you mean that you can't have something like this: > > IN MX 10 mail > IN A 63.165.246.3 > www IN A 63.165.246.3 > mail IN CNAME swishmail.com. Doesn't that achieve the same effect as your previous example? bind really should reject this unless you've set an option to let it pass with just a warning. You should have this instead: $origin swishmail.com. IN MX 10 mail IN A 63.165.246.3 www IN A 63.165.246.3 mail IN A 63.165.246.3 (you should also consider djbdns for your own servers, which makes it harder to make mistakes like that in the first place. But that's best argued elsewhere) --Colin Colin Palmer -- [EMAIL PROTECTED] -- http://raccoon.osoal.org.nz/ Systems Engineer -- [One Short Of A Llama] http://web.osoal.org.nz/
On Thu, May 03, 2001 at 04:39:32PM -0400, Kris von Mach wrote: > > So, having multiple A records pointing to the same IP is ok then, when it > comes to MX? > > like this: > > IN MX 10 mail.swishmail.com. > $ORIGIN swishmail.com. > ; Setup forward DNS for all hosts > IN A 63.165.246.3 > www IN A 63.165.246.3 > mail IN A 63.165.246.3 > ftp IN A 63.165.246.3 > pop3 IN CNAME swishmail.com. > > > Or should MX mail.swishmail.com point to an IP address that nothing else > points to? like for example: > > IN MX 10 mail.swishmail.com. > $ORIGIN swishmail.com. > ; Setup forward DNS for all hosts > IN A 63.165.246.3 > www IN A 63.165.246.3 > mail IN A 63.165.246.5 > ftp IN A 63.165.246.3 > pop3 IN CNAME swishmail.com. > > > The reason why I am asking is would mail.swishmail.com be considered FQDN > with the first example? Since mail.swishmail.com would resolve to > 63.165.246.3, but 63.165.246.3 would resolve to swishmail.com. With the > second example, forward and reverse would give you mail.swishmail.com -> > 63.165.256.5 and 63.165.256.5 -> mail.swishmail.com > Both are acceptable and are considered FQDNs. FQDNs are only required to point to IPs. It says nothing about the IP pointing back to the FQDN. -- --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior System Administrator The National Business Network Inc. localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
>So, having multiple A records pointing to the same IP is ok then, when it >comes to MX? MX records are considered and resolved separately from A records. With respect to the remainder of your question, reverse resolution isn't a necessary consideration. For example: mail.goldblatt.net -- 208.190.130.82. It reverses to wndrgrl.goldblatt.net. It still works. One issue to consider, if you're using Bind, is future maintainability. Consider what might happen if you renumber your network. If you are using a.b.c.d notation in your MX record, you must remember to update that record in addition to all your A records. If you use mail.whatever.com in your MX record, you have only to update your A record, which makes it less likely that in the event of a renumber, you'll screw it up and cut off mail service for a week. The down side is that this approach must, of necessity, produces another lookup for the A record, which produces additional load on your name servers and network to carry the UDP traffic. ag
On Thu, May 03, 2001 at 05:32:52PM -0500, Aaron Goldblatt wrote: > If you use mail.whatever.com in your MX record, you have only to update > your A record, which makes it less likely that in the event of a renumber, > you'll screw it up and cut off mail service for a week. The down side is > that this approach must, of necessity, produces another lookup for the A > record, which produces additional load on your name servers and network to > carry the UDP traffic. In most cases, no. With some minor quibbles, as long as the nameserver is authoritative for your domain (which it had better be!) and both records (the MX and the A) are known to the nameserver, the nameserver will provide the A record as glue when the MX is requested. Using djbdns, here is a query for mx records for my domain, catseye.net: $ dnsq mx catseye.net ns1.catseye.net 15 catseye.net: 152 bytes, 1+2+2+2 records, response, authoritative, noerror query: 15 catseye.net answer: catseye.net 86400 MX 10 mail.catseye.net answer: catseye.net 86400 MX 20 mail.whatwerks.com authority: catseye.net 172800 NS ns1.catseye.net authority: catseye.net 172800 NS ns1.whatwerks.com additional: mail.catseye.net 86400 A 64.34.131.193 additional: ns1.catseye.net 86400 A 64.34.131.193 See the "additional" records? That all came back in one query and, since I'm authoritative, the dns resolver library can trust the glue, which means you don't need a second query. Note that I'm *not* authoritative for my backup, whatwerks.com, so the nameserver didn't provide glue for mail.whatwerks.com. Tim -- * * * | 1) It's SLOW! --> "man tcpserver" - especially -R,-H,-l qmail | 2) Roaming users --> http://www.lifewithqmail.org/lwq.html#relaying FAQS | 3) Secondary MX --> list in rcpthosts, NOT in locals/virtualdomains * * * | 4) Discard mail --> "#" line ONLY, in appropriate .qmail file
>Which is pointless. You can't receive mail without advertising the domain >in >the DNS, so trying to hide the information here achieves precisely nothing. That's not true. I've dealt with plenty of internal corporate email situations that are not exposed to the internet email. Not all email goes out on the internet. >Hiding the domain here just makes the job of list members tougher. I >encourage everyone to ignore messages with falsified domain information or >logs. I think everyone should be free to describe their situation using either generic a.b.c notation or valid domain addresses. Granted, if you are a novice, it is preferred that you use the valid domain addresses because you may incorrectly use the wrong generic addressing. * * * | 1) It's SLOW! --> "man tcpserver" - especially -R,-H,-l qmail | 2) Roaming users --> http://www.lifewithqmail.org/lwq.html#relaying FAQS | 3) Secondary MX --> list in rcpthosts, NOT in locals/virtualdomains * * * | 4) Discard mail --> "#" line ONLY, in appropriate .qmail file _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
>From: Charles Cazabon <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Can MX record be CNAME? >Date: Thu, 3 May 2001 14:10:23 -0600 > >q question <[EMAIL PROTECTED]> wrote: > > > > > > And please don't post BIND zonefiles to Dan's lists -- [...] > > > Instead, tell us [the contents of the DNS records] > > > 4) You have stated repeatedly that people must provide detailed >information > > in their emails to this list. Kris did so, and you protest that it is >too > > detailed. You really can't have it both ways. > >I didn't mean "don't give us the DNS information". I meant "give us the >DNS >information in a format that does not require an intimiate knowledge of >BIND >zonefile format". > >After all, you don't need to know anything about BIND to be a knowledgable >mail admin. Actually, I think I could never have solved the sendmail configuration problems that I have solved without knowing BIND thoroughly. Mail administration maintenance doesn't need detailed BIND, but the initial sendmail configuration in a complex environment absolutely needs thorough DNS/BIND knowledge. >You just need to understand some DNS basics. I, unfortunately, >have had to learn a bit here and there about BIND zonefiles, but I still >prefer the information in a non-proprietary format. BINDthink is painful, >and >in this list, completely unnecessary. Charles, I understand what it is like to be somewhat familiar with something but not thoroughly familiar. There are so many technical topics that it is impossible for all of us to maintain a full level of expertise in everything at all times. Even once one has mastered a particular topic, it is quite easy to become rusty after only a few weeks away from the topic. I understand that you are asking for the sentence explanation for those who are not into BINDthink. I think it is fine to ask for the sentence explanation and say this is helpful for those not into BINDthink. Please respect those people who do understand BINDthink and realize that it is instantly more clear to us to see the actual records rather than to suppress the display of the actual records on the email list. You do not own this email list. You are sharing this space with a lot of people who have a wide range of technical expertise in a wide range of topics. Just because you prefer something in one particular way, does not mean your opinion must dominate. I thought it was terrific when Kris showed the actual zone records. I'm happy if he wants to take the time to make a sentence summary of it to please you and others who may be hazy about DNS. I was appalled when you said "please don't post BIND zonefiles to Dan's lists". That is a blanket directive that is not necessarily shared by everyone on this list, certainly not me. A few lines of zone records speaks volumes for BINDthinkers and they are well worth the space in the email. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
>Please stop this useless flaming. You aren't posting anything usefull, just >flaming charles. This is a technical discussion list, no smalltalk. Either >provide answers or participate in technical discussions or shut up. I am not flaming Charles in any way. I have been completely respectful. I have requested that he not issue blanket directives that are not necessarily shared by all. > >-- >Henning Brauer | BS Web Services >Hostmaster BSWS | Roedingsmarkt 14 >[EMAIL PROTECTED] | 20459 Hamburg >http://www.bsws.de | Germany > >Unix is very simple, but it takes a genius to understand the simplicity. >(Dennis Ritchie) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
On Thu, May 03, 2001 at 05:32:52PM -0500, Aaron Goldblatt wrote: > If you are using a.b.c.d notation in your MX record, you must remember to > update that record in addition to all your A records. a MX record has to have a FQDN and *not* an IP address. Or did you mean a.b.c.d to be a FQDN rather than an IP address? If not, you're wrong, if you did mean it to be a FQDN than please use sth like mail.example.com so everyone gets the point. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
I shall make no further comment.
On Thu, May 03, 2001 at 08:16:16PM -0500, q question wrote: > Actually, I think I could never have solved the sendmail configuration > problems that I have solved without knowing BIND thoroughly. Mail > administration maintenance doesn't need detailed BIND, but the initial > sendmail configuration in a complex environment absolutely needs thorough > DNS/BIND knowledge. STOP THIS OT Stuff! Mr. "q question", I haven't seen a single on-topic post from you. Please search another communications forum for smalltalk. This List is not about sendmail, BIND or Flaming Charles, this list is about qmail, period. -- Henning Brauer | BS Web Services Hostmaster BSWS | Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Aaron Goldblatt wrote: > With respect to the remainder of your question, reverse resolution isn't a > necessary consideration. > > For example: > > mail.goldblatt.net -- 208.190.130.82. It reverses to > wndrgrl.goldblatt.net. It still works. This is the case what made me think the subject in the first place: If mail servers MX name (mail.goldblatt.net) which it announces when contacting another mailserver is different than the one that a PTR record for it's IP address 208.190.130.82 resolves (wndrgrl.goldblatt.net) I thought it might lead to trouble. But you are absolutely sure that it won't? If so, great, no problemo then. Peter
On Thu, May 03, 2001 at 08:18:56PM -0500, q question wrote: > >Please stop this useless flaming. You aren't posting anything usefull, just > >flaming charles. This is a technical discussion list, no smalltalk. Either > >provide answers or participate in technical discussions or shut up. > I am not flaming Charles in any way. I have been completely respectful. Sure. What else. > I > have requested that he not issue blanket directives that are not necessarily > shared by all. You are posting tons of useless OFF TOPIC stuff and not a single on-topic message so far, please stop this NOW. -- Henning Brauer | BS Web Services Hostmaster BSWS | Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
I'm found wrong, I'm install qmail from apt-get install qmail-src in my Debian GNU/Linux system, Debian not creat /var/qmail/bin he put qmail-queue in /usr/sbin autoresponder find qmail in QMAILLOCATION /var/qmail and /var/qmail/bin I'm trying install qmail for tar.gz and running autoresponder its correct? or I'm edit autoresponder.c arrrggg...
Nick (Keith) Fish <[EMAIL PROTECTED]> wrote: > Christian DRESSEND wrote: > > > The problem is not whn looking for the server or for the messages, but > > during download. It stops responding in the middle of messages in case of > > large messages >100kbyte using dial-up, when the connection speed is low > > (MODEM) so the downloads last longer. > > Ahh . .. I don't know about everyone else here; but I have never gotten big > messages do download or upload via e-mail on a dial-up connection. I always > assumed that the speed of the type of transfer used by POP1 (ASCII?) degraded > over time. No, there's no technical reason why retrieving messages via POP3 should slow down over time. The original poster should check his client software; various versions of Outlook Express and Outlook can time out in the middle of a message download if the last character in a TCP packet happens to be a period (.) . Don't ask me why those clients care about packets, when the protocols they're supposed to speak are just byte streams. 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. -----------------------------------------------------------------------
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have implemented footer on my qmail-smtpd file and its working fine. I've never used this patch, so I can't comment on how it works. > But its working for all incoming and outgoing mail, But i want that footer > should apply only on my outgoing mail. I believe i have to run two > qmail-smtpd, one with footer( for outgoing smtp ) and other without footer ( > for incoming smtp ) qmail-smtpd is _only_ for incoming mail. It doesn't handle outgoing mail. What you should probably do is run an unpatched qmail-smtpd for incoming mail, and then run the patched one for outgoing mail on a different port or IP address, and point your local MUAs which inject via SMTP to that one. However, the author of the patch must have considered this issue; isn't there a way to control which messages get the footer? 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. -----------------------------------------------------------------------
Andrea Cerrito <[EMAIL PROTECTED]> wrote: > > mail from internet > smtp.domain.ext must carry the duty > smtp.domain.ext > must forward the message to pop.domain.ext (another machine) > > In the same scenario, smtp.domain.ext must allow pop.domain.ext to fully > relay. Should be easy to do with tcpserver and smtproutes. > My problem is that smtp.domain.ext is accepting local mail if the "rcpt to:" > passage is done without the @. Fix the clients. It's forbidden to not have a domain in the address(es) in the envelope recipient(s). > How can I setup smtp.domain.ext to not allow receving mail for local at all? Don't put anything in /var/qmail/control/locals? 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. -----------------------------------------------------------------------
Charles, 1) What are the erroneous assumptions of the Prodygy relay test utility? 2) How is it so clear that the machine didn't relay mail? >From: Charles Cazabon <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SPAM Patches recomendations. >Date: Tue, 1 May 2001 09:52:51 -0600 > >Eduardo Augusto Alvarenga <[EMAIL PROTECTED]> wrote: > > > > I've tested my qmail smtp server for spam using the Prodygy Solutions > > relay test utility: >[...] > > And got 2(two) holes on my server: > >No, you don't. Your machine didn't relay mail, and the tests (hah!) didn't >even actually do any testing; they inferred a result from erroneous >assumptions. > >Ignore the "tests" you did; they're worthless, and tell you nothing about >whether your server is an open relay or not. Provided you have >/var/qmail/control/rcpthosts, and it contains only your domains, and you're >not setting the RELAYCLIENT environment variable for random IP addresses >which >connect to your SMTP port, then you are NOT an open relay. > >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. >----------------------------------------------------------------------- _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
q question <[EMAIL PROTECTED]> wrote: > > 1) What are the erroneous assumptions of the Prodygy relay test utility? It assumes that because the RCPT TO: <...> command succeeded, the mail will be delivered. This is not required by RFC821/2821, and is not true of qmail or any other MTA which does not have knowledge of the possible final delivery targets during the initial SMTP conversation. It's also making some broken assumptions about how certain conventions in the local-part of an SMTP envelope recipient address translate into implicit relaying requests -- these conventions are not part of the SMTP specification, and qmail doesn't use them. The fact that sendmail (or Domino, or Exchange, or whatever) is broken enough to do so should not implicate properly implemented SMTP servers. > 2) How is it so clear that the machine didn't relay mail? -these types of questions come up every week on this mailing list -qmail has _never_ relayed mail unless the administrator specifically configures it to do so. 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. -----------------------------------------------------------------------
>From: Charles Cazabon <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SPAM Patches recomendations. >Date: Thu, 3 May 2001 09:06:00 -0600 > >q question <[EMAIL PROTECTED]> wrote: > > > > 1) What are the erroneous assumptions of the Prodygy relay test utility? > >It assumes that because the RCPT TO: <...> command succeeded, the mail will >be >delivered. This is not required by RFC821/2821, and is not true of qmail >or >any other MTA which does not have knowledge of the possible final delivery >targets during the initial SMTP conversation. > >It's also making some broken assumptions about how certain conventions in >the >local-part of an SMTP envelope recipient address translate into implicit >relaying requests -- these conventions are not part of the SMTP >specification, >and qmail doesn't use them. The fact that sendmail (or Domino, or >Exchange, >or whatever) is broken enough to do so should not implicate properly >implemented SMTP servers. I appreciate your describing this in detail. I'm going to need some time to reflect on these assumptions. > > 2) How is it so clear that the machine didn't relay mail? > >-these types of questions come up every week on this mailing list >-qmail has _never_ relayed mail unless the administrator specifically >configures it to do so. I know the qmail documentation says that the default for qmail is not to relay. I need to see proof, not just be told to assume that the documentation is correct. As I said above, I'll need time to reflect on this. I appreciate that someone else suggested asking ORBS to do a relay test. However, that doesn't necessarily reassure me that the Prodygy Solutions relay test results should be ignored. I don't know anything specific about the Prodygy relay test "failures" but I don't just ignore something because someone else said to. I do appreciate your reply and I realize full well that I may end up deciding to ignore the Prodygy relay test failures someday myself. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
> From: "q question" <[EMAIL PROTECTED]> > Date: Thu, 03 May 2001 10:30:52 -0500 > > >From: Charles Cazabon <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: SPAM Patches recomendations. > >Date: Thu, 3 May 2001 09:06:00 -0600 > > > >It's also making some broken assumptions about how certain conventions in > >the > >local-part of an SMTP envelope recipient address translate into implicit > >relaying requests -- these conventions are not part of the SMTP > >specification, > >and qmail doesn't use them. The fact that sendmail (or Domino, or > >Exchange, > >or whatever) is broken enough to do so should not implicate properly > >implemented SMTP servers. > > > I appreciate your describing this in detail. I'm going to need some time to > reflect on these assumptions. The particular assumption that Charles didn't explain is that user%host2&host1 or host2|user@host1 will be relayed by host1 to user@host2. Certainly software that does this is broken, but it's also perfectly legal for first%last@host1 or first!last@host1 to be delivered to an account on that machine. To assume that the only reason such an address would be accepted is to relay it is totally bogus. Chris -- Chris Garrigues http://www.DeepEddy.Com/~cwg/ virCIO http://www.virCIO.Com 4314 Avenue C Austin, TX 78751-3709 +1 512 374 0500 My email address is an experiment in SPAM elimination. For an explanation of what we're doing, see http://www.DeepEddy.Com/tms.html Nobody ever got fired for buying Microsoft, but they could get fired for relying on Microsoft.
PGP signature
q question <[EMAIL PROTECTED]> wrote: > > I know the qmail documentation says that the default for qmail is not to > relay. I need to see proof, not just be told to assume that the > documentation is correct. The proper "proof" is to try to relay yourself, and see if the message makes it to its intended destination. With qmail, you'll find that it doesn't. Note that this isn't a proof in the mathematical sense. For that, you'll need to do a line-by-line analysis of the qmail source code. > I appreciate that someone else suggested asking ORBS to do a relay test. > However, that doesn't necessarily reassure me that the Prodygy Solutions > relay test results should be ignored. What should convince you to ignore those tests is that they are providing a diagnosis ("Relay attempt succeeded") which is patently false (it isn't a successful relay unless the mail makes it to the final destination, and they aren't even actually sending the mail, just testing the RCPT TO: command). 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. -----------------------------------------------------------------------
On Thu, May 03, 2001 at 10:30:52AM -0500, q question wrote: SNIP > > > 2) How is it so clear that the machine didn't relay mail? > > > >-these types of questions come up every week on this mailing list > >-qmail has _never_ relayed mail unless the administrator specifically > >configures it to do so. > > > I know the qmail documentation says that the default for qmail is not to > relay. I need to see proof, not just be told to assume that the > documentation is correct. As I said above, I'll need time to reflect on > this. I appreciate that someone else suggested asking ORBS to do a relay > test. However, that doesn't necessarily reassure me that the Prodygy > Solutions relay test results should be ignored. I don't know anything > specific about the Prodygy relay test "failures" but I don't just ignore > something because someone else said to. 'Proof'? If the relay test in question was acceptable, the OP would already have proof. A proper relay test involves the _actual receipt of relayed mail_. Try your own relay test, if you have addresses at multiple domains available, along the exact same lines as the 'tests' performed by prodigysolutions[1]. If you don't have another address available, use a friend's email account. If you manage to relay third-party mail through a qmail server with rcpthosts populated only with domains that you should actually deliver for (present in locals or virtualdomains[2]), and a properly set RELAYCLIENT environment variable, I will eat a bug on camera, and give you links to watch it on the web. :) [1] I didn't recall seeing recent results for the 'user@destination@relay' test, so I did them myself. Delivery attempt is to local user 'user@destination', which is unlikely to exist and in any case is not a relay. The '%' and '!' garbage comes up at least once a month, and is known _not_ to be a problem. Check that for yourself as well, if you like. [2] Or, of course, a domain that you're an MX for, but not the best-preference MX. > > I do appreciate your reply and I realize full well that I may end up > deciding to ignore the Prodygy relay test failures someday myself. Avoid the rush! Start ignoring them today! 'Tests' which assume that they know better than the MTA they are testing how it will deliver mail are inherently broken. 'Tests' which do not actually attempt to deliver mail anywhere, and do not only count the _actual receipt of mail_ as a successful relay (failed test) are inherently broken. As far as I am concerned, any 'test' that does not actually attempt delivery should immediately be ignored. SNIP GW
Unless the network is lying to me again, Chris Garrigues said: > The particular assumption that Charles didn't explain is that > user%host2&host1 or host2|user@host1 will be relayed by host1 > to user@host2. > > Certainly software that does this is broken, If anyone cares, this used to be completely legal and actually, a very useful way of doing things. There were a number of UUCP sites that were much quicker to address via: [EMAIL PROTECTED] than giving the full ! path to the actual uucp site. This was not "broken", it was "operational". I guess those days are gone, however. Just for fun, does anyone remember the issues surrounding: [EMAIL PROTECTED] Other fun thing that nolonger works: finger user@somehost@otherhost AlanC -- Alan Clegg I do UNIX and Networks [EMAIL PROTECTED] I don't have any certification I have experience
I appreciate your pointing this out. >From: "Chris Garrigues" <[EMAIL PROTECTED]> >To: "q question" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: SPAM Patches recomendations. >Date: Thu, 03 May 2001 11:24:49 -0500 > > > From: "q question" <[EMAIL PROTECTED]> > > Date: Thu, 03 May 2001 10:30:52 -0500 > > > > >From: Charles Cazabon <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: SPAM Patches recomendations. > > >Date: Thu, 3 May 2001 09:06:00 -0600 > > > > > >It's also making some broken assumptions about how certain conventions >in > > >the > > >local-part of an SMTP envelope recipient address translate into >implicit > > >relaying requests -- these conventions are not part of the SMTP > > >specification, > > >and qmail doesn't use them. The fact that sendmail (or Domino, or > > >Exchange, > > >or whatever) is broken enough to do so should not implicate properly > > >implemented SMTP servers. > > > > > > I appreciate your describing this in detail. I'm going to need some time >to > > reflect on these assumptions. > >The particular assumption that Charles didn't explain is that >user%host2&host1 >or host2|user@host1 will be relayed by host1 to user@host2. > >Certainly software that does this is broken, but it's also perfectly legal >for >first%last@host1 or first!last@host1 to be delivered to an account on that >machine. To assume that the only reason such an address would be accepted >is >to relay it is totally bogus. > >Chris > >-- >Chris Garrigues http://www.DeepEddy.Com/~cwg/ >virCIO http://www.virCIO.Com >4314 Avenue C >Austin, TX 78751-3709 +1 512 374 0500 > > My email address is an experiment in SPAM elimination. For an > explanation of what we're doing, see http://www.DeepEddy.Com/tms.html > > Nobody ever got fired for buying Microsoft, > but they could get fired for relying on Microsoft. > > ><< attach3 >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
>What should convince you to ignore those tests is that they are providing a >diagnosis ("Relay attempt succeeded") which is patently false (it isn't a >successful relay unless the mail makes it to the final destination, and >they >aren't even actually sending the mail, just testing the RCPT TO: command). > >Charles Relay test 7 MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com) 250 ok RCPT TO:("nobody%prodigysolutions.com") 250 ok (Failed Test) RSET 250 flushed Relay test 13 MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com) 250 ok RCPT TO:(prodigysolutions.com!nobody) 250 ok (Failed Test) RSET 250 flushed I see your point, the "(Failed Test)" occurs immediately after "RCPT TO: ..." "250 ok" This is why your (and Chris's) explanations about the assumptions are very useful, that the mail could be successfully received either for a local delivery, or for a relay, or perhaps not delivered at all. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
You don't need to look for any bugs to eat! I haven't installed qmail yet, I'm still in the planning stages. I wanted to know how to test for relays and I appreciate your points. Thanks! :) >From: Greg White <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: SPAM Patches recomendations. >Date: Thu, 3 May 2001 10:41:33 -0700 > >On Thu, May 03, 2001 at 10:30:52AM -0500, q question wrote: >SNIP > > > > 2) How is it so clear that the machine didn't relay mail? > > > > > >-these types of questions come up every week on this mailing list > > >-qmail has _never_ relayed mail unless the administrator specifically > > >configures it to do so. > > > > > > I know the qmail documentation says that the default for qmail is not to > > relay. I need to see proof, not just be told to assume that the > > documentation is correct. As I said above, I'll need time to reflect on > > this. I appreciate that someone else suggested asking ORBS to do a relay > > test. However, that doesn't necessarily reassure me that the Prodygy > > Solutions relay test results should be ignored. I don't know anything > > specific about the Prodygy relay test "failures" but I don't just ignore > > something because someone else said to. > >'Proof'? If the relay test in question was acceptable, the OP would already >have proof. A proper relay test involves the _actual receipt of relayed >mail_. Try your own relay test, if you have addresses at multiple domains >available, along the exact same lines as the 'tests' performed by >prodigysolutions[1]. If you don't have another address available, use a >friend's email account. If you manage to relay third-party mail through a >qmail server with rcpthosts populated only with domains that you should >actually deliver for (present in locals or virtualdomains[2]), and a >properly set RELAYCLIENT environment variable, I will eat a bug on camera, >and >give you links to watch it on the web. :) > >[1] I didn't recall seeing recent results for the >'user@destination@relay' test, so I did them myself. Delivery attempt is >to local user 'user@destination', which is unlikely to exist and in any >case is not a relay. The '%' and '!' garbage comes up at least once a >month, and is known _not_ to be a problem. Check that for yourself as >well, if you like. > >[2] Or, of course, a domain that you're an MX for, but not the >best-preference MX. > > > > > I do appreciate your reply and I realize full well that I may end up > > deciding to ignore the Prodygy relay test failures someday myself. > >Avoid the rush! Start ignoring them today! 'Tests' which assume that >they know better than the MTA they are testing how it will deliver mail >are inherently broken. 'Tests' which do not actually attempt to deliver >mail anywhere, and do not only count the _actual receipt of mail_ as a >successful relay (failed test) are inherently broken. As far as I am >concerned, any 'test' that does not actually attempt delivery should >immediately be ignored. > > >SNIP > >GW _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
Alan Clegg <[EMAIL PROTECTED]> wrote: > > > The particular assumption that Charles didn't explain is that > > user%host2&host1 or host2|user@host1 will be relayed by host1 > > to user@host2. > If anyone cares, this used to be completely legal and actually, a very > useful way of doing things. There were a number of UUCP sites that were > much quicker to address via: > > [EMAIL PROTECTED] > > than giving the full ! path to the actual uucp site. This was not "broken", > it was "operational". The brokenness comes from a third party looking at the local-part of that address, and deducing that it implies relaying. The most recent SMTP RFC (2821) forbids this in section 2.3.10: The standard mailbox naming convention is defined to be "local- part@domain": contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. Prodygy (or whoever it was) was assuming that since a qmail server responded with a 2xx code to RCPT TO: <[EMAIL PROTECTED]@baz.net> that it would relay the mail. That assumption is incorrect, and has always been. The fact that some sites will interpret the local-part of that address and relay it does not mean that all sites which do not respond with a 4xx or 5xx code to that command should be identified as relays. > I guess those days are gone, however. So are the days of the 5-cent Coke and the sub-$1000 new car. Doesn't mean I'm wistful about them. 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. -----------------------------------------------------------------------
I get the following when trying to launch sqwebmail: <H1>Internal error (module sqwebmail.c, line 1499) - contact system administrator</H1> How can I fix this problem? Brendan
> -----Messaggio originale----- > Da: Charles Cazabon [mailto:[EMAIL PROTECTED]] > Inviato: giovedi 3 maggio 2001 16.32 > A: [EMAIL PROTECTED] > Oggetto: Re: Qmail as only relay > > > Andrea Cerrito <[EMAIL PROTECTED]> wrote: > > > > mail from internet > smtp.domain.ext must carry the duty > > smtp.domain.ext > > must forward the message to pop.domain.ext (another machine) > > > > In the same scenario, smtp.domain.ext must allow pop.domain.ext to fully > > relay. > > Should be easy to do with tcpserver and smtproutes. It is. :) > > My problem is that smtp.domain.ext is accepting local mail if > the "rcpt to:" > > passage is done without the @. > > Fix the clients. It's forbidden to not have a domain in the > address(es) in > the envelope recipient(s). Ah. Ok. > > How can I setup smtp.domain.ext to not allow receving mail for > local at all? > > Don't put anything in /var/qmail/control/locals? Already done, but this doesn't work (qmail puts @smtp.domain.ext if no domain is used). --- Cordiali saluti / Best regards Andrea Cerrito ^^^^^^^^^^^^^^ Net.Admin @ Centro MultiMediale di Terni SpA P.zzale Bosco 3A 05100 Terni IT Tel. 0744 / 5441330 Fax. 0744 / 5441372
Hi, I have a small question: if qmail sees an MX record with multiple IP's for the same domain, will it always use the same IP or will it do a random use of the IP's ? Thinking about djbdns, I know it is expected for this functionality to be in the client (here qmail) so I wonder ... I know it is kind of silly to implement round robin for MX records, but that's beside the point here. Greets, Franky
Your email was unreadable. Try resending with plain text in the body of the message. On Thu, 3 May 2001 19:10:48 +0200, Fares Gianluca wrote: Stephen Berg //- USAF Instructor -/- Reluctant NT User -/- Web Designer -// //- Home = [EMAIL PROTECTED] -// //- Work = [EMAIL PROTECTED] -// //- http://iceberg.3c0x1.com/ -/- http://www.3c0x1.com -//
Hello All, I'm trying to do a forwaring-service, where the users each have an address (ie [EMAIL PROTECTED]) and any mail sent to this address is forwarded to their _actual_ address (perhaps a hotmail-address or similiar). I know how to forward (& [EMAIL PROTECTED]) but how do I do it dynamically? I can do a php or perl-script that will digg out the needed to-address from my mySql-database, but don't know how to do the actual forwarding?? any help is greatly appriciated!!!!! (I've subscribed to the list, but am not getting any mail yet, so please cc: [EMAIL PROTECTED]) // Kim [EMAIL PROTECTED]
Kim Chr. Hvidkjaer <[EMAIL PROTECTED]> wrote: > > I'm trying to do a forwaring-service, where the users each have an address > (ie [EMAIL PROTECTED]) and any mail sent to this address is forwarded to their > _actual_ address (perhaps a hotmail-address or similiar). > > I know how to forward (& [EMAIL PROTECTED]) but how do I do it dynamically? I > can do a php or perl-script that will digg out the needed to-address from my > mySql-database, but don't know how to do the actual forwarding?? Have your script call qmail-inject, qmail-queue, or /usr/sbin/sendmail (as appropriate). There are good man pages for each of these. 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. -----------------------------------------------------------------------
You can make a script in your preferred language that reads the message, get the destination address (Delivered-To:), query for its alias in a DB, and finally reinject it into the queue using qmail-inject, sendmail or other, keeping the original sender address and optionally adding your ads, tails... .qmail-default: |/path_to_your_script Regards Wagner. > -----Original Message----- > From: Kim Chr. Hvidkjaer [mailto:[EMAIL PROTECTED]] > Sent: Quinta-feira, 3 de Maio de 2001 14:38 > To: [EMAIL PROTECTED] > Subject: forwarding to a dynamic / variable address ?? > > > Hello All, > > I'm trying to do a forwaring-service, where the users each have an address > (ie [EMAIL PROTECTED]) and any mail sent to this address is > forwarded to their > _actual_ address (perhaps a hotmail-address or similiar). > > I know how to forward (& [EMAIL PROTECTED]) but how do I do it > dynamically? I > can do a php or perl-script that will digg out the needed > to-address from my > mySql-database, but don't know how to do the actual forwarding?? > > any help is greatly appriciated!!!!! > > > > > (I've subscribed to the list, but am not getting any mail yet, so > please cc: > [EMAIL PROTECTED]) > > // Kim > > [EMAIL PROTECTED] > >
Hmm. Well, you could set up a .qmail-default file in xyz's directory that has this: | find_and_forward.pl where find_and_forward.pl is your perl script that dynamically finds the forward address for xyz. Then in order to actually forward the message just read <> into a variable (say, $message) and inject that into qmail with qmail-inject which, in perl, would look something like this: $mail_prog = '/var/qmail/bin/qmail-inject'; $mail = "To: $to_name <$to_email>\r\n"; $mail .= "From: $from_name <$from_email>\r\n"; $mail .= "Subject: $subject\r\n\r\n"; $mail .= "$message\r\n"; system ("echo '$mail' | $mail_prog"); Obviously the $to_email came from your SQL database search and you can either parse the message for the $subject or fudge your own. Better methods than this? I'm sure there are several but this is what immediately comes to mind. Brett. -----Original Message----- From: Kim Chr. Hvidkjaer [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:38 AM To: [EMAIL PROTECTED] Subject: forwarding to a dynamic / variable address ?? Hello All, I'm trying to do a forwaring-service, where the users each have an address (ie [EMAIL PROTECTED]) and any mail sent to this address is forwarded to their _actual_ address (perhaps a hotmail-address or similiar). I know how to forward (& [EMAIL PROTECTED]) but how do I do it dynamically? I can do a php or perl-script that will digg out the needed to-address from my mySql-database, but don't know how to do the actual forwarding?? any help is greatly appriciated!!!!! (I've subscribed to the list, but am not getting any mail yet, so please cc: [EMAIL PROTECTED]) // Kim [EMAIL PROTECTED]
I have two problems. Problem #1: I've installed the big concurrency patch successfully and yet I cannot get above 257 connections at once. I'm using Debian Linux 2.2.18pre21 and from what I read, it should be quite possible to adjust the maximum processes per user through 'limit' (or 'ulimit' depending on the shell) rather than adjusting and recompiling the kernel. Well, I'm root, I do the adjustments to limit ('limit maxproc 1000') but when I check the logs, qmail never gets above 257 concurrency (256 is the default limit of maxproc). I do a 'limit' before and after I run my script and get the following output each time: cputime unlimited filesize unlimited datasize unlimited stacksize 8192 kbytes coredumpsize 0 kbytes memoryuse unlimited descriptors 10000 memorylocked unlimited maxproc 1000 openfiles 10000 So the limit adjustment is sticking and yet it's being ignored. I thought at one point that maybe when I change the limit as root it doesn't apply to user qmailr (the user opening all the connections) but when I 'su qmailr' and check 'limit' I get the same updated numbers so that doesn't seem to be the problem. In the logfiles, the error I get at 257 concurrent connections is this: May 2 16:21:07 debian qmail: 988845667.036121 status: local 0/10 remote 257/500 May 2 16:21:07 debian qmail: 988845667.036150 delivery 44180: deferral: qmail-spawn_unabl e_to_fork._(#4.3.0)/ May 2 16:21:07 debian qmail: 988845667.036176 status: local 0/10 remote 256/500 May 2 16:21:07 debian qmail: 988845667.036210 delivery 43746: success: 64.4.56.199_accept ed_message./Remote_host_said:_250_Requested_mail_action_okay,_completed/ "qmail-spawn unable to fork" pretty much tells me it's a linux resource problem. Okay, but what are 'limit' and 'ulimit' for if the adjustments I make to them are ignored? I realize this is more of a Linux question than a qmail one but at the same time, I know it's something many qmail users must have run into so I'm hoping I can get some feedback. Thanks. Problem #2: Is there a limit on the maximum number of Bccs you can have for a single message? I ask because somewhere between 5600 and 5700 Bccs qmail-inject stops trying. That is, I can send one message Bcced to 5600 people fine. But when I try to send the same message Bcced to 5700 people, qmail doesn't even try. The logs don't show that anything took place whatsoever. I suppose this could be another Linux resource issue but then wouldn't qmail at least try to send the message and then give me an error like it does above when it can't fork? Also puzzling is the fact that I *can* do this: call qmail-inject twice in a row, each time with 5600 recipients and qmail sends all 11200 messages fine. Here's qmail-showctl: qmail home directory: /var/qmail. user-ext delimiter: -. paternalism (in decimal): 2. silent concurrency limit: 500. subdirectory split: 23. user ids: 1001, 1002, 1003, 0, 1004, 1005, 1006, 1007. group ids: 1001, 64010. badmailfrom: (Default.) Any MAIL FROM is allowed. bouncefrom: (Default.) Bounce user name is MAILER-DAEMON. bouncehost: (Default.) Bounce host name is debian.wnrg.com. concurrencylocal: (Default.) Local concurrency is 10. concurrencyremote: Remote concurrency is 500. databytes: (Default.) SMTP DATA limit is 0 bytes. defaultdomain: Default domain name is wnrg.com. defaulthost: (Default.) Default host name is debian.wnrg.com. doublebouncehost: (Default.) 2B recipient host: debian.wnrg.com. doublebounceto: (Default.) 2B recipient user: postmaster. envnoathost: (Default.) Presumed domain name is debian.wnrg.com. helohost: (Default.) SMTP client HELO host name is debian.wnrg.com. idhost: (Default.) Message-ID host name is debian.wnrg.com. localiphost: (Default.) Local IP address becomes debian.wnrg.com. locals: Messages for debian.wnrg.com are delivered locally. Messages for debian.wnrg.com are delivered locally. me: My name is debian.wnrg.com. percenthack: (Default.) The percent hack is not allowed. plusdomain: Plus domain name is wnrg.com. qmqpservers: (Default.) No QMQP servers. queuelifetime: (Default.) Message lifetime in the queue is 604800 seconds. rcpthosts: SMTP clients may send messages to recipients at wnrg.com. SMTP clients may send messages to recipients at debian.wnrg.com. SMTP clients may send messages to recipients at debian.wnrg.com. morercpthosts: (Default.) No effect. morercpthosts.cdb: (Default.) No effect. smtpgreeting: (Default.) SMTP greeting: 220 debian.wnrg.com. smtproutes: SMTP route: debian.wnrg.com:mail.wnrg.com timeoutconnect: (Default.) SMTP client connection timeout is 60 seconds. timeoutremote: (Default.) SMTP client data timeout is 1200 seconds. timeoutsmtpd: (Default.) SMTP server data timeout is 1200 seconds. virtualdomains: (Default.) No virtual domains. Thanks in advance to anyone patient enough to read through all this and at least point me in the right direction. Brett.
Brett <[EMAIL PROTECTED]> wrote: > I have two problems. Yes. And you posted the same message twice. Since no one replied to your first message, I'll take a stab at it here. > Problem #1: > May 2 16:21:07 debian qmail: 988845667.036150 delivery 44180: deferral: > qmail-spawn_unable_to_fork._(#4.3.0)/ [...] > "qmail-spawn unable to fork" pretty much tells me it's a linux resource > problem. Yes; you solved it yourself. However, it doesn't belong on this list. Perhaps ask a Linux mailing list why your system is limiting the number of processes. > Problem #2: [...] > But when I try to send the same message Bcced to 5700 people, qmail doesn't > even try. The logs don't show that anything took place whatsoever. Unlikely. If the message makes it into the queue, qmail will log information about it. If it doesn't make it into the queue, then qmail-queue (or qmail-inject, or whatever) will exit with an appropriate error code. How were you injecting the message, and what was the exit code of the program? 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. -----------------------------------------------------------------------
FormMailpl http://www.worldwidemart.com/scripts/ work it qmail?
I would assume one of your configuration options is the choice of what mailer you want to use and therefore, yes, this would work with qmail. But really, you're probably better off checking the faq, READMEs, other documentation, etc. on the specific FormMail page: http://www.worldwidemart.com/scripts/formmail.shtml Brett. -----Original Message----- From: Flavio Alberto [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 1:32 PM To: [EMAIL PROTECTED] Subject: FromMail.pl FormMailpl http://www.worldwidemart.com/scripts/ work it qmail?
On Thu, May 03, 2001 at 05:31:59PM -0300, Flavio Alberto wrote: > FormMailpl http://www.worldwidemart.com/scripts/ work it qmail? of course it does :) If you installed the sendmail symlinks... (as explained at the end of qmail install file) Regards, Olivier -- _________________________________________________________________ Olivier Mueller - [EMAIL PROTECTED] - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
I'm new to sqwebmail, but I think you can help you and us with an strace / truss of the httpd program serving the cgi. Good luck --- Cordiali saluti / Best regards Andrea Cerrito ^^^^^^^^^^^^^^ Net.Admin @ Centro MultiMediale di Terni SpA P.zzale Bosco 3A 05100 Terni IT Tel. 0744 / 5441330 Fax. 0744 / 5441372 > -----Messaggio originale----- > Da: Brendan McAlpine [mailto:[EMAIL PROTECTED]] > Inviato: giovedi 3 maggio 2001 21.40 > A: [EMAIL PROTECTED] > Oggetto: error with sqwebmail > > > I get the following when trying to launch sqwebmail: > > <H1>Internal error (module sqwebmail.c, line 1499) - contact system > administrator</H1> > > How can I fix this problem? > > Brendan >
On Thu, May 03, 2001 at 10:40:51PM +0200, Andrea Cerrito wrote: > I'm new to sqwebmail, but I think you can help you and us with an strace / > truss of the httpd program serving the cgi. No, help yourself and use the correct list - this is qmail, not sqwebmail. And beforfe posting this to the sqwebmail list: include _much_ more information, especially the entries in ther server error log. -- Henning Brauer | BS Web Services Hostmaster BSWS | Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Hi, I have a case where one of the local user is sending lot of mails to outside domains in bunches of 50 mails each time since we have imposed limit of max recipients as 50. As of now now that user is consuming lot of our Internet Bandwith and constantly sending lot of outbound emails. Can we block /control/limit that particular user's outbound connections. Regards, Puneet ----- Original Message ----- From: "Charles Cazabon" <[EMAIL PROTECTED]> To: "Qmail list (E-mail)" <[EMAIL PROTECTED]> Sent: Thursday, March 29, 2001 7:40 PM Subject: Re: Limit outbound connections but not for all domains > Iņigo Martínez Lasala <[EMAIL PROTECTED]> wrote: > > > > Is there anyway to limit outbound connections with control/concurrentremote > > but not for all domains? I want to limit outbound connections for all > > domains but one (it's an internal domain and the bandwidth is not limited, > > so there is no reason to limit this domain and I want immediate delivery > > too). > > No easy way. djb's .qmail-default/serialmail trick is designed for the > opposite case. The only way that comes to mind is to set up two separate > instances of qmail on the box, one handling mail to the internal domain, > one for everything else. The second hands mail for the internal domain off > to the first instance, which has a high concurrencyremote. > > 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. > ----------------------------------------------------------------------- >
Puneet Narang <[EMAIL PROTECTED]> wrote: > I have a case where one of the local user is sending lot of mails to outside > domains in bunches of 50 mails each time since we have imposed limit of max > recipients as 50. As of now now that user is consuming lot of our Internet > Bandwith and constantly sending lot of outbound emails. Can we block > /control/limit that particular user's outbound connections. Sounds like a spammer. Perhaps you should log copies of his messages to determine if he is violating any of your terms of service, and terminate his service if he is. The best solution in this case is probably not a technical one, but an administrative one -- tell this user they can not send more than X messages, or Y bytes of email, per period Z. Then check the logs (with qmail-analog) to see if he violates the policy. If he does, warn him. If he does it again, terminate him. If you want a technical solution -- well, if he injects via SMTP from a known IP address, you could set up a separate qmail instance (and hence separate queue) just for his use, and direct his connections to the appropriate qmail-smtpd with ipchains, or ip-filter, or whatever your system has. Then, when network bandwidth is at a premium, stop the qmail-send process on that instance of qmail, restarting it only when available bandwidth is sufficient for his uses. If he's injecting with qmail-inject, you could apply Bruce Guenter's QMAILQUEUE patch, and use either his qmail-qfilter mechanism or your own to apply whatever filtering criteria you want to his mail. More details about the situation would help. 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. -----------------------------------------------------------------------
I could be wrong, but by simply adding a domain to rcpthosts and locals will allow mail to be accepted on multiple domains using /etc/passwd for authentication. I use vpopmail for virtual domains and it is handled entirely differently from the locals, which use passwd. It may depend on the system used to handle virtual domains, however. -K "Do not meddle in the affairs of wizards, for they are subtle and quick to anger." > From: "Twinsen Mak" <[EMAIL PROTECTED]> > Date: Wed, 2 May 2001 07:36:26 +0800 > To: <[EMAIL PROTECTED]> > Subject: Both system account and virtual account of one domain. > > Does qmail(or vpopmail) can do so that one domain can include some system > accounts(via passwd) and some virtual accounts(via > vpopmail w/ mysql)!!? Please advise. > > \TM > > >
On 02-May-2001 Charles Cazabon wrote: > Marco Calistri <[EMAIL PROTECTED]> wrote: >> >> I've been bombed too by this lesoleil and I put its MAILER-DAEMON >> >> into my /var/qmail/control/badmailfrom ;) > >> > Which will *SURELY NOT* work, as the envelope sender for bounces is <> >> > and not <mailer-daemon@...> and badmailfrom does work with the envelope >> > sender and not into the From: field in the message header. > >> It works half a way:I see fetchmail passes undesired mail to qmail >> that accept it but then such a mail never arrives into my Mailbox(!) >> my /var/qmail/control/badmailfrom: >> >> [EMAIL PROTECTED] >> >> So now wonder where those badmail goes? > > You're almost certainly losing _all_ mail with empty envelope sender, > including all bounce messages, and perhaps other automated types of mail. > Your fetchmail configuration is broken. If you care about lost mail, fix it, > or perhaps try my replacement, getmail. > > Charles Charles I already tested and liked your getmail but unfortunately I have to forward incoming mail toward another host-operation not possible with your good and light program (unless you install procbox as I red on FAQ). I'm not loosing nothing other than undesired mail ;) Watching the session with fetchmail -v I note qmail answers: sorry envelope sender is into my BADMAILFROM list ...or something like this for any undesired FROM field I have into ../badmailfrom. I see that's not a smart solution since fetchmail and qmail are working uselessly for what I wanna destroy or bounce away but at least I'm freed of reading such undesired stuff. I'm not a SysAdmin but a complete newbie so hope you'll support my comments. Regards,Marco. > -- > ----------------------------------------------------------------------- > Charles Cazabon <[EMAIL PROTECTED]> > GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ > Any opinions expressed are just that -- my opinions. > -----------------------------------------------------------------------
On Thu, May 03, 2001 at 03:39:59AM -0400, Robin S. Socha wrote: > * Essy Ren <[EMAIL PROTECTED]> [010503 03:33]: > > Can I use qmail in open BSD ? > > Huh? Did you even bother to read http://cr.yp.to/? Like, the line that > starts with DNS? Or how about > http://cr.yp.to/qmail/faq/orientation.html#os? Or even better: how about > man locate? But are you sure a genius like this one will ever succeed in installing OpenBSD prior to start thinking about qmail over it ? I doubt it. -- Stefan Laudat CCNA & CCAI ------------- "I dont suffer from insanity, i enjoy every minute of it!"
Is there a way to get qmail to use the IP that mail is recived in on to resend it back out ? ie My qmail box has a few IP applied to it. 10.1.1.1 10.1.1.2 10.1.1.3 I'd like mail comming in via smtp on 10.1.1.2 to go out useing 10.1.1.2 as the src address. Currently it defaults to 10.1.1.1 IS there a way to do this ?
my qmail-mrtg show that the qmail concurrency value 20 is not enough. anyone can tell me how to increase it. Thanks in advance ---- Chris
concurrency-day.png
On Fri, May 04, 2001 at 12:28:17PM +0800, Chris wrote: > my qmail-mrtg show that the qmail concurrency value 20 is not enough. anyone > can tell me how to increase it. man qmail-send Chris
> my qmail-mrtg show that the qmail concurrency value 20 is not enough. anyone > can tell me how to increase it. > > Thanks in advance > > > ---- > Chris Hi Chris Please read 'FAQ' in your source directory, or have a look at http://www.lifewithqmail.org/lwq.html which is linked from www.qmail.org jason
hi jason why not just say /var/qmail/control/concurrencyremote add it there...have a good day. On Fri, 4 May 2001, Jason Brooke wrote: > Date: Fri, 4 May 2001 14:35:45 +1000 > From: Jason Brooke <[EMAIL PROTECTED]> > To: Chris <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: How to increase the qmail "concurrency"? > > > my qmail-mrtg show that the qmail concurrency value 20 is not enough. anyone > > can tell me how to increase it. > > > > Thanks in advance > > > > > > ---- > > Chris > > > Hi Chris > > Please read 'FAQ' in your source directory, or have a look at > http://www.lifewithqmail.org/lwq.html which is linked from www.qmail.org > > jason > > >
> hi jason why not just say /var/qmail/control/concurrencyremote > > add it there...have a good day. Because I'd prefer to politely teach people to learn to help themselves if they can jason
Hi all, I've set up qmail+mysql on freebsd 4.2 using the ports collection. compilation and installation looks fine. I have this funny feeling that my qmail+mysql setup is somehow wrong. When I do this: root@markus /var/qmail/bin$ ./qmail-getpw whyme alias8181/var/qmail/alias-whymeroot@markus /var/qmail/bin$ This shouldn't happen since the following is my mailbox data: mysql> select * from mailbox; +----------+-----+-----+-----------+----------+---------------+-----------+ | username | uid | gid | home | password | password_type | suspended | +----------+-----+-----+-----------+----------+---------------+-----------+ | whyme | 800 | 800 | /var/mail | whyme | Password | N | +----------+-----+-----+-----------+----------+---------------+-----------+ 1 row in set (0.00 sec) Here are the things I have done: -I've set up mysql to version 3.23.37. -I've created a database in mysql. -Added a user which has full access to the database. -My processes are like these: 36449 p0- I 0:00.01 /bin/sh /usr/local/bin/safe_mysqld --datadir=/var/db/ 36478 p0- S 0:00.60 /usr/local/libexec/mysqld --basedir=/usr/local --data 36678 p0- I 0:00.02 qmail-send 36679 p0- I 0:00.00 splogger qmail 36680 p0- I 0:00.00 qmail-lspawn |preline procmail 36681 p0- I 0:00.00 qmail-rspawn 36682 p0- I 0:00.00 qmail-clean The funny thing is, i can't seem to find the mysql server process, even when i do a 'ps aux'. My aliases/ directory is quite empty: -rw-r--r-- 1 root qmail 0 May 3 11:19 .qmail-mailer-daemon -rw-r--r-- 1 root qmail 0 May 3 11:19 .qmail-postmaster -rw-r--r-- 1 root qmail 0 May 3 11:19 .qmail-root Can anyone pls advise?
Does anyone have experience with HUGE Maildir's? I have an account that is subscribed to a lot of high traffic mailing lists (like this one), and I want to keep all the messages on my server. I have seen grumblings, but no concrete info, on what may happen when your Maildir contains 10,000 or 100,000 or 1,000,000 messages? I am running 2.2.* Linux Thanks.
* List Monkey <[EMAIL PROTECTED]> [010504 01:52]: > Does anyone have experience with HUGE Maildir's? I have an account that > is subscribed to a lot of high traffic mailing lists (like this one), and > I want to keep all the messages on my server. Would you care to elaborate what sort of experiences you're looking for. If you want an answer to "will my buggy and insecure Pine.LNX.4.10 perform well with such a maildir?", you can have it. "No". That is, not unless you filter into folders and read from there. man maildrop. > I have seen grumblings, but no concrete info, on what may happen when your > Maildir contains 10,000 or 100,000 or 1,000,000 messages? What should happen? It's just files. Performance problems are the same as per usual (ext2 being one of the not-so-very-good filesystems for starters). > I am running 2.2.* Linux If this is a real problem for you, you might want to think about taking a look at one of the journalling file systems. You might as well take a look at softupdates and *BSD. -- Robin S. Socha http://my.gnus.org/ - To boldly frobnicate what no newbie has grokked before.
Hi. How do I manually run the queue in qmail? My qmailmachine mapi-mailserver has been down for a couple of hours, and qmail has queued up all the incoming mails. Now the mailserver has been up for 1 hour, but qmail hasnīt started to deliver.
> Hi. How do I manually run the queue in qmail? Read the documentation under administration: http://cr.yp.to/qmail/faq.html FAQs are created because they answer just that, FAQs. -sc -- Sean Chittenden
Read the faq.---
Cordiali saluti / Best regards
Andrea Cerrito
^^^^^^^^^^^^^^
Net.Admin @ Centro MultiMediale di Terni SpA
P.zzale Bosco 3A
05100 Terni IT
Tel. 0744 / 5441330
Fax. 0744 / 5441372-----Messaggio originale-----
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Inviato: venerdė 4 maggio 2001 8.57
A: [EMAIL PROTECTED]
Oggetto: manually run queue
Hi. How do I manually run the queue in qmail? My qmailmachine mapi-mailserver has been down for a couple of hours, and qmail has queued up all the incoming mails. Now the mailserver has been up for 1 hour, but qmail hasnīt started to deliver.
