qmail Digest 8 Aug 1999 10:00:01 -0000 Issue 722
Topics (messages 28683 through 28712):
$HOME must be owned by user?
28683 by: Eric Lammerts <[EMAIL PROTECTED]>
28690 by: [EMAIL PROTECTED] (John R. Levine)
28693 by: Mate Wierdl <[EMAIL PROTECTED]>
28695 by: "Scott D. Yelich" <[EMAIL PROTECTED]>
28696 by: Tomasz Papszun <[EMAIL PROTECTED]>
28697 by: "Scott D. Yelich" <[EMAIL PROTECTED]>
28698 by: Tomasz Papszun <[EMAIL PROTECTED]>
can 'alias' run programs?
28684 by: [EMAIL PROTECTED] (James R Grinter)
Performance
28685 by: Cris Daniluk <[EMAIL PROTECTED]>
28686 by: "Johannes Erdfelt" <[EMAIL PROTECTED]>
28687 by: "Fred Lindberg" <[EMAIL PROTECTED]>
qmail-remote size
28688 by: Cris Daniluk <[EMAIL PROTECTED]>
28689 by: Andre Oppermann <[EMAIL PROTECTED]>
28694 by: Russ Allbery <[EMAIL PROTECTED]>
Qmail newbie POP problem..
28691 by: Mate Wierdl <[EMAIL PROTECTED]>
RH 6.0 compile problem...
28692 by: Mate Wierdl <[EMAIL PROTECTED]>
Bare LF and zombie processes
28699 by: Aaron Nabil <[EMAIL PROTECTED]>
451 See http://pobox.com/~djb/docs/smtplf.html.
28700 by: Aaron Nabil <[EMAIL PROTECTED]>
28701 by: Russell Nelson <[EMAIL PROTECTED]>
28702 by: Aaron Nabil <[EMAIL PROTECTED]>
28703 by: Russell Nelson <[EMAIL PROTECTED]>
28704 by: Aaron Nabil <[EMAIL PROTECTED]>
28705 by: "D. J. Bernstein" <[EMAIL PROTECTED]>
28706 by: Aaron Nabil <[EMAIL PROTECTED]>
28709 by: Aaron Nabil <[EMAIL PROTECTED]>
question about ip hosts and virtual hosts
28707 by: "steve j. kondik" <[EMAIL PROTECTED]>
28708 by: John Gonzalez/netMDC admin <[EMAIL PROTECTED]>
28711 by: "steve j. kondik" <[EMAIL PROTECTED]>
bare line feeds
28710 by: [EMAIL PROTECTED] (John R. Levine)
28712 by: John R Levine <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Fri, 6 Aug 1999, Russell Nelson wrote:
> Given /etc/passwd and the user's home directory, how do you decide
> whether an entry in /etc/passwd should receive mail? Look for a
> .qmail file and give up otherwise? That's a reasonable choice, but it
> involves creating a bunch of .qmail files, all of which are empty.
You could deliver mail if the user own his home directory OR if a
.qmail file exists.
> But also consider that qmail-local runs as the user, and if the user
> doesn't own their home directory, they can't modify their mailbox.
You don't necessarily need those rights. Maybe a maildir is used that
is owned by the user, or something like '|/usr/cyrus/bin/deliver $USER'.
Eric
--
Eric Lammerts <[EMAIL PROTECTED]>
"Don't you know there ain't no devil?
There's just God when he's drunk." -- Tom Waits
>You don't necessarily need those rights. Maybe a maildir is used that
>is owned by the user, or something like '|/usr/cyrus/bin/deliver $USER'.
Those are perfectly reasonable ways to deliver mail. If you don't
want users to be able to change their delivery rules, make a
users/assign that doesn't list those users, and create
~alias/.qmail-whoever files with the delivery rules you want to use.
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
Well, part of qmail's philosophy is to give more control to the user (so the
admin is bothered less).
If you want to give part of the control back to root, use qmail-users.
(On the side: my home dir is my homedir. Even if root owns files in it, I
can delete them. Try
su -
echo '|supercontrol.sh' > ~user/.qmail
chmod -xrw ~user/.qmail
su - user
rm .qmail
)
Mate
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, 7 Aug 1999, Mate Wierdl wrote:
> If you want to give part of the control back to root, use qmail-users.
I may end up going this way, it might just be cleaner...
> (On the side: my home dir is my homedir. Even if root owns files in it, I
> can delete them. Try
> su -
> echo '|supercontrol.sh' > ~user/.qmail
> chmod -xrw ~user/.qmail
> su - user
> rm .qmail
>
> )
not really. "mv"ing a file is controlled by write permissions on the
dir... right. Modifying the contents of a file is controlled by write
perms on the file (well, I treat a dir like any other file, but
anyways)...
I have the user owning $HOME, and u-w (and go-w too) .... I have root
owning the .qmail files (not that this seems to really do anything or
phase qmail). The users don't have shells, but they do have ftp access.
They "could" write to $HOME provided the perms were there. As I said in
a private message to someone, I just need to see if my ftpd allows chmod
- -- if not, I appear to have what I want. I haven't decided if
users/assign would make things easier. I'll think about it.
Thanks for all the discussion and suggestions.
Scott
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBN6yxhx4PLs9vCOqdAQHQBgP8DbcEb8b8c+UF9hDEwJQCQwZd4Y3NCFcX
PvQHOZetgvbLKTKcjzm6jzMgg86bAw5djk7omOFbgnuwrh2l+4VppTzP+Yj9qhtP
rqX9+3ZPzIiwXO/huCCdHjIpJZq4+TKWjOTJwqOHv7xF6jeElPvKLBYy27PS33YZ
eKY1EP99UfY=
=ILM1
-----END PGP SIGNATURE-----
On Sat, 07 Aug 1999 at 16:21:59 -0600, Scott D. Yelich wrote:
> On Sat, 7 Aug 1999, Mate Wierdl wrote:
> > If you want to give part of the control back to root, use qmail-users.
>
> I may end up going this way, it might just be cleaner...
> [...]
> I have the user owning $HOME, and u-w (and go-w too) .... I have root
> owning the .qmail files (not that this seems to really do anything or
> phase qmail). The users don't have shells, but they do have ftp access.
> They "could" write to $HOME provided the perms were there. As I said in
> a private message to someone, I just need to see if my ftpd allows chmod
> - -- if not, I appear to have what I want. I haven't decided if
> users/assign would make things easier. I'll think about it.
Off-qmail, but as we discuss this topic...
E.g. using proftpd admin can make files _not_ owned by luser
non-visible for luser. An excerpt from proftpd.conf:
<Directory ~luser>
HideUser root
HideNoAccess
<Limit ALL>
IgnoreHidden on
</Limit>
</Directory>
--
Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only
[EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 8 Aug 1999, Tomasz Papszun wrote:
> E.g. using proftpd admin can make files _not_ owned by luser
> non-visible for luser. An excerpt from proftpd.conf:
>
> <Directory ~luser>
> HideUser root
> HideNoAccess
> <Limit ALL>
> IgnoreHidden on
> </Limit>
> </Directory>
I'm using wuftpd-vr17 as mentioned before. I tried proftpd, but it
would not chroot under solaris so I went back to wuftpd.
Scott
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBN6y7Gh4PLs9vCOqdAQEeFgP/dNlS/t4vvn8qFn2vtrKPFPwN9zktemyG
jOSnynS/cGVk8wIpZ0o9VZ+rNwm+6Cvt6NQEPkQu5TQf/v2RMtV5IR2Fo53Y70ql
XdqNv+4tHsm0HmtEDCgP4RmDf4LN6nR482n5B1NV1AdMl0ubtV5m/uq5cvvE6Crf
0odsBwwh6Ds=
=iLjQ
-----END PGP SIGNATURE-----
On Sat, 07 Aug 1999 at 17:02:50 -0600, Scott D. Yelich wrote:
>
> I'm using wuftpd-vr17 as mentioned before. I tried proftpd, but it
> would not chroot under solaris so I went back to wuftpd.
For me, it works. Sol. 2.5.1.
Making some "devices" is needed. After that, proftpd chroots.
I don't know which Solaris you use but according to README.Solaris2.5x
(where adding devices is described), in 2.6 this is no longer necessary.
--
Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only
[EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
Brian Reichert <[EMAIL PROTECTED]> writes:
> But I'm alive now. Once I get a properly fleshed-out invokation
> of sendpage, I'll mention it on the list, as it looks handy for
> people...
I call a shell script that calls sendpage. Why? To match up the return
codes with what qmail wants:
/usr/local/etc/sendpage -B -S -f $SENDER $EXT2
[ $pid -eq 0 ] && exit 0
# user invited to retry
[ $pid -eq 75 ] && exit 100
# fail
exit 100
James.
Yes, in fact, the actual processing of the message was virtually
instantaneous... there was rarely more than 3 or 4 messages not yet
processed despite the fact that we were sending in over 100 messages per
second. I love raid :)
Right now, we've been doing tests sending out to servers inside the
office. We've been experimenting with 20kb messages (as the real world
messages will be close to that size), sending them to Microsoft SMTP
servers (which do no processing). We wrote a mail eater that will monitor
the ms smtp server's queue and eat everything in it, keeping track of how
fast mail is coming in. For a good idea of how impressive this all really
is... one workstation running ms smtp was receiving from qmail at ~8
messages per second. Not too impressive. So, we added 4 more servers
receiving and then send equal messages to all of them. They recieved at 8
per second too. The catch? Concurrencyremote was set to the default 20.
Once we finished that test, I increaeed it to 255. Then, each server
started receiving ~30 messages per second. That mean qmail is sending 150
messages per second. Memory usage is pretty high (255 qmails after all)
but processor usage is almot negligible (with logging OFF). These results
are very entertaining because we couldn't even fill the queue that fast :)
(we're currently filling the queue with qmail-send off as it seems to be
faster that way). We currently believe that our bottleneck is disk access,
so we're going to increase the writeback cache on the raid controller to
256mb. We're also going to put in 4 network cards as I mentioned before,
each with its own qmail. Once this is complete, we're going to take all
the computers in our part of the building and set them to eat mail. We
believe we can acheive maximum utilization out of the network, without
pushing our raid or memory/cpu. This should allow us to send an incredible
500 messages per second on a machine that costs about 10% of the NT server
that couldn't send faster than 30 messages on a lan (and 5 messages
externally). I'll report back more when we try this benchmark. I expect
we'll have incredible results.
Cris Daniluk
MicroStrategy
(ps excuse all my missing s's, its sticking on my laptop and you can only
fix it so many times! :)
On Fri, 6 Aug 1999, Mark Delany wrote:
> At 03:38 PM Friday 8/6/99, Jim Arnott wrote:
>
> >Wow, thats very impressive throughput.
> >-jim
>
>
> I just hope that the queue was actually processed at that rate. Sure you can
> invoke qmail-inject and have all the messages in todo, but they really need
> to be processed by qmail-send before you can say the queue injection is
> complete.
>
> Cris? Did you actually check the output of qmail-qstat at the end of that
> test to ensure that
>
> "messages in queue but not yet preprocessed" was zero?
>
>
> Mark.
>
>
>
> > >
> > > Well, we're starting into our testing of qmail so that we can transition
> > > away from the garbage-polluted ms smtp server that we had such a long
> > thread
> > > about earlier this week.
> > >
> > > Basically, we constructed a temporary system for benchmarking. It is a dual
> > > p2 400 with a dpt smartraid5 controller and 64mb cache. We put in 2 9.1gb
> > > cheetahs on a raid 0 stripe. The system has 160mb ram.
> > >
> > > The first benchmark we ran was to see how fast we could populate the queue.
> > > I made a script to sequentially fill the queue with 20kb messages. It was
> > > able to do 2000 20kb messages in approximately 16 seconds (precision was
> > > only to the second, so 15.1-16.9 are valid ranges). 125 messages per second
> > > is more than adequate for our needs. I was very impressed by the fact that
> > > qmail could populate the queue so quickly. I think that definitely goes to
> > > show the scalability of qmail.
> > >
> > > The next test we're going to do is to use it as a mail relay, relaying from
> > > the message generator machines out to the net. For the short term, we are
> > > going to run 4 separate qmails with 4 separate queues. Each instance
> > will be
> > > on a separate ip, though. What needs to be done to qmail to make it bind to
> > > a specific IP? This is pretty vital that we bind to separate ips because
> > > eventually we will be putting in 4 network cards (one for each queue).
> > >
> > > To further increase our hardware aresenal, once we find the optimal
> > > performance setup, we're going to build 5 of them. We'll have 5 machines
> > > generating mail, 5 sending, and we hope to be able to send upward of 10
> > > million or more per day. At that time we'll also have a 256mb cache on the
> > > raid controller so that the queue can run much more efficiently.
> > >
> > > I think that everyone on the qmail list deserves a big thanks from all
> > of us
> > > for the valuable information and insight. It appears that qmail will be a
> > > successful solution for us, and ironically, thousands of dollars cheaper
> > > than the Big Hardware Big Software microsoft solution that we were using
> > > before.
> > >
> > > Once we get the network cards in and binded, we'll be on our way to a
> > > wonderful solution...
> > >
> > > Cris Daniluk
> > > MicroStrategy
> > >
> >
>
>
On Sat, Aug 07, 1999, Cris Daniluk <[EMAIL PROTECTED]> wrote:
> Concurrencyremote was set to the default 20.
> Once we finished that test, I increaeed it to 255. Then, each server
> started receiving ~30 messages per second. That mean qmail is sending 150
> messages per second. Memory usage is pretty high (255 qmails after all)
> but processor usage is almot negligible (with logging OFF).
Be careful calculating the memory usage. On my Linux mail exploder, a
qmail-remote process looks like this:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
17156 qmailr 1 0 408 408 332 S 0 0.1 0.0 0:00 qmail-remote
Only 76k per qmail-remote process was unique. With a concurrencyremote
set to 1000, that's a maximum of 76MB total. This is nothing.
This mail server does close to 1 Million messages a day barely breaking
a .1 load average. Talk about light weight!
BTW - The 1000 concurrent delivery limit is not to keep up with all of the
deliveries, but rather to keep the latency of our 10,000+ subscriber
lists down.
JE
On Fri, 6 Aug 1999 16:31:10 -0400, Cris Daniluk wrote:
>The next test we're going to do is to use it as a mail relay, relaying from
>the message generator machines out to the net. For the short term, we are
>going to run 4 separate qmails with 4 separate queues. Each instance will be
That'll be interesting. With a concurrency of e.g. 255, an ideal test
system behaves much better than the net, since a number of your clients
will hang on to connections for a long time or time out, so that client
response time becomes limiting. The qmail-bigrem.path discussed on the
list might help. With your kind of hardware, you might be able to
support more than a 4x 255 concurrency.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Someone in an earlier message (I appologize for not remembering who)
brought up the point that qmail lies about it size in memory because it
uses shared memory. He said that qmail-remote would take up about 76kb of
its own memory on his own machine. However, variou things will affect this
size undoubtedly. Will qmail-remote store the message its sending in
memory? If so, would it be reasonable to expect maybe 90kb per
qmail-remote with 20kb messages? I think its safe to say that these are
small differences, we're talking about a few kb here and there, but when
you multiply by 255*4, it adds up quick :) What would be a reasonable
memory footprint for a qmail-remote sending a 20kb message?
Cris Daniluk
MicroStrategy
Cris Daniluk wrote:
>
> Someone in an earlier message (I appologize for not remembering who)
> brought up the point that qmail lies about it size in memory because it
> uses shared memory. He said that qmail-remote would take up about 76kb of
> its own memory on his own machine. However, variou things will affect this
> size undoubtedly. Will qmail-remote store the message its sending in
> memory? If so, would it be reasonable to expect maybe 90kb per
> qmail-remote with 20kb messages? I think its safe to say that these are
> small differences, we're talking about a few kb here and there, but when
> you multiply by 255*4, it adds up quick :) What would be a reasonable
> memory footprint for a qmail-remote sending a 20kb message?
It does not store the message in memory. It get's it through a pipe
from qmail-rspawn which reads it from disk.
--
Andre
Cris Daniluk <[EMAIL PROTECTED]> writes:
> Someone in an earlier message (I appologize for not remembering who)
> brought up the point that qmail lies about it size in memory because it
> uses shared memory.
In the pedant department, I feel obligated to point out that qmail isn't
really lying to you; your system ps is. Nearly everything your system is
running is using shared memory since dynamic libraries are shared across
all programs on your system that use them (and nearly everything uses
libc) and if multiple copies of a given program are running, every modern
Unix will share the program code across all copies. It's not a phenomenon
specific to qmail.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Can you show us a a whole telnet session to port 110 ? (Do it as a regular
user).
How did you make the Maildir? Not as root for the regular user, I hope.
What is the output of
ls -lR ~/Maildir
Mate
Ps
BTWY, it seems that many (most?) people who set up qmail on their Linux
boxes think they have to run pop3d service; otherwise Netscape will not work.
If nobody dials in to your box, leave pop alone.
You probably do not have the glibc-devel package installed.
Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Ferhat Doruk writes...
>After some our client's Bare LF problem, I used fixcr according to DJB's
>suggestion and I started qmail-smtpd process by using a command like this:
I'd suggest instead you simply patch Qmail.
Below is an article I never got around to posting, it has a patch that
should work. I guess I never posted it becuase there seems to be
some kind of unwritten rule that if qmail does something unusual or
unexpected, it's because the RFC says to do it that way. And if the
RFC says to do it some other way, the way Qmail is doing it is actually
better.
-------
Qmail advertises itself as supporting 8BITMIME. In no sense whatsoever
does it support 8BITMIME (well, other than printing 8BITMIME as a
response to a EHLO).
# telnet qmail.org smtp
Trying 192.203.178.37...
Connected to qmail.org.
Escape character is '^]'.
220 ns.crynwr.com NO UCE ESMTP
EHLO erehwon.org
250-ns.crynwr.com NO UCE
250-PIPELINING
250 8BITMIME
According to RFC 1652,
A server which supports the 8-bit MIME transport service extension
shall preserve all bits in each octet passed using the DATA command.
Qmail will not pass, let alone preserve the bits of bare LF's in the DATA
phase. It detects them as "stray new lines", and bombs out in the middle
of message collection and closes the connection. This termination before
quit violates section 4.1.1 of RFC 821 and was responsible for a near
catastrophe last week which when a NT server (which consider a dropped
onnection an invitation to immediatly retry the failed message about
.2 secs later, charming) started a mailing list delivery run to our
server. This interaction resulted in several million failed messages
delivery attempts over a span of several days.
Since Qmail doesn't contain any code to check for the 8BITMIME message
type indicator (which looks like this on a MAIL FROM command)
MAIL FROM:<[EMAIL PROTECTED]> BODY=8BITMIME
it will also silently transform CRLF pairs into the local \n, also a
violation of RFC 1652 for BODY=8BITMIME messages.
Qmail is not RFC 822 compliant either, although it's reasonable for the
MTA to restructure bare LF's according to local end-of-line conventions,
bare LF's are perfectly _legal_ in the message body and the MTA can't
refuse to process messages that contain them, like Qmail does as
described above.
>From the RFC 822 BNF...
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
Note that some measure of RFC 822 compliance can be achieved by simply
commenting a few lines in qmail-smtpd.c, like...
switch(state) {
case 0:
/* if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 4; continue; }
break;
case 1: /* \r\n */
/* if (ch == '\n') straynewline(); */
if (ch == '.') { state = 2; continue; }
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 2: /* \r\n + . */
/* if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 3; continue; }
state = 0;
break;
case 3: /* \r\n + .\r */
if (ch == '\n') return;
put(".");
put("\r");
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 4: /* + \r */
if (ch == '\n') { state = 1; break; }
if (ch != '\r') { put("\r"); state = 0; }
}
If Qmail wants to detect people terminating lines with bare LF's, it
needs to do that before it gets to the DATA phase.
It's somewhat amusing to note in the author's page at
ftp://koobera.math.uic.edu/www/docs/smtplf.html
"Even if this slight message corruption is acceptable for the
end users, it is dangerous behavior, since LF dot LF can legitimately
appear in the middle of a binary mail message."
that qmail won't permit a "legitimate" LF dot LF in a message either!
Qmail's MIME behavior also results in some undesirable auto-conversion
when it is in a message delivery chain,
mua -> sendmail --> qmail --> sendmail
since qmail is promising to the upstream sendmail that it will
keep the 8BITMIME intact, when in fact it does a "just send 8" to
the next sendmail which will cause it to auto-convert when it
detects the incoming 8 bit data.
--
Aaron Nabil
Robin Bowes writes...
>I'm seeing the above error message in the log for my MS Mail gateway
>(MailBeamer), but only for 1 particular message.
>
> . . .
>I've looked at Dan's explanation of the problem and I am aware of the
>SMTP LF issue. My problem is why should this error occur just for 1
>message? I mean, if *every* message had the same problem, I could
>understand it and would put it down to a broken program, but for just 1
>message to cause the error? Seems strange to me...
The problem is Qmail.
The message in question had a "bare LF" in it, perfectly legal, but
qmail barfs on them. I just posted a message describing the
phenomena in more detail.
--
Aaron Nabil
Aaron Nabil writes:
> Robin Bowes writes...
> >I'm seeing the above error message in the log for my MS Mail gateway
> >(MailBeamer), but only for 1 particular message.
> >
> > . . .
> >I've looked at Dan's explanation of the problem and I am aware of the
> >SMTP LF issue. My problem is why should this error occur just for 1
> >message? I mean, if *every* message had the same problem, I could
> >understand it and would put it down to a broken program, but for just 1
> >message to cause the error? Seems strange to me...
>
> The problem is Qmail.
>
> The message in question had a "bare LF" in it, perfectly legal, but
> qmail barfs on them. I just posted a message describing the
> phenomena in more detail.
Aaron, how would you store the following one-line message sequence of
characters received by a DATA command into a Unix mailbox without
losing information? Nevermind which MTA is doing it -- just tell me
what you think the Unix mailbox would look like at the end of the process.
"<headers><CR><LF>beginning of line 1<LF>more of line 1<CR><LF>".
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Russell Nelson writes...
>Aaron Nabil writes:
> > Robin Bowes writes...
> > >I'm seeing the above error message in the log for my MS Mail gateway
> > >(MailBeamer), but only for 1 particular message.
> > >
> > > . . .
> > >I've looked at Dan's explanation of the problem and I am aware of the
> > >SMTP LF issue. My problem is why should this error occur just for 1
> > >message? I mean, if *every* message had the same problem, I could
> > >understand it and would put it down to a broken program, but for just 1
> > >message to cause the error? Seems strange to me...
> >
> > The problem is Qmail.
> >
> > The message in question had a "bare LF" in it, perfectly legal, but
> > qmail barfs on them. I just posted a message describing the
> > phenomena in more detail.
>
>Aaron, how would you store the following one-line message sequence of
>characters received by a DATA command into a Unix mailbox without
>losing information? Nevermind which MTA is doing it -- just tell me
>what you think the Unix mailbox would look like at the end of the process.
>
>"<headers><CR><LF>beginning of line 1<LF>more of line 1<CR><LF>".
I love puzzles!
But I'm not sure what you mean by "one line", other than you typed it
on one line.
So just to make sure we are talking about the same thing...
DATA
<headers><CR><LF>
beginning of line 1<LF>more of line 1<CR><LF>
.<CR><LF>
right?
Well, the easy one first. If the message was sent as a normal RFC-822
only message, I'd expect the unix mailbox to contain...
<headers>\n
beginning of line 1\n
more of line 1\n
since RFC-822 anticipates local newline conversions.
whereas if it were a MIME message sent with 8BITMIME, I'd expect something
like...
<headers>\r\n
beginning of line 1\n
more of line 1\r\n
I guess if this is really important, we could try feeding such a message
to sendmail with 8BITMIME and see what it does.
But I'm not sure I see where this is going. Qmail would never deliver
such a message, it would barf. The case you are also stating in specifically
one of delivery, where local newline standards come into play. What about
the case of transport?
--
Aaron Nabil
Aaron Nabil writes:
> I guess if this is really important, we could try feeding such a message
> to sendmail with 8BITMIME and see what it does.
sendmail is not an example implementation.
> But I'm not sure I see where this is going. Qmail would never deliver
> such a message, it would barf. The case you are also stating in specifically
> one of delivery, where local newline standards come into play. What about
> the case of transport?
Qmail does not distinguish between delivery and transport, therefore
it can store the messages in a file which use newlines for a line
terminator. Thus, qmail cannot accept bare newlines, since such a
message cannot be reconstructed once it's been in a queue or mailbox
file.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Russell Nelson writes...
> > But I'm not sure I see where this is going. Qmail would never deliver
> > such a message, it would barf. The case you are also stating in specifically
> > one of delivery, where local newline standards come into play. What about
> > the case of transport?
>
>Qmail does not distinguish between delivery and transport, therefore
>it can store the messages in a file which use newlines for a line
>terminator.
Well, sort of. It doesn't distinguish between delivery and transport
in the sense that it coerces all tranported message into a local
delivery format.
Is this supposed to be a qmail feature?
>Thus, qmail cannot accept bare newlines, since such a
>message cannot be reconstructed once it's been in a queue or mailbox
>file.
Cannot be reconstructed? You have entirely lost me. Is that exactly
the question you posed me, reconstructing a message with embedded
bare LF's? Was something wrong with my answer?
It also sounds like you are saying that qmail must refuse to transport
messages that it doesn't have the local ability to reconstruct. That
seems awfully presumptuous of qmail, denying transport say, to sendmail,
simply on the basis of some potential ambiguity in qmail's local
delivery environment and projecting that ambiguity onto the target
delivery enviroment. It's entirely possible the the recipient MTA
at the end of the transport has no such ambiguity, why in the world would
qmail try to enforce such a silly restriction? Qmail is saying, "I AM
QMAIL, IF THIS MAIL WAS DESTINED FOR LOCAL DELIVERY I WOULDN'T KNOW
WHAT TO DO WITH IT, THEREFORE I WILL REFUSE TO TRANSPORT IT TO ANOTHER
MTA THAT MIGHT POSSIBLY BE ABLE TO DELIVER IT WITH NO AMBIGUITY." Pretty
damn cheeky.
--
Aaron Nabil
Aaron Nabil writes:
> The message in question had a "bare LF" in it, perfectly legal,
Bare LFs are now categorically prohibited by 822bis. They were never
handled correctly by sendmail. The client's behavior is inexcusable.
---Dan
D. J. Bernstein writes...
>Aaron Nabil writes:
>> The message in question had a "bare LF" in it, perfectly legal,
>
>Bare LFs are now categorically prohibited by 822bis. They were never
>handled correctly by sendmail. The client's behavior is inexcusable.
I guess not having access to 822bis, I'll have to ask for clarification.
Are bare LF's themselves prohibited? Or is it the treating of bare
LF's as line terminators that is prohibited?
What about in 8BITMIME messages? No bare LF's allowed at all?
--
Aaron Nabil
Following up on my own message...
Aaron Nabil writes...
>D. J. Bernstein writes...
>>Aaron Nabil writes:
>>> The message in question had a "bare LF" in it, perfectly legal,
>>
>>Bare LFs are now categorically prohibited by 822bis. They were never
>>handled correctly by sendmail. The client's behavior is inexcusable.
>
>I guess not having access to 822bis, I'll have to ask for clarification.
>
>Are bare LF's themselves prohibited? Or is it the treating of bare
>LF's as line terminators that is prohibited?
I found draft-ietf-drums-msg-fmt, which seems to be the
822bis-in-progress.
2.3. Body
The body of a message is simply lines of US-ASCII characters. The only
two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
which would seem to address the question of 822bis messages. But
my question about MIME messages still remains, the draft goes on
to read...
- Lines of characters in the body MUST be limited to 998 characters, and
SHOULD be limited to 78 characters, excluding the CRLF.
Note: As was stated earlier, there are other standards documents,
specifically the MIME documents [RFC-2045, RFC-2046, RFC-2048, RFC-2049]
that extend this standard to allow for different sorts of message
bodies. Again, these mechanisms are beyond the scope of this document.
My question about 8BITMIME messages remains. Would a bare LF be
legal? I'm not suggesting that a bare LF be treated a line terminator.
In any case, I'm not sure where 822bis sits on the standards track, but
wouldn't it be reasonable to require an MTA to interopertate with MTAs
that are following real, published, approved RFCs like RFC-822 and
RFC-1652?
Thanks,
--
Aaron Nabil
i've scoured the documentation and haven't figured out how to do this yet..
here is my situation..
my box has several ips, lets say domain1.com and domain2.com as well as some
normal vpops, which work fine. now here is the problem, mail for
[EMAIL PROTECTED] should go to user1 and mail for [EMAIL PROTECTED]
should go to user2, now, both domain1 and domain2 are on the same box, using
ip aliasing and all the users who recieve mail for these 2 domains have real
shells on the box. is this possible without running multiple instances of qmail
for each ip?
this is probably easy, im just missing something here.
thanks in advance,
-steve
sure, very very simple.
Make sure that the virtual domains are in the
/var/qmail/control/virtualdomains file, and NOT in the locals file.
Make a user on the box called 'user1'
Now, in your /var/qmail/control/virtualdomains file, have this:
www.virtualdomain1.com:alias-virtualdomain1
www.virtualdomain2.com:alias-virtualdomain2
in the /var/qmail/alias directory, create files named:
.qmail-virtualdomain1-webmaster
inside that file, put
&[EMAIL PROTECTED]
and the mail for [EMAIL PROTECTED] will be forwarded to him.
You can do this with any address you want @virtualdomainX.com
On Sun, 8 Aug 1999, steve j. kondik wrote:
>i've scoured the documentation and haven't figured out how to do this yet..
>here is my situation..
>
>my box has several ips, lets say domain1.com and domain2.com as well as some
>normal vpops, which work fine. now here is the problem, mail for
>[EMAIL PROTECTED] should go to user1 and mail for [EMAIL PROTECTED]
>should go to user2, now, both domain1 and domain2 are on the same box, using
>ip aliasing and all the users who recieve mail for these 2 domains have real
>shells on the box. is this possible without running multiple instances of qmail
>for each ip?
>
>this is probably easy, im just missing something here.
>
>thanks in advance,
>-steve
>
_ __ _____ __ _________
______________ /_______ ___ ____ /______ John Gonzalez/Net.Tech
__ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC!
_ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052
/_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com
[---------------------------------------------[system info]-----------]
11:55pm up 16 days, 8:48, 3 users, load average: 0.00, 0.05, 0.07
thanks much, qmail suddenly seems much clearer now ;>
-steve
On 08/07/99 @ 11:59PM, John Gonzalez/netMDC admin wrote:
>
> sure, very very simple.
>
> Make sure that the virtual domains are in the
> /var/qmail/control/virtualdomains file, and NOT in the locals file.
>
> Make a user on the box called 'user1'
>
> Now, in your /var/qmail/control/virtualdomains file, have this:
>
> www.virtualdomain1.com:alias-virtualdomain1
> www.virtualdomain2.com:alias-virtualdomain2
>
> in the /var/qmail/alias directory, create files named:
>
> .qmail-virtualdomain1-webmaster
>
> inside that file, put
> &[EMAIL PROTECTED]
>
> and the mail for [EMAIL PROTECTED] will be forwarded to him.
> You can do this with any address you want @virtualdomainX.com
>
> On Sun, 8 Aug 1999, steve j. kondik wrote:
>
> >i've scoured the documentation and haven't figured out how to do this yet..
> >here is my situation..
> >
> >my box has several ips, lets say domain1.com and domain2.com as well as some
> >normal vpops, which work fine. now here is the problem, mail for
> >[EMAIL PROTECTED] should go to user1 and mail for [EMAIL PROTECTED]
> >should go to user2, now, both domain1 and domain2 are on the same box, using
> >ip aliasing and all the users who recieve mail for these 2 domains have real
> >shells on the box. is this possible without running multiple instances of qmail
> >for each ip?
> >
> >this is probably easy, im just missing something here.
> >
> >thanks in advance,
> >-steve
> >
>
> _ __ _____ __ _________
> ______________ /_______ ___ ____ /______ John Gonzalez/Net.Tech
> __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC!
> _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052
> /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com
> [---------------------------------------------[system info]-----------]
> 11:55pm up 16 days, 8:48, 3 users, load average: 0.00, 0.05, 0.07
>>Bare LFs are now categorically prohibited by 822bis. They were never
>>handled correctly by sendmail. The client's behavior is inexcusable.
>
>I guess not having access to 822bis, I'll have to ask for clarification.
Everyone has access to it. It's at
http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-07.txt
>Are bare LF's themselves prohibited? Or is it the treating of bare
>LF's as line terminators that is prohibited?
It says:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
>What about in 8BITMIME messages? No bare LF's allowed at all?
822bis says that it doesn't define MIME, but RFC 2045 which does says:
2.8. 8bit Data
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
>>Bare LFs are now categorically prohibited by 822bis. They were never
>>handled correctly by sendmail. The client's behavior is inexcusable.
>
>I guess not having access to 822bis, I'll have to ask for clarification.
It's at
http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-07.txt
>Are bare LF's themselves prohibited? Or is it the treating of bare
>LF's as line terminators that is prohibited?
It says:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
>What about in 8BITMIME messages? No bare LF's allowed at all?
822bis says that it doesn't define MIME, but RFC 2045 which does says:
2.8. 8bit Data
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
