Berkeley CSUA MOTD:Entry 26738
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/05/25 [General] UID:1000 Activity:popular
5/25    

2002/12/6-7 [Computer/SW/Mail] UID:26738 Activity:very high
12/6    A few years ago I saw an online rant about why firstname.lastname
        email addresses are bad.  I think it was by Eric Allman, but I can't
        find any refrences to it.  Any ideas?  -John
        \_ i think it's a great idea.  what's the problem with it?
           \_ There are going to be many people with the same first.last
              combo.  There are going to be many with similar first.last.
              Too many will stupidly assume that first.last @ one place will
              be the same first.last at other places.  Much better to destroy
              that false assumption using all sorts of different things at
              different places.  And oh yeah, older hosts can't deal with
              long user names so you get into making aliases for everyone so
              they now have 2 addresses.
              \_ far lamer is using the first 7 letters, plus the first
                 initial.  EVEN more duplicates.  There's just no easy
                 answer for a large corp.
              \_ not necesarily.  what if it's a pretty small organization
                 that has it's own domain name: first.last@smalldomain.org?
        \_ http://www.sendmail.org/faq/section3.html#3.5.
           He ignores rational arguments against his position. -tom
           \_ Gee, tom, imagine that...
           \_ he won't disagree that it might work for some places.
              he will argue that it is not a general panacea.
              \_ actually, he will refuse to fix sendmail bugs related to
                 real name matching because he thinks you shouldn't do that.
                   -tom
           \_ and what are rational arguments for such a system?
              \_ being able to send mail without first consulting directory
                 services, or without having to have directory services
                 available.  There is also aesthetic appeal to name-based
                 addressing.  It breaks down for large enterprises, but for
                 small groups it's usually fine.  -tom
                   \_ "aesthetic" is not a rational argument. and I think
                       "firstname.lastname" is much uglier that "handle".
                       Anyways it seems designed for people to send email
                       withoug knowing the email address of the recipient.
                       sounds like a system designed for short term laziness
                       at the expense of long term simplicity and sanity.
                       \_ I agree. Let's ditch that DNS thing too. People
                          should use IP addresses, like God intended them to
                          do. Ascii was a bad idea too, everyone should learn
                          to type in hex.
        \_ not the same thing, but here is something:
           http://beef.berkeley.edu/report/namespace.html
            \_ that idea would be great it "you" happened to own the
               you@berkeley.edu name space, but if somebody else gets the
               name you use: you@csua.berkeley.edu  that would suck.
                \_ You would own you@berkeley.edu if you own you@uclink or
                   you@socrates.  That sort of screws people in departments
                   that provide their own mail servers, but it was a
                   necessary compromise to get the report written.  -tom
                     \_ so it screws people in technically competent
                        departments for the benefit of others.
                    \_  if you want shorter email addresses, what about
                        giving uclink or socrates ailiases like
                        <DEAD>mail.berkeley.edu<DEAD> or <DEAD>po.berkeley.edu<DEAD>? something
                        that has one syllable instead of 3.
2025/05/25 [General] UID:1000 Activity:popular
5/25    

You may also be interested in these entries...
2011/2/6-19 [Computer/Networking] UID:54028 Activity:nil
2/5     hmm.
$netstat -at | grep LISTEN
tcp        0      0 *:43300                 *:*                     LISTEN
        \_ this is an sshd
tcp        0      0 *:49416                 *:*                     LISTEN
tcp        0      0 *:36201                 *:*                     LISTEN
	...
2010/4/7-8 [Computer/SW/Mail] UID:53776 Activity:nil
4/7     postfix equivalent of 'sendmail -bt' ?
	...
2009/9/10-15 [Computer/SW/Mail] UID:53353 Activity:nil
9/9     What should outbound mail server be when reading mail from soda
        with IMAP? Is there a FAQ?
        \_ It's <DEAD>mail.csua.berkeley.edu<DEAD> (same as for incoming mail).
           \_ "The message could not be sent because connecting to SMTP
               server <DEAD>mail.csua.berkeley.edu<DEAD> failed. The server may
               be unavailable or is refusing SMTP connections."
	...
2008/11/11-26 [Computer/SW/Mail] UID:51911 Activity:nil
11/11   My RAID box has an email alert setting that requires an SMTP
        server. Are there non-encrypted smtp servers I can use?
        \_ yes
	...
2008/11/18-23 [Computer/SW/Mail] UID:52031 Activity:nil
11/18   Say I've written a pcap-based program which pulls out the message
        body of unencrypted SMTP sessions and writes those into file1 file2
        file3 ... fileN. Is there a simple way to get a spam-score for
        each of those [based on message body, not SMTP headers, sender
        reputations etc]. I'd like to have a program warn me if some
        IP address inside my institution starts sending say >10 suspect
	...
2008/7/15-16 [Computer/Domains] UID:50572 Activity:nil
7/14    Help sendmail experts. I forward email from my own domain to
        http://gmail.com. I have never had any problem until recently. The problem
        happens only when eBay sends an email to my domain (as
        member@ebay.com). I receive the mail on my domain/my machine, and
        when it tries to forward to gmail, I get the following:
         Diagnostic-Code: X-Postfix; host <DEAD>gmail-smtp-in.l.google.com<DEAD>[w.x.y.z]
	...
2008/1/28-2/2 [Computer/SW/Mail] UID:49023 Activity:nil
1/28    When I run Thunderbird to use my soda mail, I can read mail but I can't
        send.  It gives an error "Sending of message failed.  The message
        could not be sent because connecting to SMTP server
        <DEAD>mead.CSUA.Berkeley.edu<DEAD> failed. ......"  Is there some special setup
        that I need to configure in order to send mail?  Thanks.
        \_ Just use your ISP's SMTP server to send mail. Soda probably
	...
2007/8/21-22 [Computer/SW/Mail] UID:47698 Activity:nil
8/21    Would someone please post the IMAP and SMTP setting for soda email
        please?  thanks
	...
2007/4/5-7 [Computer/SW/Mail, Computer/HW/Drives] UID:46203 Activity:nil
4/5     IMAP questions
        1. when I IMAP, I got this error:
        "the current comand did not succeed.
        The mail server responded: Out of disk space"
        what did I do wrong?
        2. is SMTP the same server as IMAP server?
	...
2007/1/30-2/3 [Computer/SW/Mail] UID:45624 Activity:nil 76%like:45619
1/30    I can't get mutt to read my maildir dir.  What am I doing wrong?
        set mbox_type=Maildir
        \_ mine works just fine with MAIL set to /var/mail/user
        Also does anyone know the correct settings to get Mail.app to play
        nice with IMAP and soda mail?
        \_  Advanced: IMAP Path Prefix: "mail"; Port: "993"; "check" Use SSL;
	...
2007/1/30 [Computer/SW/Mail] UID:45619 Activity:nil 76%like:45624
1/30    I can't get mutt to read my maildir dir.  What am I doing wrong?
        \_ mine works just fine with MAIL set to /var/mail/user
        Also does anyone know the correct settings to get Mail.app to play
        nice with IMAP and soda mail?
        \_  Advanced: IMAP Path Prefix: "mail"; Port: "993"; "check" Use SSL;
                      Authentication: Password.  Haven't tried using CSUA's
	...
Cache (8192 bytes)
www.sendmail.org/faq/section3.html#3.5
This question is answered in detail at the configuration 44 Masquerading and Relaying page. Date: September 23, 1997 Updated: November 8, 1999 Use the generics table, as described in steps 6 and 7 of the 45 Virtual Hosting page. The proper solution is to use the generics table, as described in steps 6 and 7 of the 46 Virtual Hosting page. The important thing to note is that the host/domain part of the fully-qualified address must be specified via GENERICS_DOMAIN() or GENERICS_DOMAIN_FILE(). Date: May 12, 1997 The intent was to have all information for a given user (where the user is the unique login name, not an inherently non-unique full name) in one place. This would include phone numbers, addresses, and so forth. UC Berkeley is (was) in the process of setting up their environment so that mail sent to an unqualified "name" goes to that person's preferred maildrop; The purpose of "FEATURE(notsticky)" is to cause "name@host" to be looked up in the user database for delivery to the maildrop. Date: May 12, 1997 Updated: April 7, 2004 Because full names are not unique. For example, the computer community has two Peter Deutsches. And you can bet that one of them will get most of the other person's email. Moreover, at institutions with high turnover (such as universities), a given name may refer to different people at different times, which can again lead to mail going to the wrong person. So called "full names" are just an attempt to create longer versions of unique names. Rather that lulling people into a sense of security, I'd rather that it be clear that these handles are arbitrary. People should use good user agents that have alias mappings so that they can attach arbitrary names for their personal use to those with whom they correspond (such as the MH alias file). Since non-ASCII characters cannot be used in the SMTP envelope or e-mail headers, the full names are mangled anyway. Even worse is fuzzy matching in email -- this can make good addresses turn bad. But if another Allman ever appears, this address could suddenly become ambiguous. He's been the only Allman at Berkeley for over fifteen years -- to suddenly have this "good address" bounce mail because it is ambiguous would be a heinous wrong. Directory services should be as fuzzy as possible (within reason, of course). This question is answered in detail at the 47 Virtual Hosting page. This question is answered in detail at the configuration 48 Using UUCP Mailers page. This question is answered in detail within the 49 Compiling Sendmail page. Date: April 8, 1997 Updated: May 9, 2000 Updated: June 8, 2002 Updated: March 2, 2003 If you are just getting occasional such messages, they're probably due to a temporary network problem, or the remote host crashing or otherwise abruptly terminating the connection. If you get a lot of them in general, you may have network problems that are causing connections to get reset. Note that this problem is sometimes caused by incompatible values of the MTU (Maximum Transmission Unit) size on a SLIP or PPP connection. Be sure that your MTU size is configured to be the same value as what your ISP has configured for your connection. If you are still having problems, then have your ISP configure your MTU size for 1500 (the maximum value), and you configure your MTU size similarly. Path MTU discovery relies on certain ICMP messages being allowed through back to the host originating the traffic - see 52 our tip on Path MTU Discovery and RFC 1191 for the details. After applying a few patches, the problem appears to have been resolved. Date: July 9, 1996 Updated: November 19, 1999 I just upgraded to version 8 sendmail and now when my users try to forward their mail to a program they get an "illegal shell" or "cannot mail to programs" message and their mail is not delivered. If /etc/shells does not exist, a default list is used, typically consisting of /bin/sh and /bin/csh. This is to support environments that may have NFS-shared directories mounted on machines on which users do not have login permission. For example, many people make their file server inaccessible for performance or security reasons; If you allowed them to run programs anyway you might as well let them log in. This must be typed exactly as indicated, in caps, with the trailing slash. NOTA BENE: DO NOT list /usr/local/etc/nologin in /etc/shells -- this will open up other security problems. You can copy the information in the "shells=" stanza into a /etc/shells on your system so sendmail will have something to use. Do NOT add "/usr/lib/uucp/uucico" or any other non-login shell into /etc/shells. Date: November 24, 1996 Updated: August 29, 2001 I just upgraded to version 8 sendmail and suddenly connections to the SMTP port take a long time. It's probably something weird in your TCP implementation that makes the IDENT code act oddly. On most systems version 8 sendmail tries to do a callback'' to the connecting host to get a validated user name (see RFC 1413 for detail). If the connecting host does not support such a service it will normally fail quickly with "Connection refused", but certain kinds of packet filters and certain TCP implementations just time out. Alternatively, if you don't use m4, you can put OrIdent=0'' in the configuration file (we recommend the m4 solution, since that makes maintenance much easier for people who don't understand sendmail re-write rules, or after you've been away from it for a while). Either way, this will completely disable all use of the IDENT protocol. You may also wish to check out our tips on how to 56 set up DNS for your private address space. If they differ, you might try changing the V8 flags to match the Sun flags. This should be available from your hardware vendor through your support contract or their online support facilities (including being available on the SunSolve CD). V8 propagates the owner information into the SMTP envelope sender field (which appears as the Unix From line sometimes incorrectly referred to as the From-space "header" on Unix mail or as the Return-Path: header) so that downstream errors are properly returned to the mailing list owner instead of to the sender. Date: November 24, 1996 Believe it or not, this is intentional. The interpretation of the standards by the version 8 sendmail development group was that this was an inappropriate rewriting, and that if the rewriting were incorrect at least the envelope would contain a valid return address. This is discussed in greater detail at the configuration 59 Masquerading and Relaying page. Date: March 23, 1996 When I look in the queue directory I see that qf* files have been renamed to Qf*, and sendmail doesn't see these. If you look closely you should find that the Qf files are owned by users other than root. Since sendmail runs as root it refuses to believe information in non-root-owned qf files, and it renames them to Qf to get them out of the way and make it easy for you to find. The usual cause of this is twofold: first, you have the queue directory world writable (which is probably a mistake -- this opens up other security problems) and someone is calling sendmail with an "unsafe" flag, usually a -o flag that sets an option that could compromise security. When sendmail sees this it gives up setuid root permissions. If you must use them, you have to write a special queue directory and have them processed by the same uid that submitted the job in the first place. Date: March 23, 1996 Updated: September 5, 1999 This is considered to be a MUA issue rather than an MTA issue. Quoth Eric Allman: The primary reason is that the information necessary to do the encoding (that is, 8->7 bit) is unknown to the MTA. In specific, the character set used to encode names in headers is _NOT_ necessarily the same as used to encode the body (which is already encoded in MIME in the charset parameter of the Content-Type: header). Furthermore, it is perfectly reasonable for, say, a Swede to be living and working in Korea, or a Russian living and working in Germany, and want their name to be encoded in their native character set; If all I have are 8-bit characters, I can't choose the charset properl...
Cache (3483 bytes)
beef.berkeley.edu/report/namespace.html
Expenses and Workload The most contentious deliberations BEEF had were over how to choose the name space; Our recommendations, and some background discussion follow. EDU address should be the only one allowed to select that name on uclink or socrates. In particular: + Name length: Names of two characters or longer should be accepted. The maximum length should be as large as is allowed by the Namespace, and should be, at minimum, 30 characters. If so, the restriction should be narrowly targeted--perhaps, no 9 or 10-digit all-numeric names allowed (rather than a blanket restriction on all-numeric names). EDU bounces with a generic message, that name should be made available to the current community). EDU names into the Online Alumni Community when students graduate, possibly by adding the year graduated or some other qualifier. Some of the other suggestions considered include: * Assignment of names. There are many different schemes one could use to implement auto-assignment; The common feature of these implementations is that the friendlier the naming scheme is, the worse the conflicts become. If there are two people named "Jennifer Lee", what happens to their e-mail address? Does the first one to claim it get stuck with mail for all of the Jennifer Lees? It's also worth noting that, given Berkeley's population, name conflicts are disproportionately Asian. The tcholub scheme probably has fewer conflicts, but raises most of the same issues when conflicts do arise. Also, many people prefer not to use their middle name, so this option is decidedly unfriendly for them. Conflicts are built into the system, so they are distributed equally--there is no "lower class" of users. Unfortunately, as with so many social engineering programs, the lower class is removed by making everyone's name equally distasteful. The unfriendliness would undermine the usefulness of the system; The lack of a satisfying scheme for auto-assignment already had the group leaning away from the idea, when we found out that the CalNet Steering Committee had recently grappled with the same problem, in the realm of self-selected CalNet (Kerberos) login names. Another plan we eventually discarded was to auto-generate addresses for everyone using one of the above schemes, and then give them the option to self-select a friendlier name. This would allow us to use one of the unfriendly but equitable solutions above (like th278), while allowing users to have an attractive name. The main sticking point was the opinion of several committee members that the service should be opt-in only. There was a great deal of public outcry about the availability of everyone's information in the EZ-Sure-Pay system; Instead of coordinating with the Namespace, we could create a totally fresh namespace. This would get around the problem of pollution in the Namespace, and would in some ways be more equitable. There was also concern that people would question why IST was maintaining two separate namespaces. After much discussion, it was decided that to move forward, we had to discard this option. One problem with uclink's current namespace is that names are limited to 8 characters in length due to technical restrictions. That turnover is probably too rapid for an email forwarding namespace. One way to handle this would be to "deprecate" addresses once the user leaves the LDAP database. As long as the name will be reserved, we should continue providing at least this level of service to it.
Cache (73 bytes)
berkeley.edu
For a text-only version of the campus home page, please follow this link.
Cache (1958 bytes)
csua.berkeley.edu
Science Undergraduate Association The Computer Science Undergraduate Association is dedicated to representing the undergraduate Computer Science student body and associates to the University of California at Berkeley, its representatives, and other related organizations; Our office is located in 343 Soda Hall, located at the corner of Hearst & LeRoy. May___| |May, 2004 | |_S___M___T___W___T___F___S_| | |1 | ||___| |2 |3 |4 |5 |6 |7 |8 | |___|___|___|___|___|___|___| |9 |10 |11 |12 |13 |14 |15 | |___|___|___|___|___|___|___| |16 |17 |18 |19 |20 |21 |22 | |___|___|___|___|___|___|___| |23 |24 |25 |26 |27 |28 |29 | |___|___|___|___|___|___|___| |30 |31 | | |___|___|| Calendar of Events Mon, May 3rd, (6:00 PM) General Meeting/Officer Elections Announcements: * CSUA t-shirts are now available in the office (343 Soda) for $12 each. Baby-doll cuts also available. View the design on front and back. The CSUA Mentoring Program is calling for new students to sign up to be mentored. Register to find out more information about this free program at the mentoring website. Members interested in mentoring should contact jhs as soon as possible. CSUA Officer Meetings: Politburo meetings for Spring 2004 are scheduled for every Monday at 6pm in 337 Soda Hall. New members always welcome. Help Sessions are being offered, open especially to new students. The topics, times, and locations are listed here. We just made a Costco run. If you don't know what this means, stop by 343 Soda to find out. The Constitution has been amended. Many thanks to AMD and the TDA Project. Secure remote logins require either SSH ( Java Client) or S/KEY ( Java Client). User Policy - The Rules * Frequently Asked Questions about the CSUA and Soda * CSUA Constitution * Message of the Day - Including downtime announcements * CSUA Library * CSUA Encyclopedia * Membership application form, in PDF, TeX, DVI, and Postscript. The Mentoring Program * Prospective LSCS Mailing List.