|
|
| Author |
Message |
| 25 new of 467 responses total. |
cross
|
|
response 378 of 467:
| 
Dec 29 16:33 UTC 2004 |
No need to apologize Sindi.
However, I do see grex's mail logs bouncing mail sent to pipes. It appears
to be a problem with shell syntax in .forward files; I'm not convinced exim
is piping commands from .forward's into sh.
|
blaise
|
|
response 379 of 467:
|
Dec 29 17:11 UTC 2004 |
I think I know what the syntax error is; sendmail expected commands to
be quoted, and IIRC exim does not. I am testing that now.
|
blaise
|
|
response 380 of 467:
|
Dec 29 17:23 UTC 2004 |
OK, I have verified that the following text in a .forward file sends
messages through procmail successfully:
|/usr/local/bin/procmail
|
keesan
|
|
response 381 of 467:
|
Dec 29 19:11 UTC 2004 |
You don't need the -f- any more (or the " ")? It appears to be working okay
for me now with -f- (but for some reason mails from keesan@ all go to my inbox
despite spammish subject lines - no big deal).
|
blaise
|
|
response 382 of 467:
|
Dec 29 19:25 UTC 2004 |
The -f- tells procmail to update the "From " line in the message
envelope (not the From: header) with the current timestamp. My personal
opinion is that this is not only unnecessary but a poor idea; that
original timestamp may be useful in analyzing a message (for example, if
it is thought to be a forgery).
As I mentioned in the System Problems item in the Winter Agora, the
reason the filters are not catching emails from yourself is that you
have a whitelisting for From:.*grex in the middle of your /dev/null blocks.
|
gelinas
|
|
response 383 of 467:
|
Dec 29 22:41 UTC 2004 |
Some of the people who tested the new machine had a mail spool file on the
machine. I appended those files to the mail spool files moved over from the
old machine. That's why you have some October messages after your December
messages, Sindi.
|
keesan
|
|
response 384 of 467:
|
Dec 30 03:05 UTC 2004 |
Thanks for the explanation, Joe, which also explains why my four appended
mails had to do with next grex. Blaise, I will remove the -f- and I already
deleted from my whitelist keesan, grex, org and edu. I go back and forth
between having them on the whitelist, depending on how much spam they have
caught recently, and how much real mail gets sent to /dev/null.
This is great, mail is already working properly and it is not even 2005!
(Not counting problems with elm, of course). The file transfer problems are
less urgent at least for those of us with ftp (which I ought to test now).
|
jp2
|
|
response 385 of 467:
|
Dec 31 02:51 UTC 2004 |
This response has been erased.
|
jp2
|
|
response 386 of 467:
|
Dec 31 03:01 UTC 2004 |
This response has been erased.
|
mfp
|
|
response 387 of 467:
|
Dec 31 03:27 UTC 2004 |
"older version" shouldn't be hyphenated.
|
cross
|
|
response 388 of 467:
|
Dec 31 06:08 UTC 2004 |
OpenBSD does kqueue; that's not an issue. I rewrote the watch.c used
here on grex and it does what's needed. If we want to port uwatch, I'm
not opposed to it.
|
mfp
|
|
response 389 of 467:
|
Jan 1 06:29 UTC 2005 |
I, contrariwise, am.
|
nharmon
|
|
response 390 of 467:
|
Jan 4 02:21 UTC 2005 |
Regarding the previous problem of mail stopping up Grex by filling the /var
partition...
Has Grex ever considered using Qmail for its email system? It has the
advantage of storing mail spool files in user home directories, thus
subjecting them to quota limits.
|
gelinas
|
|
response 391 of 467:
|
Jan 4 03:19 UTC 2005 |
We could configure any mail system to deliver to home directories. I, at
least, don't think that is a good idea.
When mail delivery to a shared space is set up properly, it is hard to deny
service to a single user. Right now, we don't have it set up properly,
obviously. (We did have it done properly on the old machine, and we will get
it set up here eventually.)
When mail is delivered to a user's home directory, it is very easy to deny
service to a single user by simply flooding them with mail. When they hit
quota, a lot of things start going on that novice uers (grex's primary
audience, remember) simply don't undeerstand. And some things break in such
a way that they can't easily fix it themselves.
Let's not go there, 'kay?
|
keesan
|
|
response 392 of 467:
|
Jan 4 04:12 UTC 2005 |
If a user gets sent 100 10K spams in half an hour, don't they still get
service denied?
|
gelinas
|
|
response 393 of 467:
|
Jan 4 04:21 UTC 2005 |
Only mail, not everything they do.
|
janc
|
|
response 394 of 467:
|
Jan 4 15:01 UTC 2005 |
I don't see any big advantages to delivery to home directories. What we are
doing now can be made secure and reliable. Delivery to home directories can
be made secure and reliable. The problem that started this discussion, namely
mail filling up /var, was a configuration error that has been fixed and that
will never happen again. (I had failed to mount the /var/mail disk
partition, so mail was being delivered into the /var partition, which was
never intended to have mail on it and so was not sized large enough to
accommodate mail.)
|
gelinas
|
|
response 395 of 467:
|
Jan 5 03:05 UTC 2005 |
(The fault was not all yours, Jan: I put the mail spool files in place; I
could and should have checked to make sure the right partition was mounted
first.)
|
albaugh
|
|
response 396 of 467:
|
Jan 14 18:23 UTC 2005 |
I guess this is as good as any item for bringing up the following:
I don't recall seeing anywhere in coop or agora the mentioning that the O/S
for nextgrex would apparently relax a restriction (I'm assuming it was) from
the O/S of old grex such that under nextgrex userIDs could be longer than
8 characters. This may have been considered one of those technical things
that only needed to be covered in garage - I don't know.
But personally speaking, I would like to retain the 8-character-maximum length
for userIDs, under nextgrex, even if the O/S supports longer ones. I have
already seen in agora that there are others who already agree that a
restriction in userID length is desired (although maybe 12 or 16).
How do you recommend that I proceed on this issue? Create another ill-fated
membership vote?
|
remmers
|
|
response 397 of 467:
|
Jan 14 19:33 UTC 2005 |
Let's start by just discussing it here, before setting bureacratic
mechanisms in motion. If a concensus emerges that people would like
a shorter limit, staff can just *do* it.
My preference would be to retain the old 8-character limit, for a few
reasons, some better than others:
(a) It wasn't broken.
(b) Increasing the limit could break some software that assumes the
old 8-character standard. (No sign of this yet, but it hasn't
been tested.)
(c) Long login id's mess up formatting of column-oriented listings
that include login id's (e.g. who, finger)
(d) Long login id's are inconvenient to reference (e.g. in email
addresses, URL's, and other contexts).
I think 32 characters is way too large a maximum. I'd prefer 8 but
could live with 12.
|
mfp
|
|
response 398 of 467:
|
Jan 14 20:09 UTC 2005 |
Keep in mind that the maximum is 31, not 32.
|
remmers
|
|
response 399 of 467:
|
Jan 14 20:39 UTC 2005 |
Sub-reason for (c) in #397 above: Party formatting gets messed up.
Sub-reason for (d): It's a pain to :ignore someone with a 27-character
login, since you have to pass the login as a parameter to :ignore.
|
mfp
|
|
response 400 of 467:
|
Jan 14 20:43 UTC 2005 |
keep in mind it's also a pain to use a 27-character login, so don'
t expect too many of them.
|
keesan
|
|
response 401 of 467:
|
Jan 14 22:43 UTC 2005 |
I would be happy with 6 characters but jdeigert might like 8. I cannot think
of a situation where anyone would need more than 8. What is the theoretical
minimum needed for 24,000 current and maybe that many past users?
|
marcvh
|
|
response 402 of 467:
|
Jan 14 22:56 UTC 2005 |
3 characters would be plenty, if minimizing size were the goal.
|
