text:
User:Spammy

Just a filler user page for the time being. I am a student at Florida State University currently working on my undergraduate degree in biomedical engineering. I recently switched majors from physics to my current field, which unfortunately added an extra two years onto my degree. Hopefully I will finish my PhD work by 2010 :/ More information to come.

title: User:Spammy


text:
Talk:Barbara Grunes

External links modified
Hello fellow Wikipedians,

I have just modified 3 one external links on Barbara Grunes. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20120502175534/http://www.topchinesefoods.com/cuisine-de-chine-chinese-cooking-made-fast-and-easy-with-the-food-processor/ to http://www.topchinesefoods.com/cuisine-de-chine-chinese-cooking-made-fast-and-easy-with-the-food-processor/
 * Added archive https://web.archive.org/web/20110908055439/http://authors.simonandschuster.com:80/Barbara-Grunes/17911592 to http://authors.simonandschuster.com/Barbara-Grunes/17911592
 * Added archive https://web.archive.org/web/20120502175534/http://www.topchinesefoods.com/cuisine-de-chine-chinese-cooking-made-fast-and-easy-with-the-food-processor/ to http://www.topchinesefoods.com/cuisine-de-chine-chinese-cooking-made-fast-and-easy-with-the-food-processor/

Cheers.— InternetArchiveBot  (Report bug) 04:10, 27 October 2016 (UTC)

source: wikimedia

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Talk:Barbara Grunes


text:
Wikipedia:Articles for deletion/List of criticism and critique articles

The result was   keep. The Bushranger One ping only 02:05, 27 July 2012 (UTC)

List of criticism and critique articles

 * – ( View AfD View log  •  Stats )

Article is a list of Wikipedia articles by purpose. It doesn't seem particularly encyclopaedic, and I feel that it violates WP:NOTDIR and WP:SELFREF  W.  D.   Graham  14:59, 11 July 2012 (UTC)

 * Comment - We probably need to have an RFC someday about whether Index pages like this are "in" or "out." Opinion varies and we need to form a consensus... Carrite (talk) 15:08, 11 July 2012 (UTC)
 * Comment - I've got a few other articles like this including List of controversy articles and List of comparison articles. I happen to think they're exceptionally useful and are a great way to track what types of articles have a certain spinoff and how they use them. I'd also like to point out that List of lists of lists also fits into this category as it only lists wiki lists of lists, not all. That article should be renamed, like I suggested on the talkpage... Oh btw an obvious keep as creator for me on this article. :)--Coin945 (talk) 15:14, 11 July 2012 (UTC)

 * Comment - Why don't we close this debate and the two of you get together to frame up an RFC on the question? Most of these index pages, when they are brought here, seem to be kept — but there's really no doctrinal grounds for that, it's more a matter of IAR or IT'S USEFUL. If we do allow such navigational index pages, where are the lines to be drawn? Carrite (talk) 17:41, 11 July 2012 (UTC)
 * I have no objection to that if other parties would be happy with it. -- W.  D.   Graham  00:23, 12 July 2012 (UTC)
 * I'm unfamiliar with how RfCs work, but sure, I'm fine with that to... might need a tiny bit of coaching on what to do exactly though :).--Coin945 (talk) 01:07, 12 July 2012 (UTC)
 * "Most of these index pages, when they are brought here, seem to be kept — but there's really no doctrinal grounds for that..." That such indexes are usually kept is a doctrinal ground, as it represents WP:CONSENSUS on the issue. Requiring a preexisting, codified rule to support the community's express and repeated consensus is getting things backwards, as WP:NOTBUREAUCRACY explains. Also, it should be obvious that whether an index of Wikipedia content is useful should be one of the key factors in deciding whether or not to keep it, as the whole point of an index is its utility in organizing and locating content, just as it always has been with any traditional print encyclopedia or other reference work. But even if you still want codified doctrine, WP:LISTPURP and WP:CLN do codify the validity of WP indexes as navigational tools for readers and editors. postdlf (talk) 22:01, 13 July 2012 (UTC)

 * Delete This seems to fail WP:LISTN "A list topic is considered notable if it has been discussed as a group or set by independent reliable sources" and I'm not seeing or finding such sources. Warden (talk) 18:11, 11 July 2012 (UTC)
 * This is more of a directory-type list, so it's only natural there will be no "independent reliable sources". The only sources involved are: and . :) --Coin945 (talk) 18:25, 11 July 2012 (UTC)

 * Keep – This is a useful navigation page for Wikipedia pages whose titles are based upon criticism and critiques. How does deletion of this list improve the encyclopedia? Also, per WP:NOTDUP, this list is complementary to Category:Criticisms, rather than inappropriate. Also, this article doesn't particularly appear to fail WP:NOTDIR (It's a focused list, not indiscriminate) nor WP:SELFREF (article lists and indexes for Wikipedia are common, not included in WP:SELFREF). Northamerica1000(talk) 01:44, 12 July 2012 (UTC)

 * Keep Wikipedia policy doesn't really cover lists of this sort, which are not encyclopedic in the sense that you wouldn't expect to find them in Britannica, but are useful for navigation (some such pages are in the Special namespace but not all are). I can't see a reason to delete it, or even a reason for nominating it. The arguments for deletion simply cite policies, but that is not the way to conduct an AfD debate: the actual policies exist for definite reasons, and the policy articles explain what these reasons are. So explain what is bad about this article. Does it do harm to Wikipedia? --Colapeninsula (talk) 13:51, 12 July 2012 (UTC)
 * Note: This debate has been included in the list of Lists-related deletion discussions.  • Gene93k (talk) 14:17, 12 July 2012 (UTC)

 * Keep. This article is useful for navigation, and if annotated would provide more information than a comparable category would provide.
 * —Wavelength (talk) 15:23, 13 July 2012 (UTC)

 * Relisted to generate a more thorough discussion so a clearer consensus may be reached.

 * Please add new comments below this notice. Thanks, -Scottywong | express _ 16:00, 19 July 2012 (UTC)

 * Delete - Why can't this just be moved to, say,WP:Criticism Articles? What possible justification is there to keep this in article-space? Tarc (talk) 16:08, 19 July 2012 (UTC)
 * Keep, largely per NorthAmerica1000. The nom's WP:SELFREF complaint is off the mark, as that style guide is entirely about article content referring to their own nature as articles ("This article is about George Washington"), and doesn't deal with indexes or any kind of list at all; list indexes are naturally about what Wikipedia articles exist and so are not improper self-references. Warden's WP:LISTN !vote is also irrelevant as Coin945 explained, as LISTN has nothing to do with this kind of index; see instead WP:LISTPURP and WP:CLN for navigational/organizational lists. That takes care of all the actual deletion arguments. postdlf (talk) 15:43, 24 July 2012 (UTC)
 * Keep per standing consensus that such navigational articles be kept. I disagree with Postdif that ad hoc ITSUSEFUL/IAR arguments like this are either satisfactory or permanent, but that's where we're at in lieu of any formal test of community consensus on the matter. Carrite (talk) 17:58, 25 July 2012 (UTC)


text:
Wikipedia:WikiProject Spam/LinkReports/caiyuu.com

Links

 * caiyuu.com resolves to [//<IP_ADDRESS> <IP_ADDRESS>]
 * Link is not on the blacklist.
 * Link is not on the domainredlist.
 * Link is not on the Monitorlist.
 * None of the mentioned users is on the blacklist.
 * Link is not on the whitelist.
 * Link is not on the monitor list.
 * Link is not on the whitelist.
 * Link is not on the monitor list.

Users
No users found.

Additions
No additions recorded.


text:
Volvo Elisabeth I

The Volvo Elisabeth I was a concept car designed by Giovanni Michelotti and built by Vignale sometime in 1953, on the chassis of a Volvo P445.

The lines are recognizable in the later Amazon, but the Elisabeth has a small triangular grille, similar to one on an Alfa Romeo. The man behind the project was the businessman Gösta Wennberg, who made official contact with Michelotti in Paris in 1952. Michelotti was supposed to design the bodywork of a car to be built by Ghia Aigle, but the drawings came from Vignale instead. The work itself took place mainly at Carrozzeria Allemano located in Turin not too far from Vignale.

Because of the construction of the chassis, there was no space for any back seats. This was probably one of the main reasons for Volvo's lack of interest in serial production of Elisabeth I, which had been Wennberg's original intention with the project. The one-off car was crashed sometime in the beginning of the 1960s.

title: Volvo Elisabeth I


text:
Anthony Thomopoulos

Anthony Denis "Tony" Thomopoulos (Αντώνης Θωμόπουλος ) is an American motion picture and television executive. Thomopoulos spent 12 years of his career at ABC, moving progressively from Vice President of Prime Time Programs, to President of ABC Entertainment, to President of ABC Broadcast Group.

Biography
The son of Greek immigrants, he grew up in the Bronx. His father owned a restaurant. Tony was raised in the Greek Orthodox Church. After a high school aptitude test marked Thomopoulos as a potential diplomat, he applied to Georgetown University's Edmund A. Walsh School of Foreign Service. There, he developed an interest in business instead. After graduating, he worked as a mail clerk at NBC's New York headquarters.

Business career
In 1973, Barry Diller hired Thomopoulos at ABC to oversee prime-time programming. He was noted, among other things, for the tough position he took in dealing with the contract holdout of Suzanne Somers on the hit ABC show Three's Company, and for his quick cancellation of the 1982 cult favorite Police Squad!, explaining that the show had been cancelled because, among other reasons, "it required constant attention". In June 1983, he was named president of the broadcast group. He resigned as president in 1985 and became chairman of United Artists Pictures, where he supervised such productions as Betrayed, Baby Boom, and The Living Daylights. In 1989, Thomopoulos formed Thomopoulos Productions, an independent production company of both motion pictures and television programs.

From 1991 to 1995, he was President of Amblin Television, a division of Amblin Entertainment. He was responsible for the original placement of NBC's highly acclaimed program ER, in addition to several other successful series on network television. In 1995, Thomopoulos joined International Family Entertainment, Inc. (IFE). His responsibilities included all aspects of programming for The Family Channel. He was named CEO of MTM Entertainment, Inc., a subsidiary of IFE, and was also responsible for all aspects of MTM Television and MTM Distribution.

Thomopoulos was chairman and CEO of artist Thomas Kinkade's Media Arts Group from June 2001 to January 2004. He subsequently founded Morning Light Productions.

Personal life
Thomopoulos's first marriage ended in 1983 after 22 years, and produced three children. In 1985, he married television host Cristina Ferrare. They have two children. As of 2011, they lived in California.

title: Anthony Thomopoulos


text:
Stuart Young (accountant)

Stuart Young (23 April 1934 – 29 August 1986) was an English business executive and accountant.

The younger brother of Lord Young of Graffham, Stuart Young succeeded George Howard as the chairman of the BBC board of governors in 1983, and remained in this role until his early death from cancer in 1986.

When he first became a BBC governor in 1981 he argued that the BBC should be funded by advertising. However, he later changed his mind and argued for the continuation of the television licence during the Peacock Committee. This disappointed Prime Minister Margaret Thatcher, who disliked the television licence and had originally appointed Young believing that, as a Conservative, he would challenge the more left-leaning Director-General of the BBC, Alasdair Milne. She believed that Young had “gone native” and was now supporting the BBC instead of the government.

At the time of his death in 1986, aged 52, Young had with his wife Shirley, two daughters – Lesley and Lynda.

title: Stuart Young (accountant)


text:
User:Namaliki207

Abdulmalik Shuaib (Namaliki) is a Nigerian professional typist, who work for Upperlink Computer Services, Jos North, Plateau State.

title: User:Namaliki207


text:
User:Oac00001

I study film and media studies and history as an extra module at Stirling University. I enjoy watching movies, playing games and have recently fallen madly in love with sleeping. I feel sorry for Greg having to sit in here till 6!

title: User:Oac00001


text:
Cookbook talk:Requested Recipes

Incorporating the Open Source Cookbook
I'm going to be adding recipes and such from the Open Source Cookbook. It should add quite a bit to the Wikibook.--Alsocal 07:28, 5 Oct 2004 (UTC)

Glazed Sweet Potatoes
I have finished that recipe. So I removed it from the list. Mr. C.C. 03:42, 13 July 2006 (UTC)

Lobster Thermidor
I added this recipe to the Northeastern American cookbook -- it has been subsequently been removed from the list of requested recipes. Sarah Murray 16:25 3 August 2006 (PST)

Jewish cuisine?
Why isn't there a category? It's an ethnic cuisine like any other. --<IP_ADDRESS> 15:25, 2 July 2007 (UTC)

 * There is Cookbook:Cuisine of Israel, as well as Category:Israeli recipes, Category:Jewish recipes, Category:Yiddish recipes. If you think we need a page describing how Jewish cuisine differs from Israeli cuisine (e.g. through European and American influences) then be bold and create it. Webaware talk 02:33, 3 July 2007 (UTC)

Requesting recipes
If one wishes to request a recipe, does one simply edit the list here? Jade Knight 10:39, 3 July 2007 (UTC)

 * Yes. Webaware talk 08:40, 4 July 2007 (UTC)

Shouldn't be classified as a recipe
This page is classified as a recipe, which it should not be. —Kri (discuss • contribs) 13:09, 16 June 2012 (UTC)

Pocky sticks? Really?
They're just biscuit sticks dipped and dried in chocolate or other sauces. There are any number of recipes for biscuit sticks and anyway, why is a trademarked snack listed as a recipe request? Might as well include a recipe request for Snickers. <IP_ADDRESS> (discuss)

title: Cookbook talk:Requested Recipes


text:
Talk:Dez Cadena

Heritage
Does anybody know anything of his ancestral origins or ethnicity? He has an interesting last name.--<IP_ADDRESS> (talk) 04:37, 9 November 2011 (UTC)

Spanish (Mexican) last name. — Preceding unsigned comment added by <IP_ADDRESS> (talk) 21:54, 23 February 2013 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Dez Cadena. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20090412044034/http://www.independentmusicawards.com/ima_new/imajudges2009.asp to http://www.independentmusicawards.com/ima_new/imajudges2009.asp

Cheers.— InternetArchiveBot  (Report bug) 04:12, 12 December 2016 (UTC)

title: Talk:Dez Cadena


text:
AIR Awards of 2020

The 2020 AIR Awards was the fourteenth annual Australian Independent Record Labels Association Music Awards ceremony (generally known as the AIR Awards). It took place on 1 October 2020 in Adelaide.

The nominations were revealed on 7 July 2020, consisting of sixteen categories, up four from twelve, as was the case in 2019. The four new categories were: Best Independent Pop Album or EP, Best Independent Rock Album or EP, Best Independent Children's Album or EP, and Best Independent Soul/R&B Album or EP. The award for Best Independent Hard Rock, Heavy or Punk Album was split in two, recognising Punk and Heavy separately. For the first time, the ceremony didn't include the Best Independent Artist category.

Performers

 * Stella Donnelly
 * The Teskey Brothers
 * Angie McMahon
 * The Soul Movers

AIR Awards
Winners are listed first and highlighted in boldface; other final nominees are listed alphabetically.

title: AIR Awards of 2020


text:
Talk:Glide reflection

Perhaps you [the author] are smarter than the rest of us, but...
This is perhaps the most obtuse article have seen in Wikipedia.

I came here because I was intrigued by:

 * The symmetry observed is not exactly bilaterian, but appears to be a glide reflection, where opposite segments are shifted by half an interval.

In the article on Spriggina, an Ediacaran organism. It sounded like an interesting concept, but I left confused and hurt. Tapatio (talk) 07:44, 12 July 2012 (UTC)

deez nuts — Preceding unsigned comment added by <IP_ADDRESS> (talk) 13:43, 19 June 2015 (UTC)

 * Welcome to Wikipedia, the online encyclopedia wherein very smart people compete with others like then to demonstrate their deep familiarity with many bafflingly complex fields of endeavor, to the exclusion of the so-called "average reader." --Quisqualis (talk) 20:16, 9 December 2016 (UTC)

I came here from sea pens -- a type of sea anemone relative that is the only living organism to demonstrate such an orientation to its segments, and this article is written in such sophisticated text that it's difficult to get a good quick grasp of the definition. And I hesitate to edit it because I'm afraid I don't understand the content well enough.  DRosenbach  ( Talk 14:48, 19 December 2016 (UTC)

Proposed merge of Glide plane into Glide reflection
same concept. fgnievinski (talk) 04:47, 17 August 2023 (UTC) fgnievinski (talk) 04:47, 17 August 2023 (UTC)

 * Support. The difference between articles is the dimensionality: Glide reflection considers symmetry operations in 2D and Glide plane in 3D. I don't find this an essential difference. Both cases can easily be discussed in the same article. Jähmefyysikko (talk) 07:32, 27 September 2023 (UTC)
 * I would oppose for now. This page (Glide reflection) has a 'too technical' tag at present and (I concur) is difficult to follow. If it is the same concept as Glide plane then I can’t tell, and dumping the Glide plane content into this article won’t make it any easier to read. A better option would be to improve this page (Glide reflection) so that it is readable; then if it is clear they are the same thing re-propose the merge with a proper rationale. Moonraker12 (talk) 19:37, 28 September 2023 (UTC)
 * PS: I also note the text states Glide reflection is a 2D function while Glide plane is 3D; and that Glide reflection is in three maths categories while Glide plane is in Crystallography and Symmetry. So I’m not convinced they are the same thing at all. Moonraker12 (talk) 19:39, 28 September 2023 (UTC)
 * Support. The article glide plane is confusing. From what I can tell skimming around the academic literature, "glide reflection" is the operation, and the "glide plane" is the associated (hyper)-plane. For example, from International Tables for Crystallography (2006). Vol. A, Ch. 1.3: "To each glide plane, infinitely many different glide reflections belong, because to each glide vector listed in column 3 any lattice translation vector parallel to the glide plane may be added; this includes centring vectors of centred cells. Each resulting vector is a glide vector of a new glide reflection but with the same plane as the geometric element. Any of these glide operations can be used as a 'defining operation'." –jacobolus (t) 06:41, 29 November 2023 (UTC)

I went ahead and did a merge, but both the content previously here and the new material added from glide plane need a substantial rewrite for better narrative flow, accessibility to less technical readers, and clarity. –jacobolus (t) 22:01, 29 November 2023 (UTC)

 * @Moonraker12 Noting that you were opposed to this merge before, does the merger seem okay now, or do you still have concerns? I cleaned up at least the lead section, though the rest is still a bit rough and incomplete. –jacobolus (t) 17:48, 10 December 2023 (UTC)

 * Thanks for the notification (sorry for the lateness in replying); I think your additions to the Introduction here make the connection between glide plane and glide reflection much clearer, so your merge makes sense. Regards, Moonraker12 (talk) 21:43, 27 December 2023 (UTC)

title: Talk:Glide reflection


text:
Eli (2015 film)

Eli is a 2015 Indian Tamil-language spy comedy written and directed by Yuvaraj Dhayalan. The film stars Vadivelu and Sadha. Vidyasagar composed the film's music. Eli, set in the 1960s, focuses on a small-time thief who is recruited by the police to infiltrate a gang in an effort to thwart an illegal cigarette smuggling scheme. The film was released on 19 June 2015 to mostly negative reviews and became a box-office bomb.

Plot
In 1960s, Chennai (Madras then), a police officer and a social worker give speech about ban of cigarettes in All India Radio. Then three men gets out from a car. They were thieves and led by Elisamy alias Eli, a petty thief (who once aspired to become a police officer), who pretends to be a captured-thief who has sold all his robbery items to a jewellery shop owner. The jewellery shop owner had no contact with him and his henchmen dressed as police take all the items pointed out and pretend to arrest Eli and loot the shop. He uses his tricks and loots many other places. One day he enters the house of retired police officer Mr. Rangarajan who had rejected him at the police selection. He loots everything except his photograph, in revenge. When the current police Inspector General Mohanraj arrives to meet Rangarajan, Eli pretends as though Rangarajan had vacated his house and he is performing rituals and not to disturb him. When the police officer meets Rangarajan on the way he is shocked to find that he had been tricked and Eli had looted the house.

Later when the police officer tells Rangarajan to send a police spy to catch the illegal cigarette cartel leader Nagarajan, Rangarajan recommends Eli to capture him. Eli pretends to be one of Nagarajan's henchmen and with the help of Julie captures Nagarajan red handed and hands him over to the police and also the policeman who had been helping Nagarajan.

Cast

 * Vadivelu as Elisamy alias "Eli" / Jolly
 * Sadha as Julie
 * Pradeep Rawat as Nagarajan
 * Adithya Menon as IG Mohanraj
 * Santhana Bharathi as Jail Warden Ezhumalai
 * Raj Kapoor as Police Inspector
 * Rajendran as Kuruvi Manda Kumar
 * Kitty as Retired IG Rangarajan
 * Bose Venkat as Inspector Karunakaran
 * Besant Ravi as Pathanambakkam Ravi
 * Shanmugarajan
 * Mahanadi Shankar as Padagu Babu
 * Bava Lakshmanan as Eli's partner
 * Vengal Rao as Eli's partner
 * Nellai Siva
 * King Kong as convict
 * Muthukaalai as terrorist
 * Boys Rajan as Padmanabhan
 * Krishnamoorthy as Bank clerk
 * Sakthivel as Jail warden
 * Poochi Murugan as Minister Poochi Muthu
 * Amirtha Lingam
 * Pei Krishnan
 * Kottai Perumal as smuggler
 * Jayakumar as Police officer
 * Aarivaya Shaik as Dumb convict
 * Karnaa Radha

Production
Eli is the second film of Vadivelu with Yuvaraj Dhayalan after Tenaliraman (2014). In March 2015, Sadha was confirmed to play the female lead in the film. Pradeep Rawat plays the film's antagonist. In an interview with Sudhir Srinivasan of The Hindu, Dhayalan said that the inspiration for the film's title came from the repeated usage of the word "rat", which is a term used to denote a spy, in the Martin Scorsese film The Departed (2006).

Principal photography commenced with the filming of a song sequence on the outskirts of the city, from the same day as the first look poster was released. The shooting is reported to continue for 60 days at a stretch. A stunt sequence was shot at a specially erected set in early April 2015 over a period of eight days. According to Dhayalan, this sequence features Vadivelu evading the villain's henchmen instead of fighting them.

Soundtrack
Vidyasagar composed the film's soundtrack and score while Pulamaipithan and Viveka wrote the lyrics. The music rights were purchased by Saregama. The launch of the soundtrack was held on 11 May 2015. During the audio launch, Vadivelu revealed that the Hindi song "Mere Sapno Ki Rani" from Aradhana (1969) would be reused in the film and that the sequence would feature himself and Sadha.

Release
On 5 February 2015, Eli's first look poster was revealed. The poster featured Vadivelu sporting a red coat and yellow scarf over a black shirt and checked black trousers. The first trailer was released on 14 May 2015, while a second trailer was released on 4 June 2015. The film was released on 19 June the same month.

Critical reception
Eli received negative reviews from critics. Baradwaj Rangan of The Hindu wrote, "There have been films...that have mined comedy from crime, but just about nothing works here. Eli is full of scenes that go on forever — and for no reason....Even Vadivelu is stranded — the gags he's in are shockingly weak." The Times of India's M. Suganth gave the film 1.5 stars out of 5, describing it as "overlong, dull and largely unfunny" and adding, "Yuvaraj Dhayalan, seems to be after a spoof of spy movies but the filmmaking has no comic rhythm and the script, which rehashes elements from movies as varied as Ragasiya Police 115 and The Departed, is too slack that scenes just go on for ever". The New Indian Express wrote, "An insipid screenplay and flat narration ensures that it would be the most tedious and boring 154 minutes one could have spent in a theatre...the film is a test of patience". Behindwoods concluded, "Vadivelu tries hard but Eli doesn't evoke enough laughter." Sify called Eli an "unmitigated disaster" and "probably the worst movie he (Vadivelu) has ever done as a hero". Raisa Nasreen of Bookmyshow commented positively on Vadivelu's performance but criticised the film's screenplay by stating that the scenes in the film were "too long and too predictable".

Box office
Eli grossed ₹ 9,34,054 in Chennai during its opening weekend. It was a box-office bomb.

title: Eli (2015 film)


text:
Bisbee Woman's Club Clubhouse

The Bisbee Woman's Club Clubhouse in Bisbee, Arizona was built in 1902. It was listed on the National Register of Historic Places in 1985.

It was designed by architect Frederick C. Hurst and is a one-story frame bungalow/craftsman style house.

title: Bisbee Woman's Club Clubhouse


text:
LPI Linux Certification/LPIC2 Exam 202/Mail & News

Section Overview

 * Configuring mailing lists
 * Using sendmail
 * Using Postfix
 * Managing mail traffic
 * Serving news
 * Configuring mailing lists

Configuring mailing lists
Majordomo is a mailing list management program. Its goal is to handle all incoming mails to a particular email address, and re-distribute them to a list of email addresses. Majordomo also handles adding and deleting an email address from its lists.

Since Majordomo is responsible for managing E-mail lists, Majordomo relies heavily on a MTA such as Sendmail, Smail, Qmail or Postfix.

aliases file (usually /etc/aliases) is used for making aliases for E-mail addresses. For example, once Majordomo is installed, usually an entry in the aliases file reads:

majordomo-owner: jarchie

This entry means that all mail addressed to<EMAIL_ADDRESS>will actually be sent to<EMAIL_ADDRESS>Notice it is unnecessary to append the @host.com to jarchie because both users are on the same host. If it were desired to redirect the message to a different user on a different host, one would have to add the @host.com portion.

Another type of entry in the aliases file allows E-mail to be redirected to multiple addresses listed in a file:

testlist: :include:/usr/local/majordomo-1.94.5/lists/testlist

This entry states that any message sent to<EMAIL_ADDRESS>will be redirected to all the addresses listed in the file /usr/local/majordomo-1.94.5/lists/testlist. The testlist file might look something like this:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Majordomo is able to add or remove addresses from a list by taking advantage of this feature. When a subscribe request is processed, the user's E-mail address is appended to the testlist file; when an unsubscribe request is processed, the user's E-mail address is removed from the testlist file. One can also add or remove addresses manually simply by editing the file with a text editor such as vi.

Since Majordomo needs to be able to process commands sent to it via E-mail, Sendmail must be able to execute the Majordomo program and pass the message to it. This is done by adding another type of entry to the aliases file:

majordomo: "|/usr/local/majordomo-1.94.5/wrapper majordomo"

The program /usr/local/majordomo-1.94.5/wrapper is a wrapper (SUID and SGID majordomo or daemon depending on the configuration) that runs the Majordomo program. The quotation marks around the second part of the alias entry are used to tell Sendmail that this part of the entry is all one statement; the quotation marks would be unnecessary if there were not a space between wrapper and majordomo. The | is known as a "pipe"; it is used to tell Sendmail to send the E-mail to the wrapper via the standard input. (Since all the wrapper does here is to call majordomo, the E-mail is actually being sent to Majordomo.) The wrapper accepts one parameter--the parameter of the program it is supposed to execute. (Any parameters after the first will be passed to the program the wrapper is executing.) For security reasons, the wrapper only executes programs located in the Majordomo directory, /usr/local/majordomo-1.94.5/. This restriction prevents a programmer from using the wrapper to run programs that should not have Majordomo privileges. (i.e, wrapper /bin/vi would allow any user to edit any Majordomo configuration file.) When a message is sent to<EMAIL_ADDRESS>Sendmail starts up the wrapper which, in turn, starts up majordomo, and Sendmail sends the message to the majordomo script via the standard input. Majordomo then extracts the commands out of the message and responds appropriately.

Majordomo is, of course, the piece of code that this document revolves around; it consists of a collection of Perl scripts with the sole purpose of managing mailing lists.

Majordomo must run under a specific UID and GID so when any of the scripts are run, they will run under Majordomo's UID. Thus, it is necessary to decide what UID and GID Majordomo should run under. Also, Majordomo must be a Sendmail trusted user

Check the /etc/passwd and /etc/group files to find a UID and GID that are not taken. For this example, a UID of 16 and a GID of 16 was chosen. You have to decide on the location where the Majordomo scripts will reside. If you are using a shadowed password file, add entries similar to

majordomo:x:16:16:Majordomo List Manager:/usr/local/majordomo-1.94.5:

to your /etc/passwd and add an appropriate entry to /etc/shadow.

majordomo:*:10883:0:88888:7:::

Use the other entries in these files as a guide for exactly what should be added. These are only the values for my system. If you are not using shadowed passwords, only an entry in the /etc/passwd file is necessary.

To create a Majordomo group, add a line similar to

majordomo:x:16:jarchie

to your /etc/group file. Appending your username to the end of the line will give you access to the Majordomo files that are group writeable.

The Makefile contains all the information needed to install Majordomo; it is usually necessary to edit lines in the Makefile that refer to system specific settings so Majordomo will be able to install cleanly on your system. Most of the default settings are correct; however, the following settings, almost invariably, need to be changed on a per system basis.

PERL = /bin/perl CC = cc W_HOME = /usr/test/majordomo-$(VERSION) MAN = $(W_HOME)/man W_USER = 123 W_GROUP = 45

should be changed to something more appropriate for your system. For example, in my setup, the values were changed to

PERL = /usr/bin/perl CC = gcc W_HOME = /usr/local/majordomo-1.94.5 MAN = /usr/man W_USER = 16 W_GROUP = 16

Also the majordomo.cf file must be created. An easy way to create this file is to copy the provided sample.cf file to majordomo.cf and edit it.

Again, most of the settings are correct by default, but the following lines might need to be changed for your system from :

$whereami = "example.com"; $whoami = "Majordomo\@$whereami"; $whoami_owner = "Majordomo-Owner\@$whereami"; $homedir = "/usr/test/majordomo"; $digest_work_dir = "/usr/local/mail/digest"; $sendmail_command = "/usr/lib/sendmail";

to something more appropriate such as

$whereami = "kes.emeraldis.com"; $whoami = "majordomo\@$whereami"; $whoami_owner = "majordomo-owner\@$whereami"; $homedir = "/usr/local/majordomo-1.94.5"; $digest_work_dir = "/usr/local/majordomo-1.94.5/digest"; $sendmail_command = "/usr/sbin/sendmail";

$whoami and $whoami_owner do not need to be changed for Majordomo to work; however, I changed them because I like to avoid typing capital letters. $digest_work_dir is a temporary directory where digest files should be placed; this directory should be assigned to wherever you want digests to be stored. If you do not plan to use digested lists, do not worry about this option. $whereami, $homedir, and $sendmail_command should be changed to appropriate values for your system. Unlike the Makefile, these options can always be changed after Majordomo is installed by editing majordomo.cf in the directory where Majordomo was installed. (The configuration file is simply copied during setup.)

The next step is to compile the Majordomo wrapper. The wrapper is the only Majordomo component that needs to be compiled because everything else is a collection of perl scripts and, therefore, is not compiled.

$ make wrapper

To install the Majordomo files, execute the commands

 * 1) make install
 * 2) make install-wrapper

The first command can be done as the Majordomo user (assuming majordomo can create or has access to $home_dir), but the second command needs to be done as root so the installation script can SUID root the Majordomo wrapper. (Since, majordomo was created without a login shell or password, if you want to execute the first command as majordomo, you will need to su majordomo as root in order to become majordomo.)

Sendmail aliases must be created for Majordomo so commands sent to Majordomo can be processed by majordomo, and an alias for the Majordomo owner must be created so people can E-mail you through the standard owner-majordomo address. Add the following entries to your aliases file :

majordomo:      "|/usr/local/majordomo-1.94.5/wrapper majordomo" owner-majordomo: jarchie majordomo-owner: jarchie

Then test your configuration, as a regular user (not as majordomo or as root), run :

$ /usr/local/majordomo-1.94.5/wrapper config-test

This program can detect most problems in the Majordomo installation.

To create a list, create a file with the name of the list in the Majordomo lists directory. For example, to create a list called test, create a test file as Majordomo :

[root@kes /]# su majordomo [majordomo@kes /]$ touch /usr/local/majordomo-1.94.5/lists/test

and add the related aliases :

test:       :include:/usr/local/majordomo-1.94.5/lists/test owner-test:   jarchie test-request: "|/usr/local/majordomo-1.94.5/wrapper request-answer test" test-approval: jarchie

Now test the operation of the list by issuing a lists command to Majordomo :

[jarchie@kes jarchie]$ echo lists | mail majordomo

It should only take a second for majordomo to reply with a message containing all the lists which are currently set up. Next, try issuing a help command.

[jarchie@kes jarchie]$ echo help | mail majordomo

Majordomo should reply with a list of all commands that Majordomo accepts. It might be a good idea to save the message for future reference.

To see if the aliases are working properly, try subscribing and unsubscribing yourself to the list :

[jarchie@kes jarchie]$ echo subscribe test | mail majordomo

You will receive an E-mail message containing instructions on how to confirm your subscription as well as a letter confirming that your command was successful. After sending back your confirmation, Majordomo should send back two letters--one letter stating that your subscribe request was successful and another letter welcoming you to the test list. The owner of the list will also be sent a message stating that you have subscribed to the list.

To unsubscribe from a list, send a unsubscribe command

[jarchie@kes jarchie]$ echo unsubscribe test | mail majordomo

You should be sent back a letter stating that your command was successful.

For some lists, it may be desirable to have Majordomo process messages before they reach the list. For example, Majordomo has the resend script to automatically filter messages based on content (such as taboo words), to prevent people from sending Majordomo commands to the list, and other features. To use these options, it is necessary to use a better set of aliases such as :

test:       "|/usr/local/majordomo-1.94.5/wrapper resend -l test test-list" test-list:  :include:/usr/local/majordomo-1.94.5/lists/test owner-test: jarchie test-owner: jarchie test-request: "|/usr/local/majordomo-1.94.5/wrapper majordomo -l test"

The last entry allows someone simply to send a message to<EMAIL_ADDRESS>with the text subscribe rather than sending a letter to<EMAIL_ADDRESS>with the text subscribe test. Also, note that if sendmail is using smrsh, the above aliases should reference the copy of the wrapper in the safe path--usually /etc/smrsh/wrapper.

It is common for Majordomo's permissions to be set incorrectly causing Majordomo to work improperly. Fortunately, Sendmail and Majordomo typically, give decent error messages indicating a problem. For example, the lists directory must be executable by the user sendmail setuids to, typically mail or daemon. If sendmail cannot execute lists, the permissions must be loosened.

[root@kes root]# chmod +x /usr/local/majordomo-1.94.5/lists

Another common problem is caused by the lists directory being group writeable. To solve this problem, one can ether clear the group writeable bit, or use the sendmail option IncludeFileInGroupWritableDirPath

Majordomo is intended to run on a isolated system; there are a couple of well-known security holes in the scripts that allow any local user capable of executing wrapper to execute code as the majordomo user. If Majordomo must be run on a system providing users with shell access, then it is advisable to tighten up permissions on the wrapper. This can be done by clearing the world executable bit and chgrping the wrapper to the user that needs to run the Majordomo scripts. For example, if Sendmail and MajorCool are both being used to execute the wrapper use the commands

[root@kes root]# cp /usr/local/majordomo-1.94.5/wrapper /etc/smrsh/wrapper [root@kes root]# chmod 4750 /usr/local/majordomo-1.94.5/wrapper [root@kes root]# chown root:nobody /usr/local/majordomo-1.94.5/wrapper [root@kes root]# chmod 4750 /etc/smrsh/wrapper [root@kes root]# chown root:mail /etc/smrsh/wrapper

to secure the system. This will allow sendmail (while running under mail) to execute /etc/smrsh/wrapper while allowing the webserver's MajorCool (running under nobody) to execute /usr/local/majordomo-1.94.5/wrapper. This solution, however, will allow anyone with the UID or GID of mail or nobody to also obtain access to the majordomo account. To protect the nobody account, it is important not to allow normal users to make use of server side includes or cgi scripts unless those services do not run under nobody.

Key terms, files and utilities : Majordomo MTA

Exercises
.

Using Postfix
Postfix is written and maintained by Wietse Venema who has also written tcp_wrappers, and Satan. Postfix began its life as VMailer but Wietse has released the software under the IBM GPL and IBM's lawyers discovered that VMailer was too similar to an existing trade mark so the name had to be changed. Postfix is written as a drop in replacement for sendmail and it comes very close to hitting the mark on this. There are a few ?gotchas? which can bite you but they are not serious. Wietse actively supports Postfix through the postfix-users mailing list and there is also a developers mailing list. You can subscribe to the postfix-users mailing list this way:

echo subscribe postfix-users | mail<EMAIL_ADDRESS>
You can subscribe to the developers list in this way:

echo subscribe postfix-testers | mail<EMAIL_ADDRESS>
One last list we should mention is the announce list. You can join the announce list in this way: echo subscribe postfix-announce | mail<EMAIL_ADDRESS>Postfix development is on-going and these mailing lists are quite active as of this writing. Archives for the mailing lists may be found at: http://www.egroups.com/group/postfix-users/ and at: http://msgs.SecurePoint.com/postfix/.

When a message enters the Postfix mail system, the first stop on the inside is the incoming queue. The figure below shows the main components that are involved with new mail.

The figure shows the main Postfix system components, and the main information flows between them. Yellow ellipsoids are mail programs, Yellow boxes are mail queues or files. Blue boxes are lookup tables.

Programs in the large box run under control by the Postfix resident master daemon. Data in the large box is property of the Postfix mail system.

Mail is posted locally. The Postfix sendmail program invokes the privileged postdrop program which deposits the message into the maildrop directory, where the message is picked up by the pickup daemon. This daemon does some sanity checks, in order to protect the rest of the Postfix system.

Mail comes in via the network. The Postfix SMTP server receives the message and does some sanity checks, in order to protect the rest of the Postfix system. The SMTP server can be configured to implement UCE controls on the basis of local or network-based black lists, DNS lookups, and other client request information. Mail is generated internally by the Postfix system itself, in order to return undeliverable mail to the sender. The bounce or defer daemon brings the bad news.

Mail is forwarded by the local delivery agent, either via an entry in the system-wide alias database, or via an entry in a per-user .forward file. This is indicated with the unlabeled arrow.

Mail is generated internally by the Postfix system itself, in order to notify the postmaster of a problem (this path is also indicated with the unlabeled arrow). The Postfix system can be configured to notify the postmaster of SMTP protocol problems, UCE policy violations, and so on.

The cleanup daemon implements the final processing stage for new mail. It adds missing From: and other message headers, arranges for address rewriting to the standard<EMAIL_ADDRESS>form, and optionally extracts recipient addresses from message headers. The cleanup daemon inserts the result as a single queue file into the incoming queue, and notifies the queue manager of the arrival of new mail. The cleanup daemon can be configured to transform addresses on the basis of canonical and virtual table lookups.

On request by the cleanup daemon, the trivial-rewrite daemon rewrites addresses to the standard<EMAIL_ADDRESS>form. The initial Postfix version does not implement a rewriting language. Implementing one would take a lot of effort, and most sites do not need it. Instead, Postfix makes extensive use of table lookup.

The primary configuration file for Postfix (the working equivalent to /etc/sendmail.cf) is main.cf. The install.cf file contains the initial settings for Postfix which were set up during the RPM installation. The file master.cf is Postfix' master process configuration file. Each line in the master file describes how a mailer component program should be run. In the debugging section we will talk some more about this file. The postfix-script is a wrapper used by Postfix to execute Postfix commands safely for the Linux environment. Let's take a closer look at the install.cf file as this file contains some data which we will need when we start to configure Postfix with main.cf.

The install.cf file is really just a list of the default settings used by the installation program built into the RPM.

Here is the main.cf file with comments by Wietse Venema and our suggested changes interspersed throughout :

# Global Postfix configuration file. This file lists only a subset # of all 100+ parameters. See the sample-xxx.cf files for a full list. #   # The sample files mentioned above are located in /usr/doc/postfix-19990906_pl06/ # The general format is lines with parameter = value pairs. Lines # that begin with whitespace continue the previous line. A value can # contain references to other $names or ${name}s. # LOCAL PATHNAME INFORMATION #  # The queue_directory specifies the location of the Postfix queue. # This is also the root directory of Postfix daemons that run chrooted. # See the files in examples/chroot-setup for setting up Postfix chroot # environments on different UNIX systems. #  queue_directory = /var/spool/postfix

This is the same directory that sendmail uses for the incoming mail queue.

# The program_directory parameter specifies the default location of  # Postfix support programs and daemons. This setting can be overruled # with the command_directory and daemon_directory parameters. #  program_directory = /some/where/postfix/bin

The line above must be corrected. The RPM installs the Postfix binaries into /usr/libexec/postfix by default.

# The command_directory parameter specifies the location of all # postXXX commands. The default value is $program_directory. #  command_directory = /usr/sbin

The line above is correct and may be left as is.

# The daemon_directory parameter specifies the location of all Postfix # daemon programs (i.e. programs listed in the master.cf file). The # default value is $program_directory. This directory must be owned # by root. #  daemon_directory = /usr/libexec/postfix

The line above is correct and may be left as is.

# QUEUE AND PROCESS OWNERSHIP #  # The mail_owner parameter specifies the owner of the Postfix queue # and of most Postfix daemon processes. Specify the name of a user # account THAT DOES NOT SHARE A GROUP WITH OTHER ACCOUNTS AND THAT # OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM. In particular, # don't specify nobody or daemon. PLEASE USE A DEDICATED USER. #  mail_owner = postfix

The line above is correct and may be left as is.

# The default_privs parameter specifies the default rights used by  # the local delivery agent for delivery to external file or command. # These rights are used in the absence of a recipient user context. # DO NOT SPECIFY A PRIVILEGED USER OR THE POSTFIX OWNER. #  #default_privs = nobody

The line above is correct and may be left as is but it should be uncommented (e.g. Remove the leading pound sign).

# INTERNET HOST AND DOMAIN NAMES #   # The myhostname parameter specifies the Internet hostname of this # mail system. The default is to use the fully-qualified domain name # from gethostname. $myhostname is used as a default value for many # other configuration parameters. #  #myhostname = host.domain.name

Set the value in the line above to the Fully Qualified Domain Name (FQDN) for you machine. E.g. if your hostname is turkey and your domain is trot.com then your FQDN would be ?turkey.trot.com?. You will also need to uncomment this line.

#myhostname = virtual.domain.name

The line above is redundant for most configurations and can usually be left commented.

# The mydomain parameter specifies the local Internet domain name. # The default is to use $myhostname minus the first component. # $mydomain is used as a default value for many other configuration # parameters. #  #mydomain = domain.name

The line above should be your domain name only without the hostname prepended to the front of it. As in the example we gave above the correct value here would be trot.com. Don't forget to uncomment the line as well.

# SENDING MAIL #   # The myorigin parameter specifies the domain that locally-posted # mail appears to come from. The default is to append $myhostname, # which is fine for small sites. If you run a domain with multiple # machines, you should (1) change this to $mydomain and (2) set up  # a domain-wide alias database that aliases each user to   #<EMAIL_ADDRESS>#  #myorigin = $myhostname #myorigin = $mydomain

The instructions here are pretty good. Typically what's done here is to let this default to $mydomain. Be sure to uncomment your choice.

# RECEIVING MAIL # The inet_interfaces parameter specifies the network interface # addresses that this mail system receives mail on. By default, # the software claims all active interfaces on the machine. The # parameter also controls delivery of mail to<EMAIL_ADDRESS>#  #inet_interfaces = all

Once again the instructions here are good. Just uncomment the above listed line and you should be fine. Unless you have some odd requirement the next two entries can be left commented. You shouldn't need them.

#inet_interfaces = $myhostname #inet_interfaces = $myhostname, localhost # The mydestination parameter specifies the list of domains that this # machine considers itself the final destination for. # The default is $myhostname + localhost.$mydomain. On a mail domain # gateway, you should also include $mydomain. Do not specify the # names of domains that this machine is backup MX host for. Specify # those names via the relay_domains or permit_mx_backup settings for # the SMTP server (see sample-smtpd.cf.  # The local machine is always the final destination for mail addressed   # to<EMAIL_ADDRESS>of an interface that the mail system   # receives mail on (see the inet_interfaces parameter).   # Specify a list of host or domain names, /file/name or type:table   # patterns, separated by commas and/or whitespace. A /file/name   # pattern is replaced by its contents; a type:table is matched when   # a name matches a lookup key.  Continue long lines by starting the   # next line with whitespace.   #   #mydestination = $myhostname, localhost.$mydomain   #mydestination = $myhostname, localhost.$mydomain $mydomain

The most common practice is to select the line immediately above as your choice here. Be sure to uncomment it and put a comma between the last two entries as it appears to have been omitted.

#mydestination = $myhostname, localhost.$mydomain, $mydomain, #      mail.$mydomain, www.$mydomain, ftp.$mydomain # INTERNET VERSUS INTRANET # The relayhost parameter specifies the default host to send mail to  # when no entry is matched in the optional transport(5) table. When # no relayhost is given, mail is routed directly to the destination. #   # On an intranet, specify the organizational domain name. If your # internal DNS uses no MX records, specify the name of the intranet # gateway host instead. #  # Specify a domain, host, host:port, [address] or [address:port]. # Use the form [destination] to turn off MX lookups. See also the # default_transport parameter if you're connected via UUCP. #  #relayhost = $mydomain #relayhost = gateway.my.domain #relayhost = uucphost #relayhost = [mail.$mydomain:9999]

If you are behind some sort of a firewall or you need to masquerade the envelope (which will be covered later in this document) you would set the ?relayhost? value to the MTA for your domain. If this host is to be *the* MTA for the domain then leave all of these commented out.

# DEFAULT TRANSPORT #  # The default_transport parameter specifies the default message # delivery transport to use when no transport is explicitly given in  # the optional transport(5) table. #  #default_transport = smtp

In most cases the above line would be uncommented and left as is.

#default_transport = uucp # ADDRESS REWRITING #  # Insert text from sample-rewrite.cf if you need to do address # masquerading. #  # Insert text from sample-canonical.cf if you need to do address # rewriting, or if you need username->Firstname.Lastname mapping. # ADDRESS REDIRECTION (VIRTUAL DOMAIN) #  # Insert text from sample-virtual.cf if you need virtual domain support. # "USER HAS MOVED" BOUNCE MESSAGES #  # Insert text from sample-relocated.cf if you need "user has moved" # style bounce messages. Alternatively, you can bounce recipients # with an SMTP server access table. See sample-smtpd.cf. # TRANSPORT MAP #  # Insert text from sample-transport.cf if you need explicit routing.

# ALIAS DATABASE #  # The alias_maps parameter specifies the list of alias databases used # by the local delivery agent. The default list is system dependent. # On systems with NIS, the default is to search the local alias # database, then the NIS alias database. See aliases(5) for syntax # details. #   # If you change the alias database, run "postalias /etc/aliases" (or   # wherever your system stores the mail alias file), or simply run # "newaliases" to build the necessary DBM or DB file. #  # It will take a minute or so before changes become visible. Use # "postfix reload" to eliminate the delay. #  #alias_maps = dbm:/etc/aliases alias_maps = hash:/etc/aliases

The alias_maps line is pointing at the /etc/aliases file which we preserved prior to removing sendmail. Best practice (recommended) usually prefers that all the Postfix config files be kept together so it might be a good idea to change this line to read:

alias_maps = hash:/etc/postfix/aliases

and also make sure that you put the aliases file in /etc/postfix. Otherwise Postfix will complain on startup and fail to run. The default db type on Red Hat Linux is hash so be sure and use it as we have here. One common error which people have is when they use dbm instead of hash. Don't fall into that trap.

#alias_maps = hash:/etc/aliases, nis:mail.aliases #alias_maps = netinfo:/aliases # The alias_database parameter specifies the alias database(s) that # are built with "newaliases" or "sendmail -bi". This is a separate # configuration parameter, because alias_maps (see above) may specify # tables that are not necessarily all under control by Postfix. #  #alias_database = dbm:/etc/aliases #alias_database = dbm:/etc/mail/aliases #alias_database = hash:/etc/aliases

As the instructions say if you want to use the newaliases command to handle the aliases file (recommended) you should uncomment the above line but be sure (if you made the path change we recommended in the alias_maps section) and change it to read:

alias_database = hash:/etc/postfix/aliases

Then be sure to uncomment the line and run the newaliases command before starting Postfix.

#alias_database = hash:/etc/aliases, hash:/opt/majordomo/aliases

If you happen to run majordomo then you should use the line above instead of just the aliases line. Be sure the path to the file majordomo is correct. The best practice convention is to put it into /etc/postfix. Most Red Hat Linux sendmail installations would have had it in /etc/mail/. We will dicuss this a bit more when we get to the listserv section of this document.

# DELIVERED-TO #  # The prepend_delivered_header controls when Postfix should prepend # a Delivered-To: message header. #  # By default, Postfix prepends a Delivered-To: header when forwarding # mail and when delivering to file (mailbox) or command. Turning off # the Delivered-To: header when forwarding mail is not recommended. #  # prepend_delivered_header = command, file, forward # prepend_delivered_header = forward

The defaults will work fine so you can leave this section commented out unless you have some special need or preference.

# ADDRESS EXTENSIONS (e.g., user+foo) #  # The recipient_delimiter parameter specifies the separator between # user names and address extensions (user+foo). See canonical(5), # local(8), relocated(5) and virtual(5) for the effects this has on  # aliases, canonical, virtual, relocated and .forward file lookups. # Basically, the software tries user+foo and .forward+foo before # trying user and .forward. #  # recipient_delimiter = +

This one can be left commented out also, unless you have some special need or preference.

# DELIVERY TO MAILBOX #  # The home_mailbox parameter specifies the optional pathname of a   # mailbox relative to a user's home directory. The default is to  # deliver to the UNIX-style /var/spool/mail/user or /var/mail/user. # Specify "Maildir/" for qmail-style delivery (the / is required). #  #home_mailbox = Mailbox #home_mailbox = Maildir/

On Red Hat Linux systems you should leave this alone unless you know what you're doing. If you're converting from qmail to Postfix (doubtful) then it would probably be useful.

# The mail_spool_directory parameter specifies the directory where # UNIX-style mailboxes are kept. The default setting depends on the # system type. #  # mail_spool_directory = /var/mail # mail_spool_directory = /var/spool/mail

The previous line is correct for Red Hat Linux defaults so it should be uncommented and left as is. # The mailbox_command parameter specifies the optional external # command to use instead of mailbox delivery. The command is run as  # the recipient with proper HOME, SHELL and LOGNAME environment settings. # Exception: delivery for root is done as $default_user. #  # Other environment variables of interest: USER (recipient username), # EXTENSION (address extension), DOMAIN (domain part of address), # and LOCAL (the address localpart). #  # Unlike other Postfix configuration parameters, the mailbox_command # parameter is not subjected to $parameter substitutions. This is to  # make it easier to specify shell syntax (see example below). #  # Avoid shell meta characters because they will force Postfix to run # an expensive shell process. Procmail alone is expensive enough. #  #mailbox_command = /some/where/procmail

The default MDA on Red Hat Linux systems is procmail. You can use the command ?which procmail? to verify the path but unless you've changed procmail's location it is located in ?/usr/bin/procmail?. Don't forget to uncomment the line.

#mailbox_command = /some/where/procmail -a "$EXTENSION" # The mailbox_transport specifies the optional transport in master.cf  # to use after processing aliases and .forward files. This parameter # has precedence over the mailbox_command, fallback_transport and # luser_relay parameters. #  #mailbox_transport = cyrus

On a default Red Hat Linux system you should leave the above line alone. # The fallback_transport specifies the optional transport in master.cf  # to use for recipients that are not found in the UNIX passwd database. # This parameter has precedence over the luser_relay parameter. #  #fallback_transport =

On a default Red Hat Linux system you should leave the above line alone.

# The luser_relay parameter specifies an optional destination address # for unknown recipients. By default, mail for unknown local recipients # is bounced. #  # The following expansions are done on luser_relay: $user (recipient   # username), $shell (recipient shell), $home (recipient home directory), # $recipient (full recipient address), $extension (recipient address  # extension), $domain (recipient domain), $local (entire recipient   # localpart), $recipient_delimiter. Specify ${name?value} or  # ${name:value} to expand value only when $name does (does not) exist. #  # luser_relay =<EMAIL_ADDRESS># luser_relay =<EMAIL_ADDRESS># luser_relay = admin+$local

It's your choice what you do here but it can be quite annoying to receive a bazillion bounces a day. Leave this alone (recommended). # JUNK MAIL CONTROLS #   # The controls listed here are only a very small subset. See the file # sample-smtpd.cf for an elaborate list of anti-UCE controls. # The header_checks parameter restricts what may appear in message # headers. This requires that POSIX or PCRE regular expression support # is built-in. Specify "/^header-name: stuff you do not want/ REJECT" # in the pattern file. Patterns are case-insensitive by default. Note: # specify only patterns ending in REJECT. Patterns ending in OK are # mostly a waste of cycles. #  #header_checks = regexp:/etc/postfix/filename #header_checks = pcre:/etc/postfix/filename

The above section enables a filter which you can use to detect and ?bounce? mail which matches a certain regular expression (REGEXP). The difference between using procmail and regexp or PCRE is that these two catch the mail prior to delivery and can effectively block unwanted mail at the SMTP port.

# The relay_domains parameter restricts what domains (and subdomains  # thereof) this mail system will relay mail from or to. See the # smtpd_recipient_restrictions restriction in the file sample-smtpd.cf. #  # By default, Postfix relays mail only from or to sites in or below # $mydestination, or in the optional virtual domain list. #   # Specify a list of hosts or domains, /file/name patterns or type:name # lookup tables, separated by commas and/or whitespace. Continue # long lines by starting the next line with whitespace. A file name # is replaced by its contents; a type:name table is matched when a  # (parent) domain appears as lookup key. #  # NOTE: Postfix will not automatically forward mail for domains that # list this system as their primary or backup MX host. See the # permit_mx_backup restriction in the file sample-smtpd.cf. #  #relay_domains = $mydestination, $virtual_maps

For anyone who knows already how MX records work this is a critical component in the Postfix configuration. Home users probably won't need this line but anyone who handles mail for mutiple domains will.

Here's a sample of how it can be used:

relay_domains = $mydestination, /etc/postfix/relay-domains

In this example the domains you want to relay for would be placed in the file /etc/postfix/relay-domains. One to a line like so:

here.com mail.here.com there.org mail.there.org

Note: this file is *not* hashed or mapped. It is a simple text file. You can also use IP addresses instead of names. # The mynetworks parameter specifies the list of networks that are # local to this machine. The list is used by the anti-UCE software # to distinguish local clients from strangers. See permit_mynetworks # and smtpd_recipient_restrictions in the file sample-smtpd.cf file. #  # The default is a list of all networks attached to the machine:  a   # complete class A network (X.0.0.0/8), a complete class B network # (X.X.0.0/16), and so on. If you want stricter control, specify a  # list of network/mask patterns, where the mask specifies the number # of bits in the network part of a host address. You can also specify # the absolute pathname of a pattern file instead of listing the # patterns here. #  #mynetworks = <IP_ADDRESS>/28, <IP_ADDRESS>/8

The line above is another critical component in the configuration of Postfix. As the instructions say it specifies the list of networks that are local to this host. For those unfamiliar with the syntax used, it's called Classless Inter-Domain Routing (CIDR) or supernetting. For those familiar with the network classes (A, B, C etc.) it is a way of dividing IP addresses up without reference to class.

#mynetworks = $config_directory/mynetworks # SHOW SOFTWARE VERSION OR NOT #  # The smtpd_banner parameter specifies the text that follows the 220 # status code in the SMTP greeting banner. Some people like to see # the mail version advertised. By default, Postfix shows no version. #  # You MUST specify the $myhostname at the start of the text. When # the SMTP client sees its own hostname at the start of an SMTP # greeting banner it will report a mailer loop. That's better than # having a machine meltdown. #  #smtpd_banner = $myhostname ESMTP $mail_name #smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)

The above config entry is a matter of personal preference. It is not required and is up to the administrator to choose.

# PARALLEL DELIVERY TO THE SAME DESTINATION #  # How many parallel deliveries to the same user or domain? With local # delivery, it does not make sense to do massively parallel delivery # to the same user, because mailbox updates must happen sequentially, # and expensive pipelines in .forward files can cause disasters when # too many are run at the same time. With SMTP deliveries, 10 # simultaneous connections to the same domain could be sufficient to  # raise eyebrows. #   # Each message delivery transport has its XXX_destination_concurrency_limit # parameter. The default is $default_destination_concurrency_limit. local_destination_concurrency_limit = 2 default_destination_concurrency_limit = 10

As the text above says this section is really about rate limiting. It is, essentially, the gas pedal for Postfix. Unless you have some really good reason to change these the defaults should be fine. Once you've run Postfix for a while (particularly those who use it in a professional setting) you may have a better idea of how this should be set for your environment.

# DEBUGGING CONTROL #  # The debug_peer_level parameter specifies the increment in verbose # logging level when an SMTP client or server host name or address # matches a pattern in the debug_peer_list parameter. #  debug_peer_level = 2

We recommend the default here unless there is some overriding reason to change this. Debugging will be covered in a later chapter of this document. For what it's worth this section has no real relevance unless the next is enabled.

# The debug_peer_list parameter specifies an optional list of domain # or network patterns, /file/name patterns or type:name tables. When # an SMTP client or server host name or address matches a pattern, # increase the verbose logging level by the amount specified in the # debug_peer_level parameter. #  # debug_peer_list = <IP_ADDRESS> # debug_peer_list = some.domain

This section is used in combination with debug_peer_level so if that's not enabled then this one is moot. This is actually a very neat feature of Postfix. Think about it for a minut. If everything works fine but there is this one host which seems to have problem receiving or sending mail to or from your host then you could use this feature to increase the logging level for just that host.

# The debugger_command specifies the external command that is executed # when a Postfix daemon program is run with the -D option. #  # Use "command .. & sleep 5" so that the debugger can attach before # the process marches on. If you use an X-based debugger, be sure to  # set up your XAUTHORITY environment variable before starting Postfix. #  debugger_command = PATH=/usr/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5

Leave this section alone for now. We will cover debugging in some detail in a later section of this document. That's it. We've made it through the main.cf file and we're almost ready to start it up.

master.cf
The master daemon is a supervisory application which controls and monitors all of the other Postfix processes. The master.cf file is the master daemon's configuration file. The master.cf file is the throttle for Postfix. Here you set all of the daemon process count limits. A good example of a useful limit would be to set a limit on the number of SMTP processes which can be executed simultaneously, after all, you might not want to receive 50 messages inbound all at the same time. The key thing to understand here is that any process without an express limit defaults to a 50 process limit.

In general terms the master.cf file is fine with the defaults as they are so you can leave it alone.

aliases
This is simply the default aliases file and it could be exactly the same one you used with sendmail (recommended) and it works the same way it always has with the newaliases command. If you use majordomo your majordomo aliases will work the same way they always have and they will work with the newaliases command as well.

Control of the postfix server is done through the init.d scripts Don't forget to issue a postfix reload command after changing the configuration ! If you modify the aliases database (/etc/aliases), don't forget to activate the changes by issueing a newaliases command (as with sendmail)

Key terms, files and utilities : /etc/aliases /etc/postfix/main.cf /etc/postfix/master.cf /var/spool/postfix

Managing mail trafic
procmail is the mail processing utility language written by Stephen van den Berg of Germany. This article provides a bit of background for the intermediate Unix user on how to use procmail. As a "little" language (to use the academic term) procmail lacks many of the features and constructs of traditional, general-purpose languages. It has no "while" or "for" loops. However it "knows" a lot about Unix mail delivery conventions and file/directory permissions -- and in particular about file locking. Although it is possible to write a custom mail filtering script in any programming language using the facilities installed on most Unix systems -- we'll show that procmail is the tool of choice among sysadmins and advanced Unix users.

Unix mail systems consist of MTA's (mail transport agents like sendmail, smail, qmail mmdf etc), MDA's (delivery agents like sendmail, deliver, and procmail), and MUA's (user agents like elm, pine, /bin/mail, mh, Eudora, and Pegasus).

On most Unix systems on the Internet sendmail is used as an integrated transport and delivery agent. sendmail and compatible MTA's have the ability to dispatch mail *through* a custom filter or program through either of two mechanisms: aliases and .forwards.

The aliases mechanism uses a single file (usually /etc/aliases or /usr/lib/aliases) to redirect mail. This file is owned and maintained by the system administrator. Therefore you (as a user) can't modify it. The ".forward" mechanism is decentralized. Each user on a system can create a file in their home directory named .forward and consisting of an address, a filename, or a program (filter). Usually the file *must* be owned by the user or root and *must not* be "writeable" by other users (good versions of sendmail check these factors for security reasons).

It's also possible, with some versions of sendmail, for you to specify multiple addresses, programs, or files, separated with commas. However we'll skip the details of that. Managing mail trafic

You could forward your mail through any arbitrary program with a .forward that consisted of a line like:

"|$HOME/bin/your.program -and some arguments"

Note the quotes and the "pipe" character. They are required. "Your.program" could be a Bourne shell script, an awk or perl script, a compiled C program or any other sort of filter you wanted to write.

However "your.program" would have to be written to handle a plethora of details about how sendmail would pass the messages (headers and body) to it, how you would return values to sendmail, how you'd handle file locking (in case mail came in while "your.program" was still processing one, etc). That's what procmail gives us.

What we have seen so far is general information that applies to all sendmail compatible MTA/MDA's. Managing mail trafic

So, to ensure that mail is passed to procmail for processing the first step is to create the .forward file. (This is safe to do before you do any configuration of procmail itself -- assuming that the package's binaries are installed). Here's the canonical example, pasted from the procmail man pages:

"|IFS=' '&&exec /usr/local/bin/procmail -f-||exit 75 #YOUR_USERNAME"

If you did this and nothing else your mail would basically be unaffected. procmail would just look for its default recipe file (.procmailrc) and finding none -- it would perform its default action on each messages. In other words it would append new messages into your normal spool file.

You can setup procmail system-wide as local delivery agent in sendmail/postfix. When this is done, you can skip the whole part of about using the .forward file -- or you can use it anyway. For instance in sendmail this can be done by changing sendmail.mc with the following:

MAILER_DEFINITIONS dnl # MAILER(`local')dnl <- comment this one out with dnl MAILER(`procmail')dnl MAILER(`smtp')dnl

In postfix this can be done according to the postfix FAQ. Basically it is just editing /etc/postfix/main.cf with the following and reloading postfix.

/etc/postfix/mail.cf: mailbox_command = /path/to/procmail In either event the next step to automating your mail handling is to create a .procmailrc file in your home directory. You could actually call this file anything you wanted -- but then you'd have to slip the name explicitly into the .forward file (right before the "||" operator). Almost everyone just uses the default.

So far all we've talked about it how everything gets routed to procmail -- which mostly involves sendmail and the Bourne shell's syntax. Almost all sendmail's are configured to use /bin/sh (the Bourne shell) to interpret alias and .forward "pipes."

So, here's a very simple .procmailrc file:

$HOME/mail.backup

This just appends an extra copy of all incoming mail to a file named "mail.backup" in your home directory. Note that a bunch of environment variables are preset for you. It's been suggested that you should explicitly set SHELL=/bin/sh (or the closest derivative to Bourne Shell available on your system). I've never had to worry about that since the shells I use on most systems are already Bourne compatible.

However, csh and other shell users should take note that all of the procmail recipe examples that I've ever seen use Bourne syntax.

The :0 line marks the beginning of a "recipe" (procedure, clause, whatever. :0 can be followed be any of a number of "flags." There is a literally dizzying number of ways to combine these flags. The one flag we're using in this example is 'c' for "copy."

The second colon on this line marks the end of the flags and the beginning of the name for a lockfile. Since no name is given procmail will pick one automatically.

This bit is a little complicated. Mail might arrive in bursts. If a new message arrives while your script is still busy processing the last message -- you'll have multiple sendmail processes. Each will be dealing with one message. This isn't a problem by itself. However -- if the two processes might try to write into one file at the same time they are likely to get jumbled in unpredictable ways (the result will not be a properly formatted mail folder).

So we hint to procmail that it will need the check for and create a lockfile. In this particular case we don't care what the name of the lock file would be (since we're not going to have *other* programs writing into the backup file). So we leave the last field (after the colon) blank. procmail will then select its own lockfile name.

If we leave the : off of the recipe header line (omitting the last field entirely) then no lockfile is used. This is appropriate whenever we intend to only read from the files in the recipe -- or in cases where we intend to only write short, single line entries to a file in no particular order (like log file entries). The way procmail works is:

It receives a single message from sendmail (or some sendmail compatible MTA/MDA). There may be several procmail processing running currently since new messages may be coming in faster than they are being processed. It opens its recipe file (.procmailrc by default or specified on its command line) and parses each recipe from the first to the last until a message has been "delivered" (or "disposed of" as the case may be).

Any recipe can be a "disposition" or "delivery" of the message. As soon as a message is "delivered" then procmail closes its files, removes its locks and exits.

If procmail reaches the end of it's rc file (and thus all of the INCLUDE'd files) without "disposing" of the message -- than the message is appended to your spool file (which looks like a normal delivery to you and all of your "mail user agents" like Eudora, elm, etc).

This explains why procmail is so forgiving if you have *no* .procmailrc. It simply delivers your message to the spool because it has reached the end of all its recipes (there were none). The 'c' flag causes a recipe to work on a "copy" of the message -- meaning that any actions taken by that recipe are not considered to be "dispositions" of the message.

Without the 'c' flag this recipe would catch all incoming messages, and all your mail would end up in mail.backup. None of it would get into your spool file and none of the other recipes would be parsed.

The next line in this sample recipe is simply a filename. Like sendmail's aliases and .forward files -- procmail recognizes three sorts of disposition to any message. You can append it to a file, forward it to some other mail address, or filter it through a program.

Actually there is one special form of "delivery" or "disposition" that procmail handles. If you provide it with a directory name (rather than a filename) it will add the message to that directory as a separate file. The name of that file will be based on several rather complicated factors that you don't have to worry about unless you use the Rand MH system, or some other relatively obscure and "exotic" mail agent.

A procmail recipe generally consists of three parts -- a start line (:0 with some flags) some conditions (lines starting with a '*' -- asterisk -- character) and one "delivery" line which can be file/directory name or a line starting with a '!' -- bang -- character or a '|' -- pipe character.

Here's another example:

/dev/null

This is a simple one consisting of no flags, one condition and a simple file delivery. It simply throws away any mail from "someone I don't like." (/dev/null under Unix is a "bit bucket" -- a bottomless well for tossing unwanted output DOS has a similar concept but it's not nearly as handy).

Here's a more complex one:

* !^FROM_MAILER * !^X-Loop<EMAIL_ADDRESS>| $HOME/bin/my.script

This consists of a set of negative conditions (notice that the conditions all start with the '!' character). This means: for any mail that didn't come from a "daemon" (some automated process) and didn't come a "mailer" (some other automated process) and which doesn't contain any header line of the form: "X-Loop: myadd..." send it through the script in my bin directory.

I can put the script directly in the rc file (which is what most procmail users do most of the time). This script might do anything to the mail. In this case -- whatever it does had better be good because procmail way will consider any such mail to be delivered and any recipes after this will only be reached by mail from DAEMONs, MAILERs and any mail with that particular X-Loop: line in the header.

These two particular FROM_ conditions are actually "special." They are preset by procmail and actually refer to a couple of rather complicated regular expressions that are tailored to match the sorts of things that are found in the headers of most mail from daemons and mailers.

The X-Loop: line is a normal procmail condition. In the RFC822 document (which defines what e-mail headers should look like on the Internet) any line started with X- is a "custom" header. This means that any mail program that wants to can add pretty much any X- line it wants.

A common procmail idiom is to add an X-Loop: line to the header of any message that we send out -- and to check for our own X-Loop: line before sending out anything. This is to protect against "mail loops" -- situations where our mail gets forwarded or "bounced" back to us and we endlessly respond to it.

So, here's a detailed example of how to use procmail to automatically respond to mail from a particular person. We start with the recipe header.

... then we add our one condition (that the mail appears to be from the person in question):

*<EMAIL_ADDRESS>
FROM is a "magic" value for procmail -- it checks from, resent-by, and similar header lines. You could also use ^From: -- which would only match the header line(s) that start with the string "From:"

The ^ (hiccup or, more technically "caret") is a "regular expression anchor" (a techie phrase that means "it specifies *where* the pattern must be found in order to match." There is a whole book on regular expression (O'Reilly & Associates). "regexes" permeate many Unix utilities, scripting languages, and other programs. There are slight differences in "regex" syntax for each application. However the man page for 'grep' or 'egrep' is an excellent place to learn more.

In this case the hiccup means that the pattern must occur at the beginning of a line (which is its usual meaning in grep, ed/sed, awk, and other contexts).

... and we add a couple of conditions to avoid looping and to avoid responding to automated systems

* !^FROM_DAEMON * !^FROM_MAILER

(These are a couple more "magic" values. The man pages show the exact regexes that are assigned to these keywords -- if you're curious or need to tweak a special condition that is similar to one or the other of these).

... and one more to prevent some tricky loop:

* !^X-Loop<EMAIL_ADDRESS>
(All of these patterns start with "bangs" (exclammation points) because the condition is that *no* line of the header start with any of these patterns. The 'bang' in this case (and most other regex contexts) "negates" or "reverses" the meaning of the pattern).

... now we add a "disposition" -- the autoresponse.

| (formail -rk \ -A "X-Loop<EMAIL_ADDRESS>\ -A "Precendence: junk"; \ echo "Please don't send me any more mail";\ echo "This is an automated response";\ echo "I'll never see your message";\ echo "So, GO AWAY" ) | $SENDMAIL -t -oi

This is pretty complicated -- but here's how it works: The | character tells procmail that it should launch a program and feed the message to it. The open parenthesis is a Bourne shell construct that groups a set of commands in such a way as to combine the output from all of them into one "stream."

The 'formail' command is a handy program that is included with the procmail package. It "formats" mail headers according to its command line switches and its input. -rk tells 'formail' to format a "reply" and to "keep" the message body. With these switches formail expects a header and body as input.

The -A parameters tells formail to "add" the next parameter as a header line. The parameters provided to the -A switch must be enclosed in quotes so the shell treats the whole string (spaces and all) as single parameters. The backslashes at the end of each line tell procmail mail to treat the next line as part of this one. So, all of the lines ending in backslashes are passed to the shell as one long line.

This "trailing backslash" or "line continuation" character is a common Unix idiom found in a number of programming languages and configuration file formats. The semicolons tell the shell to execute another command -- they allow several commands to be issued on the same command line.

Each of the echo commands should be reasonably self-explanatory. We could have used a 'cat' command and put our text into a file if we wanted. We can also call other programs here -- like 'fortune' or 'date' and their output would be combined with the rest of this).

Now we get to the closing parenthesis. This marks the end of the block of commands that we combined. The output from all of those is fed into the next pipe -- which starts the local copy of sendmail (note that this is another variable that procmail toughtfully presets for us).

The -t switch on sendmail tell it to take the "To:" address from the header of it's input (where 'formail -r' put it) and the -oi switch enables the sendmail "option" to "ignore" lines that consist only of a 'dot' (don't worry about the details on that).

Most of the difficulty in understanding procmail as nothing to do with procmail itself. The intricacies of regular expressions (those wierd things on the '*' -- conditional lines) and shell quoting and command syntax, and how to format a reply header that will be acceptable to sendmail (the 'formail' and 'sendmail' stuff) are the parts that require so much explanation.

More information about procmail can be found in Era Eriksson's "Mini-FAQ." at http://www.iki.fi/~era/procmail/mini-faq.html or one of the several mirrors like http://www.zer0.org/procmail/mini-faq.html http://www.dcs.ed.ac.uk/home/procmail/faq/mini-faq.html

Key terms, files and utilities : Procmail .procmailrc

Exercises
.

Serving news
The INND daemon is one of the most used news server program It provides Network News Transport Protocol (NNTP) service. Major newsgroups include: alt,comp,gnu,misc,news,rec,sci,soc, and talk. Newsgroups are configured in a hierarchical fashion. INND by default uses the NNTP port TCP 119

Configuration :

Location of configuration files is /etc/news/. A minimal leafnode setup requires that you modify the following files:

inn.conf :

Set the following options. The defaults for the remaining options should be fine.

organization:  MyOrganization domain:        mydomain.com server:        news.mydomain.com incoming.conf :

Place your ISP's news server information in here.

peer myisp.com { hostname: news.myisp.com }
 * 1) Peer definition
 * 2) MyISP.com<PHONE_NUMBER><EMAIL_ADDRESS>
Newsfeeds
If you want to post articles, you need to modify newsfeeds. news.myisp.com:comp.*,!comp.sources.*,comp.sources.unix/!foo:Tf,Wnm:news.myisp.com The colon is the field delimiter used above. The format of that above line is: sitename[/exclude,exclude,...]:pattern,pattern,...[/distrib,distrib,..]:flag,flag,...:param

Options:

 * sitename : Names the site to which this feed relates. It can be called anything you want and does not have to be the domain name of the site.

 * pattern : Indicates which news groups are to be sent to this site. The default is to send all groups (leave it blank if that's what you want). The above example will cause all "comp" groups to be received, but not any group under "comp.sources" except for "comp.sources.unix".

 * distribution : If specified, and an article has a "Distribution" header, it is check against this value. If the distribution specified matches the distribution header in the article, it is sent. However, if the distribution specified starts with an exclamation point, and the distribution header in the article matches, it is not sent. In the above example, any article with a distribution header containing "foo" will not be sent.

param - Meaning varies depending on the feed type. When the feed type is "file" as in the example above, it specifies the file to write an entry to when an article is received. If not an absolute path, it is relative to the "pathoutgoing" option in inn.conf.
 * flag : Specify various options about the newsfeed. The above options specify that this is a file feed type (Tf), and that only articles "message-id" and "token" (Wmn) should be written.

readers.conf : Edit this file if you want to allow readers on other computers. motd.news : if you allow readers, it is a good idea to put a banner in this file that relays your usage policies to your readers.

Run inncheck to correct any permissions problems and catch any configuration file errors. Run makehistory to initialize the INN history database. Run makedbz to rebuild the dbz database files. Run innd and test with a news client

Troubleshooting
innd won't start Use inncheck. Check logs under /var/log/news. Readers can't read : Verify that the reader is allowed access by checking nnrp.access. Make sure innd is running. Check logs under /var/log/news. telnet to port 119 and see if a banner comes up. Posters can't post : Confirm poster is allowed to post by checking nnrp.access. Check logs under /var/log/news. telnet to port 119 and see if a banner comes up with (posting allowed).

Key terms, files and utilities : Innd


text:
East Asian Calligraphy/Introduction

What is "East Asian Orthography"? Isn't it just those symbols you see in Chinatown or Koreatown, or in anime or manga? Really, East Asian writing is a lot more complex than that, and it is important to know what you're dealing with before you learn how to write an East Asian language.

By East Asian writing, we are really talking about the set of writing used by the Chinese, Japanese, and Korean languages. But these languages use very different writing systems.

Chinese, for example, uses Chinese characters or logographs, where each symbol represents a word or a word root (called "morphemes"), with one (or several) defined meanings and pronunciations. If English were written this way, for example, we would have individual symbols for simple words like "the", "at", "sun", "moon", etc. and a series of symbols for more complex words like "understand" and "approve", with one symbol for each part of the word. (For example, "understand" may be composed of two symbols, one for "under" and one for "stand".)

Contrary to popular belief, Chinese characters do not in any way represent ideas or philosophies directly. It represents a language, and nothing more.

Japanese, on the other hand, uses the kana system, composed of two syllabaries, hiragana and katakana. "Syllabaries" are systems where one symbol represents a syllable. For example, "ka" is a syllable, and hence in Japanese it is written with a single hiragana letter or a single katakana letter. Same with, say, "ki", which is written with another hiragana letter or a katakana letter. Hiragana developed out of stylized cursive Chinese characters, and katakana developed out of parts taken from Chinese characters. Chinese characters, known in Japanese as kanji, are also used in the Japanese language to write both Chinese loanwords and native Japanese words.

Korean uses hangul, which is an alphabet just like the English one, with one letter for each discrete sound. Although Korean letters were originally invented as abstract, geometrical shapes, their stroke forms are nevertheless usually written just like those used in Chinese characters. In addition, Korean letters are arranged into square blocks by syllable, again, making Korean writing look similar to Chinese. Chinese characters, known in Korean as hanja, are also used to an extent in South Korea. In North Korea, hanja have been completely abolished.

Hence, East Asian orthography is really a set of three very different writing systems: Chinese characters, with one symbol for each word root; Japanese kana, with one symbol for each syllable; and Korean hangul, with one symbol for each discrete sound.

Despite their functional differences, however, East Asian writing systems stem from a common ancient Chinese root. By and large, they are written with the same strokes, use the same stroke order, and achieve the same general aesthetic effect. Moreover, Chinese characters are widely used in all three languages, and a thorough study of any one of the three languages would certainly entail a thorough study of Chinese characters.

This textbook will, therefore, attempt to cover topics of East Asian orthography that are common to all three systems, namely, the aesthetic aspects of East Asian writing. With these aesthetic considerations in mind, it will be possible for you avoid common pitfalls of beginners, whose writing (be it in Chinese characters, Japanese kana, or Korean hangul) often end up looking misshapen and askew.

On the other hand, this course will not focus on the functional aspects of the three different systems, which are, of course, all very different. That is the job of the individual language textbooks.

title: East Asian Calligraphy/Introduction


text:
¡Allá tú!

¡Allá tú! (Spanish for "It's Your Business") is the Spanish version of Deal or No Deal. It was initially broadcast by Telecinco between 2004 and 2008 and later changed to sister channel Cuatro for a comeback in 2011, before returning to Telecinco in 2023.

The original version was hosted by Jesús Vázquez, but during Jesús's break to focus on another Endemol show, Operación Triunfo, Silvia Jato and Arturo Valls filled in for him. He reprised his role as host on both revivals.

This version is very similar to the French and Italian versions, with 22 boxes held by 22 players representing 22 regions of Spain (except for the 2006 specials, which played like the US version, with 26 cases held by 26 models).

On June 19, 2007, Gilbert from Tarragona became the first top prize winner, winning €600,000. On July 25, 2011, Maria del Carmen Bonilla from Asturias won €300,000 and became the second top prize winner.

2004-2008
The program begins by each contestant being described by name and region (usually the newest contestant to replace the one who played last episode receives a special presentation), and then they answer a qualifying question, usually about statistics (i.e. "What percentage of the Spanish elderly have used the Internet? 1: 6%, 2: 26%, 3: 69%"). Out of those who answered correctly, one is drawn, who proceeds to the podium with the box they randomly selected before the game. Each box contains a different amount of money, from €0.10 to €300,000 (or one of 3 joke prizes).

In the main game, the contestant's objective is to find out what their box contains by removing the boxes of the other 21 contestants: when each box is selected, the card with the box's value on is shown to the camera before the value of the card is out of play, and the display shows the amounts remaining.

At various points in the game, La Banca (The Banker) makes a phone call to the host and makes the contestant a cash offer to purchase their box and for the contestant to quit the game based on the value of the boxes left. The contestant then decides whether to accept the offer and end the game or decline the offer and continue playing.

In the first round the contestant opens six boxes, three in the second, third, fourth, and fifth, and then one in the final two rounds. One player plays for the entire episode. When their episode finishes, a new contestant replaces them in the wings.

In 2005, the show started a phone-in feature where the in-studio contestant would split their winnings with a lucky at-home caller. As a result, many values on the board were increased, with the top prize doubling to €600,000.

2006 Special
In 2006, ¡Allá tú! aired a primetime special based on the US version called La Noche de los 2.000.000€ (The €2,000,000 Night), with a new set similar to the US version and 26 cases held by models (as opposed to 22 boxes held by other contestants). The special featured two contestants, each playing for €1,000,000 (split with an at-home caller, like the daytime version).

2011 version
The show was revived in 2011 on Telecinco's sister network Cuatro, with the original board and a new twist—the Green Boxes.

2023-2024
The first season of the 2023 revival aired on Sunday nights as a weekly prime time format with a runtime similar to that of the 2006 million-euro specials. The show featured two contestants on each episode, each playing for a top prize of €250,000. The revival introduced two new elements to the gameplay:
 * El pulsador de la oferta extra (The Extra Offer Buzzer): Before hearing the first offer, the player is asked to guess how much money the Banker has offered to purchase the box. If the player guesses correctly or is off by €1,000 or less, they have the option to activate the buzzer and request one additional offer from the Banker, aside from the ones that happen when specific numbers of boxes remain, at any time in the game.
 * La comunidad de la suerte (The Lucky Region): The Banker can offer the player to abandon the game if it isn't going well, and instead try to guess which Spanish region is written in a smaller, silver box. The player wins €30,000 for guessing correctly in the first attempt and €10,000 for guessing correctly in the second attempt, but the player leaves without any money if neither guess is correct.

The second season was a daily format, akin to the original version, airing Monday thru Thursday (later Monday thru Wednesday) each week. As a result of the change in format, one contestant was featured each episode, and the top prize was lowered to €150,000. Additionally, the prizes for La comunidad de la suerte were cut in half to €15,000 for the first attempt and €5,000 for the second attempt.

Box/Case Values
NOTE: In each episode, three of the smaller values are replaced with three different joke prizes (except for the million euro specials).

In 2011, Box 23 ("The Green Box") could contain one of the following amounts:

title: ¡Allá tú!


text:
User:Tkaye78/Books/Feigned Illnesses

Feigned Illnesses

 * Malingering
 * SIMS (Structured Inventory of Malingered Symptomatology)
 * Factitious disorder
 * Ganser syndrome
 * Somatic symptom disorder

title: User:Tkaye78/Books/Feigned Illnesses


text:
Talk:Dexter Air Taxi

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Dexter Air Taxi. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20160306053502/http://aviasystems-usa.com/netcat_files/File/otz2_Dexter.pdf to http://aviasystems-usa.com/netcat_files/File/otz2_Dexter.pdf

Cheers.— InternetArchiveBot  (Report bug) 20:34, 9 September 2017 (UTC)

title: Talk:Dexter Air Taxi


text:
Introduction to psychology/Questions one: Definition and History/1.04

Things can be learned from animal studies in psychology that apply to humans. Some studies that can be performed on animals are not ethical to perform on humans.


text:
Wikipedia:Articles for improvement/main page placement

Note: Pages within Wikipedia's Main page space will require development for the random generation of TAFI entries to occur. The Random component appears to not be transferable between namespaces via transclusion (e.g. transcluded from Template namespace to Main namespace). For examples of pages that appear likely to need re-creation within the Main page space, see Template:TAFI Main page, Template:TAFI Main page/box-header, Template:TAFI Main page/Main page queue/1 through Template:TAFI Main page/Main page queue/7 and Template:Random component main namespace for the code that needs to be existent as a separate page in Main page space, from which the (e.g.) reads from via transclusion.

For additional information, please see: User:Northamerica1000/TAFI random generation. Also note that the example article below "Foobar" is not a TAFI selection; it's just an example to demonstrate layout. Northamerica1000(talk) 06:39, 25 January 2013 (UTC)