Is not honoring bounces-to violation of RFC?
I know this question is not specifically germane to Postfix but everyone on this list has extensive experience with bouncing policies. If a receiver of campaign emails (that promotes itself as an email security service) sends bounces to "reply-to" rather than "bounces-to" as a policy despite bounces-to present in all campaign emails headers, would this be considered a violation of RFCs?
Is not honoring bounces-to violation of RFC?
If Return-path is added by receiving MTA, as you say, below, and that it contains the MAIL FROM, then why do I see the following in source code of received message in which return-path does not match From? X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: From: "Sears" X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-Path: From: lucky On 06/29/2016 10:50 AM, Kris Deugau wrote: Chip wrote: My mistake NOT "bounces-to" rather "return-path" Return-path is a header added by the receiving MTA (usually on final delivery) that contains the envelope sender (MAIL FROM) used by the sending system.
Re: Is not honoring bounces-to violation of RFC?
Chip: > I know this question is not specifically germane to Postfix but everyone > on this list has extensive experience with bouncing policies. > > If a receiver of campaign emails (that promotes itself as an email > security service) sends bounces to "reply-to" rather than "bounces-to" > as a policy despite bounces-to present in all campaign emails headers, > would this be considered a violation of RFCs? RFCs are published at ietf.org, so I did an experiment: site:ietf.org bounces-to Neither google.com nor bing.com produced any matches. I guess that result speaks for itself, no? Wietse
Re: Is not honoring bounces-to violation of RFC?
Okay I guess it does. Meaning there are no standards for the way emailers should respond to bounces? On 06/28/2016 12:54 PM, Wietse Venema wrote: Chip: I know this question is not specifically germane to Postfix but everyone on this list has extensive experience with bouncing policies. If a receiver of campaign emails (that promotes itself as an email security service) sends bounces to "reply-to" rather than "bounces-to" as a policy despite bounces-to present in all campaign emails headers, would this be considered a violation of RFCs? RFCs are published at ietf.org, so I did an experiment: site:ietf.org bounces-to Neither google.com nor bing.com produced any matches. I guess that result speaks for itself, no? Wietse
Re: Is not honoring bounces-to violation of RFC?
Chip: > Okay I guess it does. Meaning there are no standards for the way > emailers should respond to bounces? According to RFC 5321, the definition of the Internet email protocol, an undeliverable email message is returned to its MAIL FROM address, and that return message is sent with the null MAIL FROM adress. Undeliverable mail with the null MAIL FROM address is not returned. That answers your question, but you probably meant something else. Wietse
Re: Is not honoring bounces-to violation of RFC?
On 6/28/2016 12:12 PM, Chip wrote: > Meaning there are no standards for the way > emailers should respond to bounces? bounces always go to the envelope sender, regardless of any unrelated junk in the headers.
Re: Is not honoring bounces-to violation of RFC?
In standard email campaign software like phplist, constantcontact, mailchimp all of those popular email campaign software many of which use Exim and are used literally by millions of email campaigners, the bounces-to is where bounces are expected to be returned so that they can be effectively removed from mailings and people don't' receive spam. It is an very important part of email campaigns and reduces by great amounts the amount of spam that is manufactured. Okay maybe it's not in RFC's but I would it would be at least a recommendation that bounces can be routed back to bounces-to rather than reply-to. After all, why have the field at all if it's not used properly. On 06/28/2016 01:51 PM, Noel Jones wrote: On 6/28/2016 12:12 PM, Chip wrote: Meaning there are no standards for the way emailers should respond to bounces? bounces always go to the envelope sender, regardless of any unrelated junk in the headers.
Re: Is not honoring bounces-to violation of RFC?
Bounces go to the envelope sender, the address used in the SMTP MAIL FROM command. Not reply-to, nor bounces-to, nor any other address listed in a header. To control where bounces are returned, set the envelope sender. -- Noel Jones On 6/28/2016 1:28 PM, Chip wrote: > In standard email campaign software like phplist, constantcontact, > mailchimp all of those popular email campaign software many of which > use Exim and are used literally by millions of email campaigners, > the bounces-to is where bounces are expected to be returned so that > they can be effectively removed from mailings and people don't' > receive spam. It is an very important part of email campaigns and > reduces by great amounts the amount of spam that is manufactured. > > Okay maybe it's not in RFC's but I would it would be at least a > recommendation that bounces can be routed back to bounces-to rather > than reply-to. After all, why have the field at all if it's not > used properly. > > > > > On 06/28/2016 01:51 PM, Noel Jones wrote: >> On 6/28/2016 12:12 PM, Chip wrote: >>> Meaning there are no standards for the way >>> emailers should respond to bounces? >> bounces always go to the envelope sender, regardless of any >> unrelated junk in the headers. >> >> >> >> >
Re: Is not honoring bounces-to violation of RFC?
Mail-server refusals (as in NOQUEUE) are generated before the email body is received - and will also be sent to the envelope sender. On 28/06/16 18:51, Noel Jones wrote: > On 6/28/2016 12:12 PM, Chip wrote: >> Meaning there are no standards for the way >> emailers should respond to bounces? > bounces always go to the envelope sender, regardless of any > unrelated junk in the headers. > > > >
Re: Is not honoring bounces-to violation of RFC?
> On 28 Jun 2016, at 19:28, Chip wrote: > > Okay maybe it's not in RFC's but I would it would be at least a > recommendation that bounces can be routed back to bounces-to rather than > reply-to. After all, why have the field at all if it's not used properly. No RFC defines a bounces-to email header. Or how an MTA or MUA should handle one. As a matter of fact, the only email-related RFC which contains the word “bounce” is RFC5355. Which is in the Experimental category. It uses “bounce" in the context of clients speaking UTF8SMTP to servers that don’t support this feature. Here’s the relevant part of Section 4.4 of that RFC: Below are a few examples of possible representations. ... "DISPLAY_NAME" ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported ; without DISPLAY_NAME and quoted string ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported If you think bounces-to has to be part of Internet email standards, feel free to write up a draft and submit it to the IETF.
Re: Is not honoring bounces-to violation of RFC?
I don't dispute any of what happens just saying that a company out there that advertises as their mission to eliminate spam and whom, they advertise, has access to 30 million MX records is sending bounces to the reply to or envelope sender whereas I'm just saying that ALL email campaign services allow and indeed suggest users to identity a specific sole purpose email account in which to receive bounces to eliminate spam and which almost all email campaigners adhere to, is thus defeating the purpose of there mission. Maybe what they do works for the small time spammer who uses a personal account to distribute spam but it defeats the purpose of eliminating non deliverables for honest mailers. On Jun 28, 2016 3:17 PM, "Allen Coates" wrote: > Mail-server refusals (as in NOQUEUE) are generated before the email body > is received - and will also be sent to the envelope sender. > > On 28/06/16 18:51, Noel Jones wrote: > > On 6/28/2016 12:12 PM, Chip wrote: > >> Meaning there are no standards for the way > >> emailers should respond to bounces? > > bounces always go to the envelope sender, regardless of any > > unrelated junk in the headers. > > > > > > > > > >
Re: Is not honoring bounces-to violation of RFC?
> On 28 Jun 2016, at 20:26, Jeffs Chips wrote: > > I'm just saying that ALL email campaign services allow and indeed suggest > users to identity a specific sole purpose email account in which to receive > bounces to eliminate spam and which almost all email campaigners adhere to The IETF process is open to all. Feel free to make use of it. BTW, the IETF is where Internet email protocols get developed and documented. It doesn’t and can’t happen on postfix-users.
Re: Is not honoring bounces-to violation of RFC?
My mistake NOT "bounces-to" rather "return-path" as in the following snippet of campaign emails from Home Depot, Martha Stewart and Sears: From - Mon Jun 20 08:43:03 2016 X-Account-Key: account15 X-UIDL: UID1962-1324328699 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: From - Tue Jun 21 14:39:36 2016 X-Account-Key: account15 X-UIDL: UID1969-1324328699 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: From - Mon Jun 20 08:43:02 2016 X-Account-Key: account15 X-UIDL: UID1961-1324328699 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: So is "Return-path" supposed to be respected? Because the company I was speaking of insists it's appropriate to send bounces to something other than "Return-path" usually the "From" or "Reply-to". On 06/28/2016 03:36 PM, Jim Reid wrote: On 28 Jun 2016, at 20:26, Jeffs Chips wrote: I'm just saying that ALL email campaign services allow and indeed suggest users to identity a specific sole purpose email account in which to receive bounces to eliminate spam and which almost all email campaigners adhere to The IETF process is open to all. Feel free to make use of it. BTW, the IETF is where Internet email protocols get developed and documented. It doesn’t and can’t happen on postfix-users.
Re: Is not honoring bounces-to violation of RFC?
On 6/28/16 2:01 PM, Chip wrote: > My mistake NOT "bounces-to" rather "return-path" This is not a subtle difference. The Return-Path header gets added (or replaced, in the case it is already there) by the receiving MTA with the MAIL FROM address. It is placed there only for convenience of the receiving part. Setting the Return-Path header on outbound messages has no effect. What you need to change is the MAIL FROM address, as already explained a few times in this thread. Cheers, Daniele
Re: Is not honoring bounces-to violation of RFC?
Chip wrote: > My mistake NOT "bounces-to" rather "return-path" Return-path is a header added by the receiving MTA (usually on final delivery) that contains the envelope sender (MAIL FROM) used by the sending system. > as in the following > snippet of campaign emails from Home Depot, Martha Stewart and Sears: > Return-path: Notice this one contains an extended ID number? Their mail-sending infrastructure almost certainly generates this pseudoaddress on a per-mailing+recipient basis, so automated systems can quickly tell whose email is bouncing, and which email campaign it bounced on. > Return-path: This doesn't use a unique envelope sender for each recipient, so they'll have to do more complex parsing of any bounce messages to identify stale recipients. > So is "Return-path" supposed to be respected? Because the company I was > speaking of insists it's appropriate to send bounces to something other > than "Return-path" usually the "From" or "Reply-to". No; as stated upthread bounces must be sent to the envelope sender address. Any system sending bounces to any other address is misbehaving and may end up blacklisted (locally or in public datasources like DNSBLs) because of it. All that said, if *you* are a perfectly innocent bulk-mailer who is *receiving* bounces to the wrong place, you'll probably have to suck up and deal with it to keep your service clean. -kgd
Re: Is not honoring bounces-to violation of RFC?
Le 29/06/2016 17:02, Chip a écrit : If Return-path is added by receiving MTA, as you say, below, and that it contains the MAIL FROM, then why do I see the following in source code of received message in which return-path does not match From? X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-path: From: "Sears" X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-Path: From: lucky MAIL FROM/envelope from and header From are two different beast. Return-Path: is MAIL FROM/envelope from. From: lucky in your example is header from, witch is data and and not directly related to MAIL FROM/envelope from. On 06/29/2016 10:50 AM, Kris Deugau wrote: Chip wrote: My mistake NOT "bounces-to" rather "return-path" Return-path is a header added by the receiving MTA (usually on final delivery) that contains the envelope sender (MAIL FROM) used by the sending system.
Re: Is not honoring bounces-to violation of RFC?
On 29/06/16 17:02, Chip wrote: > If Return-path is added by receiving MTA, as you say, below, and that it > contains the MAIL FROM, then why do I see the following in source code > of received message in which return-path does not match From? Could I respectfully suggest that you read up on the difference between the envelope sender and the From header, for example here: http://blog.tidymail.co.uk/glossary/smtp-envelope/ The two are not necessarily the same, and in fact in the examples you showed they were not.
Re: Is not honoring bounces-to violation of RFC?
I will read up on it. Thank you for the link. Not everyone, I think, who visits this list is an engineer. So it would have been easier to understand if the response had been along the lines of: "envelope-from" instead of just FROM since there are a number of Froms in the source code. Someone wrote: "Return-path is a header added by the receiving MTA (usually on final delivery) that contains the envelope sender (MAIL FROM) used by the sending system. On 06/29/2016 11:22 AM, Jan Ceuleers wrote: On 29/06/16 17:02, Chip wrote: If Return-path is added by receiving MTA, as you say, below, and that it contains the MAIL FROM, then why do I see the following in source code of received message in which return-path does not match From? Could I respectfully suggest that you read up on the difference between the envelope sender and the From header, for example here: http://blog.tidymail.co.uk/glossary/smtp-envelope/ The two are not necessarily the same, and in fact in the examples you showed they were not.
Re: Is not honoring bounces-to violation of RFC?
> I will read up on it. Thank you for the link. > > Not everyone, I think, who visits this list is an engineer. In that you are mistaken. Almost everyone who subscribes to this mailing-list is an engineer. Please re-read that line. This mailing list is for people who need to configure or make changes to the configuration of a Mail Transfer Agent called Postfix. Some people here actually suggest software changes, since the author of the system is present on the list. Pretty much everyone here is an engineer. RFC 821 (and its successors) is documentation of the COMMANDS (verbs, if you will) used to move mail, of which one, MAIL FROM, is a way to express where an NDR should go if something goes wrong. Furthermore, at some points along the journey of a piece of mail (data, or a NOUN if you will), it will be captured and recorded in a header, most typically in the Return-Path value. But it is not guaranteed to be stored in any header at any time because it's a COMMAND to a server. RFC 822 (and its successors) is documentation of the structure of DATA (the NOUNS mentioned above) that represents an email message, which is divided up into Headers and Data. One of those headers is, "From:". And almost all of those headers are little more than comments, forgeable by anyone with the inclination to do so, and at best advisory in nature. So, to summarize: The "From:" header is a comment, and may or may not reflect reality. Typically it does, but not always. The "Return-Path" is a recognized way to capture the value of the "MAIL FROM:" command, and encode it into the headers, but it is best described as a, "Virtual Header". Some other headers inserted by arbitrary third parties are not documented in *ANY* RFC anywhere, and almost everyone completely ignores them. Such is the case with, "bounces-to". It's not a standard. Almost everything will ignore it. People who expect it to always work should be prepared for disappointment. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: Is not honoring bounces-to violation of RFC?
On 29 Jun 2016, at 11:45, Chip wrote: I will read up on it. Thank you for the link. Not everyone, I think, who visits this list is an engineer. True, unless you accept Michael Wise's generous functional definition. I'm on the fence there, as I've held job titles calling me an engineer but my only formal engineering training was secondary to theatrical set design and construction, i.e. to make sure actors didn't die in collapses of not quite enough steel and/or wood. All of my education in "software engineering" and "systems engineering" (skills I supposedly have if you believe job titles) is from a handful of low-numbered college classes 25+ years ago and on-the-job/self training But Michael is entirely correct in that nearly everyone subscribed to this list is a de facto mail system "engineer" in that we work with the complexities of configuring and operating mail systems. So even though I don't build bridges, haven't built a stage set in decades, and don't write much ode these days, I DO "drive the trains" of multiple email systems, some of which use Postfix. So I'm an engineer, I guess. And so are you, since you seem to have run both Postfix and Exim systems at least at the "train driver" level (and frankly, railroad engineers ARE engineers to at least the same degree as sysadmins, but most of us just don't have any idea how complex trains can be...) So it would have been easier to understand if the response had been along the lines of: "envelope-from" instead of just FROM since there are a number of Froms in the source code. Someone wrote: "Return-path is a header added by the receiving MTA (usually on final delivery) that contains the envelope sender (MAIL FROM) used by the sending system. Which is accurate, if a bit ecumenical in its nomenclature... It would definitely be helpful if everyone trying to manage mail systems read RFC5598 (https://tools.ietf.org/html/rfc5598) carefully enough and often enough to adopt its formal terminology. Dave Crocker's purpose in writing that RFC was to establish precise standard jargon and a baseline understanding of how email actually works (and is intended to work) for people who should have such an understanding. If you're running a mail server, whether you accept the label "engineer" or not, you should definitely read it.
(Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?
On 6/29/16 2:30 PM, Michael J Wise wrote: I will read up on it. Thank you for the link. Not everyone, I think, who visits this list is an engineer. In that you are mistaken. Almost everyone who subscribes to this mailing-list is an engineer. Please re-read that line. This mailing list is for people who need to configure or make changes to the configuration of a Mail Transfer Agent called Postfix. Some people here actually suggest software changes, since the author of the system is present on the list. Pretty much everyone here is an engineer. I could be wrong, but I expect that many of the folks here are NOT engineers. I happen to have an engineering background, and spend a good part of my time doing engineering work of various sorts - but that's completely incidental to running our mail system. As a one-man shop, I ALSO play sys admin, postmaster, webmaster, listmaster, janitor, chief cook & bottle washer, ad infinitum, ad nauseum. I expect, that many of the folks here are full-time sys admins - a role that does not necessarily involved (or require) an engineering background. Having said that, it seems not unreasonable for folks on this list to have a working familiarity with the standards and software associated with email processing. Managing a postfix installation (or any MTA) is not a job for amateurs. (IMHO) AND NOW I'M CURIOUS... What kinds of backgrounds and roles do people here have? Is managing a postfix installation part of your official duties, or something that you've fallen into? Miles Fidelman RFC 821 (and its successors) is documentation of the COMMANDS (verbs, if you will) used to move mail, of which one, MAIL FROM, is a way to express where an NDR should go if something goes wrong. Furthermore, at some points along the journey of a piece of mail (data, or a NOUN if you will), it will be captured and recorded in a header, most typically in the Return-Path value. But it is not guaranteed to be stored in any header at any time because it's a COMMAND to a server. RFC 822 (and its successors) is documentation of the structure of DATA (the NOUNS mentioned above) that represents an email message, which is divided up into Headers and Data. One of those headers is, "From:". And almost all of those headers are little more than comments, forgeable by anyone with the inclination to do so, and at best advisory in nature. So, to summarize: The "From:" header is a comment, and may or may not reflect reality. Typically it does, but not always. The "Return-Path" is a recognized way to capture the value of the "MAIL FROM:" command, and encode it into the headers, but it is best described as a, "Virtual Header". Some other headers inserted by arbitrary third parties are not documented in *ANY* RFC anywhere, and almost everyone completely ignores them. Such is the case with, "bounces-to". It's not a standard. Almost everything will ignore it. People who expect it to always work should be prepared for disappointment. Aloha mai Nai`a. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: (Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?
> On 6/29/16 2:30 PM, Michael J Wise wrote: > >>> I will read up on it. Thank you for the link. >>> >>> Not everyone, I think, who visits this list is an engineer. >> In that you are mistaken. >> >> Almost everyone who subscribes to this mailing-list is an engineer. >> Please re-read that line. >> >> This mailing list is for people who need to configure or make changes to >> the configuration of a Mail Transfer Agent called Postfix. >> Some people here actually suggest software changes, since the author of >> the system is present on the list. >> >> Pretty much everyone here is an engineer. > > I could be wrong, but I expect that many of the folks here are NOT > engineers. I guess it depends on one's definition of, "Engineer". It can cover a lot of ground. > Having said that, it seems not unreasonable for folks on this list to > have a working familiarity with the standards and software associated > with email processing. Managing a postfix installation (or any MTA) is > not a job for amateurs. (IMHO) In that I would completely agree, even though with respect to my use of Postfix, it probably would qualify as, "Amateur" since I don't use it for profit. But with respect to the handling of mail for ... Others ... in that, it is my profession. And I'm particularly interested in problems that other mail servers may experience with relation to certain other mail server software. > AND NOW I'M CURIOUS... What kinds of backgrounds and roles do people > here have? Is managing a postfix installation part of your official > duties, or something that you've fallen into? It used to be what I did up until 8+ years ago. Nowadays I fight spam for a certain large corporation, and keep my hand in here as one of many early warning signs of trouble. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: (Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?
On 6/29/16 3:13 PM, Michael J Wise wrote: On 6/29/16 2:30 PM, Michael J Wise wrote: I will read up on it. Thank you for the link. Not everyone, I think, who visits this list is an engineer. In that you are mistaken. Almost everyone who subscribes to this mailing-list is an engineer. Please re-read that line. This mailing list is for people who need to configure or make changes to the configuration of a Mail Transfer Agent called Postfix. Some people here actually suggest software changes, since the author of the system is present on the list. Pretty much everyone here is an engineer. I could be wrong, but I expect that many of the folks here are NOT engineers. I guess it depends on one's definition of, "Engineer". It can cover a lot of ground. Well... for purposes of discussion, let's restrict "Engineer" to mean someone who: - has a degree in an engineering or engineering related technical field - has, at one time or another, held a position that included the word "Engineer" in his/her title - actually done some engineering along the way (be it R&D or development) - with some allowance for special cases who don't meet all of the above (example: Ray Kurzweil has an MIT degree, in MUSIC - I'd certainly consider him an engineer, and then some) - on the other hand, I wouldn't consider someone with a business degree, even with an MIS concentration, to be an Engineer - even though that's a fairly common background for CIOs and MIS Directors (and maybe sys admins?), you wouldn't hire them to design system software or network gear - let's NOT include train drivers :-) Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: (Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?
> On Jun 29, 2016, at 1:06 PM, Miles Fidelman > wrote: > > AND NOW I'M CURIOUS... What kinds of backgrounds and roles do people here > have? Is managing a postfix installation part of your official duties, or > something that you've fallen into? CS degree from before the 'Net, missed the 'Net programming on toy OS's (CP/M, MSDOS, etc.), and decided to learn IP networking when I retired. Rented a domain and a T1, bought a couple servers, a router, and several pounds of O'Reilly books (and one on Postfix), installed Linux, and started typing. Downhill ever since :-) Managing Postfix is more a recreational duty that I fell into by choice. Postfix is a delightful piece of software. -- Glenn English
Re: (Off-topic: who's on the list) was: Is not honoring bounces-to violation of RFC?
> On 6/29/16 3:13 PM, Michael J Wise wrote: > >>> On 6/29/16 2:30 PM, Michael J Wise wrote: >>> > I will read up on it. Thank you for the link. > > Not everyone, I think, who visits this list is an engineer. In that you are mistaken. Almost everyone who subscribes to this mailing-list is an engineer. Please re-read that line. This mailing list is for people who need to configure or make changes to the configuration of a Mail Transfer Agent called Postfix. Some people here actually suggest software changes, since the author of the system is present on the list. Pretty much everyone here is an engineer. >>> I could be wrong, but I expect that many of the folks here are NOT >>> engineers. >> I guess it depends on one's definition of, "Engineer". >> It can cover a lot of ground. > Well... for purposes of discussion, let's restrict "Engineer" to mean > someone who: All of the following, or just a few? Many *VERY* large corporations don't require some or all of these to put, "Engineer" on your business card. This is not the case all over the planet, but in many places, like the USA, it most certainly is. One has to have a global perspective on such issues. > - has a degree in an engineering or engineering related technical field > - has, at one time or another, held a position that included the word > "Engineer" in his/her title > - actually done some engineering along the way (be it R&D or development) > - with some allowance for special cases who don't meet all of the above > (example: Ray Kurzweil has an MIT degree, in MUSIC - I'd certainly > consider him an engineer, and then some) > - on the other hand, I wouldn't consider someone with a business degree, > even with an MIS concentration, to be an Engineer - even though that's a > fairly common background for CIOs and MIS Directors (and maybe sys > admins?), you wouldn't hire them to design system software or network gear It's a lot looser a definition in many places. For the purposes of this list and similar, I'd define "Engineer" to also include someone reasonably competent enough to make changes to the Postfix config files and not break stuff irreparably. It would for all intents and purposes be equivalent to SysAdmin. Or BOFH. Someone who, for example, can telnet to port 25 and get the mail delivered. > - let's NOT include train drivers :-) Let's not. But this is grossly off-topic for the list, so I won't have anything further to say on the issue. Feel free to declare victory and move on. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
