[Dovecot] RFE: please add Return-Path: to sieve sent mail headers
May I ask to add Return-Path: some meaningful header line to sieve sent mail headers in vacation message? Now the header line isn't generated at all and the effect is as follows:
on receiving MTA:
2014-05-09T15:04:32+02:00 host/ip postfix/qmgr[2408]: 41F2F6024E: from=<>, size=900, nrcpt=1 (queue active)
in received mail body:
Return-Path: <>
Would be nice to get:
Return-Path: <user@domain>
Copy of From: header line could be sufficient.
Thanks.
MU
On 5/13/2014 1:58 PM, Maciej Uhlig <maciej.uhlig@us.edu.pl> wrote:
Return-Path: <>
Would be nice to get:
Return-Path: <user@domain>
No, no, no, null sender is *required* for these kinds of messages.
--
Best regards,
Charles
Am 13.05.2014 20:27, schrieb Maciej Uhlig:
Charles Marcus - 2014-05-13 20:20:
No, no, no, null sender is *required* for these kinds of messages.
Why? It's _my_ message after all. IMHO I'm sending "I'm on vacation", not MTA.
you are *not sending* "I'm on vacation" because you as human would not be that dumb to send it 1000000 times to the vacation responsder on the other end
http://en.wikipedia.org/wiki/Bounce_message a vaction is *exactly* the same
you need to understand mail basics like the difference of the From-header and the envelope sender
hint: you are talking about the envelope which no human person ever get displayed in his MUA
Does not make sense vacation msgs is seldom sent to known users where you like to get another msg back asking when you come home again, this why its best to keep sender envelope empty on vaction msgs
Sendt fra min Android telefon med K-9 Mail. Undskyld hvis jeg er lidt kortfattet.
Am 13.05.2014 19:58, schrieb Maciej Uhlig:
May I ask to add Return-Path: some meaningful header line to sieve sent mail headers in vacation message? Now the header line isn't generated at all and the effect is as follows:
on receiving MTA:
2014-05-09T15:04:32+02:00 host/ip postfix/qmgr[2408]: 41F2F6024E: from=<>, size=900, nrcpt=1 (queue active)
in received mail body:
Return-Path: <>
which is correct
Would be nice to get:
Return-Path: <user@domain>
Copy of From: header line could be sufficient
which is completly insane in case you don't log every single vacation and stop after the first one to the same address
guess what happens if two persons have a vacation resonder at the same time and one of them sends a mail - the faster server with more storage will win that battle
may i ask to read some RFC's and consider the impact of sloppy proposals if one would make them real?
Reindl Harald - 2014-05-13 21:00:
guess what happens if two persons have a vacation resonder at the same time and one of them sends a mail - the faster server with more storage will win that battle
Not necessarily. 'sieve_vacation_default_period' would be taken into account.
may i ask to read some RFC's and consider the impact of sloppy proposals if one would make them real?
Sure.
Thanks.
MU
On 5/13/2014 7:58 PM, Maciej Uhlig wrote:
May I ask to add Return-Path: some meaningful header line to sieve sent mail headers in vacation message? Now the header line isn't generated at all and the effect is as follows:
on receiving MTA:
2014-05-09T15:04:32+02:00 host/ip postfix/qmgr[2408]: 41F2F6024E: from=<>, size=900, nrcpt=1 (queue active)
in received mail body:
Return-Path: <>
Would be nice to get:
Return-Path: <user@domain>
Copy of From: header line could be sufficient.
Use of NULL envelope sender is generally recommended to prevent mail loops:
http://tools.ietf.org/html/rfc5230#section-5.1 http://tools.ietf.org/html/rfc3834#section-3.3
Keep in mind that the From: header is set to something useful (http://tools.ietf.org/html/rfc5230#section-5.4). That is what the recipient will normally see.
If you know what you are doing (think twice about that!), you can override this behavior using the sieve_vacation_send_from_recipient setting (if your Pigeonhole is recent enough):
http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Vacation#Configuration
Regards,
Stephan.
Stephan Bosch - 2014-05-13 21:02:
Keep in mind that the From: header is set to something useful (http://tools.ietf.org/html/rfc5230#section-5.4). That is what the recipient will normally see.
Right. I was looking from the mail admin point of view (there was only "from=<>" in receiving MTA log line while I wanted to be sure who was the message from).
If you know what you are doing (think twice about that!),
I'll do :-)
you can override this behavior using the sieve_vacation_send_from_recipient setting
Thank you. That's what I was asking for.
Best regards,
MU
On 5/13/2014 3:02 PM, Stephan Bosch <stephan@rename-it.nl> wrote:
If you know what you are doing (think twice about that!), you can override this behavior using the sieve_vacation_send_from_recipient setting (if your Pigeonhole is recent enough): http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Vacation#Configuration Regards, Stephan.
Just be sure you understand why...
I recommend you read the pertinent RFC which explains the reasoning as to why the null sender is recommended, and if you are going to use another/real address, only use one that will never auto-respond to *anything*:
http://tools.ietf.org/html/rfc3834#section-3.3
Specifically:
The primary purpose of the MAIL FROM address is to serve as the
destination for delivery status messages and other automatic
responses. Since in most cases it is not appropriate to respond to
an automatic response, and the responder is not interested in
delivery status messages, a MAIL FROM address of <> MAY be used for
this purpose. A MAIL FROM address which is specifically chosen for
the purpose of sending automatic responses, and which will not
automatically respond to any message sent to it, MAY be used instead
of <>.--
Best regards,
Charles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 14 May 2014, Charles Marcus wrote:
On 5/13/2014 3:02 PM, Stephan Bosch <stephan@rename-it.nl> wrote:
If you know what you are doing (think twice about that!), you can override this behavior using the sieve_vacation_send_from_recipient setting (if your Pigeonhole is recent enough): http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Vacation#Configuration Regards, Stephan.
Just be sure you understand why...
I recommend you read the pertinent RFC which explains the reasoning as to why the null sender is recommended, and if you are going to use another/real address, only use one that will never auto-respond to *anything*:
Yep, those using different <> null senders should be aware, that there envelope sender rewritings, such as BATV and SRS0, that make the address unique each time by adding hashed timestamps or something like that. Those rewritings undermine the vacation database. I hope that those implementations generate an unique address per day and not per message. :-)
http://tools.ietf.org/html/rfc3834#section-3.3
Specifically:
The primary purpose of the MAIL FROM address is to serve as the destination for delivery status messages and other automatic responses. Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of <> MAY be used for this purpose. A MAIL FROM address which is specifically chosen for the purpose of sending automatic responses, and which will not automatically respond to any message sent to it, MAY be used instead of <>.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU3OBT3z1H7kL/d9rAQKGhggAxXOPt5UGUeSiZk/mc+2CvcKkmO5oIrDD Z/mTligp6LOzJC3WnkXgra+mBwBlr/6WBE0Qze/7/z6arbG/3kQLaRhGexLJ630J Z/f1uDNh6ntziw5yiix9QiW241UaDf9kVWrhKjPSchiLMF8GS874jSW7Ox/siMOu +QcFIiTGXeFdUmqNb6F0rDKJLdGShLULh+EfOh26JRMkPiPpdzWXdgIHA8xqB5iN pvD23uB/Hm+gSrj6hwFZjGBI0jxqyIdo3prtqO7Iw6zs7dvvGR45GmVAiVe1KsSl mDNmxXpTtLPO4g3AlgVg98VinTC8BGACStS5zQvvhnwHjqd/0CgtQA== =e7tc -----END PGP SIGNATURE-----
On 5/14/2014 10:44 AM, Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:
Yep, those using different <> null senders should be aware, that there envelope sender rewritings, such as BATV and SRS0, that make the address unique each time by adding hashed timestamps or something like that. Those rewritings undermine the vacation database. I hope that those implementations generate an unique address per day and not per message.
Best would be if there was a way to code sieve such that it could ignore the BATV/SRS0 junk, as well as plussed addresses...
Is there enough rhyme/reason to these schemes that would make that feasible?
--
Best regards,
Charles
Am 14.05.2014 16:56, schrieb Charles Marcus:
On 5/14/2014 10:44 AM, Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:
Yep, those using different <> null senders should be aware, that there envelope sender rewritings, such as BATV and SRS0, that make the address unique each time by adding hashed timestamps or something like that. Those rewritings undermine the vacation database. I hope that those implementations generate an unique address per day and not per message.
Best would be if there was a way to code sieve such that it could ignore the BATV/SRS0 junk, as well as plussed addresses...
wrong way - there are standards for not-to-repsond messages
- null sender
- Precedence: bulk
- Precedence: list
- Auto-Submitted: auto-generated
these are typically ignored
there is really no reason to code around because someone insists on rejecting all warnings and pretending that he knows what he is doing by add a Return-Path to auto-repsonders
no, he does *not* know what he is doing and i even go so far to say it's missing competence for mailserver administration
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path and even reply works from a mail-client
only other responders and mailing-lists are acting with the Return-Path and they all know how to handle a null-sender
Reindl Harald - 2014-05-14 17:04:
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path
I'm actually looking at your mail using the newest Thunderbird and guess what I see? I see your mistake:
Return-Path: <dovecot-bounces@dovecot.org>
Thanks.
MU
On 5/14/2014 12:29 PM, Maciej Uhlig <maciej.uhlig@us.edu.pl> wrote:
Reindl Harald - 2014-05-14 17:04:
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path I'm actually looking at your mail using the newest Thunderbird and guess what I see? I see your mistake:
Return-Path: <dovecot-bounces@dovecot.org>
??? He didn't say you couldn't see the return path, he said that the mail client (I'll append 'usually') only shows the From header.
--
Best regards,
Charles
Charles Marcus - 2014-05-14 19:26:
On 5/14/2014 12:29 PM, Maciej Uhlig <maciej.uhlig@us.edu.pl> wrote:
Reindl Harald - 2014-05-14 17:04:
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path I'm actually looking at your mail using the newest Thunderbird and guess what I see? I see your mistake:
Return-Path: <dovecot-bounces@dovecot.org>
??? He didn't say you couldn't see the return path, he said that the mail client (I'll append 'usually') only shows the From header.
He said the mail client doesn't show the Return-Path and I said it's not true because Thunderbird shows not only the From header line but also it _does_ show Return-Path line. This is simple logic coming from everyday observation.
Thanks.
MU
On -10.01.-28163 20:59, Maciej Uhlig wrote:
Charles Marcus - 2014-05-14 19:26:
On 5/14/2014 12:29 PM, Maciej Uhlig <maciej.uhlig@us.edu.pl> wrote:
Reindl Harald - 2014-05-14 17:04:
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path
He said the mail client doesn't show the Return-Path and I said it's not true because Thunderbird shows not only the From header line but also it _does_ show Return-Path line. This is simple logic coming from everyday observation.
Allow me to both correct Haralds sentence, and provide you with a suitably picky answer to your initial question ("May I ask to add Return-Path: some meaningful header line"):
a) MUAs will use the Header-From: (and a variety of other headers, like Reply-To: or, if "Reply to all", To: and Cc:) to determine the address(es) to send replies to, not the Envelope-From_ like automated processing should.
b) Your (sender-side) software CANNOT generate a Return-Path: header, because it is generated (if at all, as that functionality is optional) upon final delivery on the receiver's side (MDA).
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
On 5/14/2014 1:49 PM, Maciej Uhlig <maciej.uhlig@us.edu.pl> wrote:
He said the mail client doesn't show the Return-Path and I said it's not true because Thunderbird shows not only the From header line but also it _does_ show Return-Path line.
It shows the return path buried deep in the headers, yes, but virtually every email client I've ever used (Thunderbird included) will not show that header unless you tell it to, all you'll ever see is the From header.
Are you done picking nits?
--
Best regards,
Charles
Am 14.05.2014 18:29, schrieb Maciej Uhlig:
Reindl Harald - 2014-05-14 17:04:
the mail cient on the receiver shows the FROM-HEADER and not the Return-Path
I'm actually looking at your mail using the newest Thunderbird and guess what I see? I see your mistake:
Return-Path: <dovecot-bounces@dovecot.org>
not in a default setup no MUA i ever seen shows that in a default setup thunderbird-24.5.0-1.fc20.x86_64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 14 May 2014, Reindl Harald wrote:
Am 14.05.2014 16:56, schrieb Charles Marcus:
On 5/14/2014 10:44 AM, Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:
Yep, those using different <> null senders should be aware, that there envelope sender rewritings, such as BATV and SRS0, that make the address unique each time by adding hashed timestamps or something like that. Those rewritings undermine the vacation database. I hope that those implementations generate an unique address per day and not per message.
Best would be if there was a way to code sieve such that it could ignore the BATV/SRS0 junk, as well as plussed addresses...
wrong way - there are standards for not-to-repsond messages
- null sender
- Precedence: bulk
- Precedence: list
- Auto-Submitted: auto-generated
these are typically ignored
Then there are standards, implemented by one big software creator:
http://msdn.microsoft.com/en-us/library/ee219609%28v=EXCHG.80%29.aspx
I've seen messages with X-Auto-Response-Suppress only, but neither Auto-Submitted nor Precedence.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU3SJSXz1H7kL/d9rAQLAKAf/ZqaOLNEejUcG9nXXY1D7JHCZSmL/R/Ux ygy7L31PBQ5DdxniS6yJvuDyRkL+aum0yFy0GlusOgJhG331s+frw7tMHPZLPPru LqDRGVlJN54ot71f6gDPixJo42WrAt9tKAhXm6ySon3S32+rp2Z2GKGQ18aQ7TR9 B+2F+asHsyNIM5TiJvOkOxagmfI3sKdfE4hEr2O4uaSixGMOYqSVovQr4swFedSR mFRhfkEszTbpDMEegbaLBpMZ9UTAPNggzkq4LYjVE2qISrTiHE0uTIEXiw+2gKPL PYanoP4gnAbgrXkP5eNSB44FphotLNMf/0Ebz2Ea25SPQAOJ2o/MTQ== =I82K -----END PGP SIGNATURE-----
On 05/13/14 03:02 PM, Stephan Bosch wrote:
Use of NULL envelope sender is generally recommended to prevent mail loops
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited) :
... while talking to antispam1.*.ca.:
DATA <<< 550 Empty envelope senders not allowed
... while talking to smtp.*.net.:
MAIL From:<> SIZE=1096 <<< 550 5.1.0 <> Blank From: addresses are not allowed. Please provide a valid From: IB501 <http://x.co/srbounce>
... while talking to spam.*.edu.cn.:
DATA <<< 553 Requested action not taken: NULL sender is not allowed
... while talking to mail.*.co.kr.:
MAIL From:<> <<< 501 bad sender address expression.
... while talking to antispam.*.com.:
MAIL From:<> <<< 501 Syntax error in address
Am 16.05.2014 21:03, schrieb Oscar del Rio:
On 05/13/14 03:02 PM, Stephan Bosch wrote:
Use of NULL envelope sender is generally recommended to prevent mail loops
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited) :
... while talking to antispam1.*.ca.:
DATA <<< 550 Empty envelope senders not allowed
... while talking to smtp.*.net.:
MAIL From:<> SIZE=1096 <<< 550 5.1.0 <> Blank From: addresses are not allowed. Please provide a valid From: IB501 <http://x.co/srbounce>
... while talking to spam.*.edu.cn.:
DATA <<< 553 Requested action not taken: NULL sender is not allowed
... while talking to mail.*.co.kr.:
MAIL From:<> <<< 501 bad sender address expression.
... while talking to antispam.*.com.:
MAIL From:<> <<< 501 Syntax error in address
you will find any kind of bad config in www if you search for it
http://www.postfix.org/postconf.5.html
... Beware, some sites reject mail from <>, even though RFCs require that such addresses be accepted. ...
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Quoting Oscar del Rio <delrio@mie.utoronto.ca>:
On 05/13/14 03:02 PM, Stephan Bosch wrote:
Use of NULL envelope sender is generally recommended to prevent mail loops
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited) :
Any domain hosted by RackSpace will reject a NULL sender for 'backscatter'.
Bascially, 'backscatter' blockers assume all edge SMTP servers will have complete knowledge of the final delivery status - during the SMTP conversation - thus labeling all NULL senders as forged spam redirected to them via a bounce message.
Rick
Am 16.05.2014 21:24, schrieb Rick Romero:
Quoting Oscar del Rio <delrio@mie.utoronto.ca>:
On 05/13/14 03:02 PM, Stephan Bosch wrote:
Use of NULL envelope sender is generally recommended to prevent mail loops
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited) :
Any domain hosted by RackSpace will reject a NULL sender for 'backscatter'.
Bascially, 'backscatter' blockers assume all edge SMTP servers will have complete knowledge of the final delivery status - during the SMTP conversation - thus labeling all NULL senders as forged spam redirected to them via a bounce message.
this use of this rbl is widly broken, dont do it, unless you have fully understand what you do
Rick
however if you want to change Return-Path
use
http://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Extprograms
http://hg.rename-it.nl/pigeonhole-0.3-sieve-extprograms/raw-file/tip/doc/rfc...
with procmail/formail
this also might give you the chance to prefilter only do changes to broken mail domain setups
you might also write some milter/policy server for submission host etc and/or poke around with some SRS Solution
dont expect coders focus to broken setups
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Am 16.05.2014 21:03, schrieb Oscar del Rio:
On 05/13/14 03:02 PM, Stephan Bosch wrote:
Use of NULL envelope sender is generally recommended to prevent mail loops
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited)
*that* are not compliant mailservers - period
they also break sender verification and what not else
On 5/16/2014 3:03 PM, Oscar del Rio <delrio@mie.utoronto.ca> wrote:
Unfortunately, many servers out there reject emails with NULL sender.
Unfortunately, there are many clueless mail admins and/or badly/mis configured mail servers out there.
The reality is that the RFCs mandate that the null sender envelope address is one that must be accepted, as there are many tthings smtp that depend on it.
That said, I really don't care if their server rejects our user occasional vacation message or not, so it isn't something I even care about knowing about, other than to tell a user that the reason their valuable vacation response wasn't received by their VIP customer is because their VIP customers genius mail admin decided that they didn't want to receive any of those kinds of emails, so go complain to them if they want to complain to someone.
Best regards,
Charles
On 5/17/2014 6:14 AM, Charles Marcus wrote: ...
The reality is that the RFCs mandate that the null sender envelope address is one that must be accepted, as there are many things smtp that depend on it. ...
Spammers tried to take advantage of null sender handling en masse many years ago and had little success with it. Receivers rejected the messages by standard anti-spam mechanisms such as non existent PTR, dnsbls, content filters, etc. And in fact some spammers still try to use null sender today. Recent examples from Chinese IP space sending spam to messages IDs scraped from mailing list archives, clearly a spam bot infected PC:
Apr 29 22:32:52 greer postfix/smtpd[4968]: NOQUEUE: reject: RCPT from unknown[14.148.130.120]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [14.148.130.120]; from=<> to=<4D18F665.6090709@hardwarefreak.com> proto=ESMTP helo=<a01> Apr 29 22:32:52 greer postfix/smtpd[4967]: NOQUEUE: reject: RCPT from unknown[14.148.130.120]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [14.148.130.120]; from=<> to=<4D18F04D.3040604@hardwarefreak.com> proto=ESMTP helo=<a01>
Check your mail logs and you'll likely find such rejections of null sender as well.
Certainly one should never reject mail based on the presence of the null sender address, but by no means should anyone have a blanket accept policy based on the mere existence of the null sender address, regardless of what the relevant SMTP RFCs might say on the matter. That would simply result in more spam in inboxen and/or more load on one's content filters.
Cheers,
Stan
Am 18.05.2014 00:22, schrieb Stan Hoeppner:
On 5/17/2014 6:14 AM, Charles Marcus wrote: ...
The reality is that the RFCs mandate that the null sender envelope address is one that must be accepted, as there are many things smtp that depend on it. ...
Spammers tried to take advantage of null sender handling en masse many years ago and had little success with it. Receivers rejected the messages by standard anti-spam mechanisms such as non existent PTR, dnsbls, content filters, etc. And in fact some spammers still try to use null sender today. Recent examples from Chinese IP space sending spam to messages IDs scraped from mailing list archives, clearly a spam bot infected PC:
Apr 29 22:32:52 greer postfix/smtpd[4968]: NOQUEUE: reject: RCPT from unknown[14.148.130.120]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [14.148.130.120]; from=<> to=<4D18F665.6090709@hardwarefreak.com> proto=ESMTP helo=<a01> Apr 29 22:32:52 greer postfix/smtpd[4967]: NOQUEUE: reject: RCPT from unknown[14.148.130.120]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [14.148.130.120]; from=<> to=<4D18F04D.3040604@hardwarefreak.com> proto=ESMTP helo=<a01>
Check your mail logs and you'll likely find such rejections of null sender as well.
Certainly one should never reject mail based on the presence of the null sender address, but by no means should anyone have a blanket accept policy based on the mere existence of the null sender address
nobody said that - even not what you quoted above
it only says you must not reject all messages based on the fact there is a null-sender in use and that is why using anything else than a null-sender for autoreplies and try to excuse that by clueless fools blocking all null-senders is only silly
On -10.01.-28163 20:59, Oscar del Rio wrote:
Unfortunately, many servers out there reject emails with NULL sender. Some recent examples (real server names edited) :
*Sigh* A mere two years ago, I would've known *the* place for you to put that data ...
https://web.archive.org/web/20120717010658/http://rfc-ignorant.org/policy-ds...
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
participants (11)
-
Benny Pedersen
-
Charles Marcus
-
Jochen Bern
-
Maciej Uhlig
-
Oscar del Rio
-
Reindl Harald
-
Rick Romero
-
Robert Schetterer
-
Stan Hoeppner
-
Steffen Kaiser
-
Stephan Bosch