subject:"Moderated posts\?"

On 10/15/2014 3:13 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:
 Tanstaafl wrote:
 1. email to invalid recipients should be rejected at the RCPT-TO stage,

 Easier said then done - at least when a server does relaying, but 
 clearly ideal when possible.

No, it is 100% easily done.

For servers under your control, you just do it. If you don't know how
and are unwilling or unable to learn how, then you have no business
running a mail server.

For servers not under your direct control, but for whom your server is
the official relay for final delivery (which means you need the current
list o valid recipients), you either require them to allow you to
perform recipient verification, or to provide you with a constantly up
to date list of valid recpients, or you don't act as their relay.

snip

 Generally agree with you in principle.  And that's certainly the 
 standards-compliant policy.
 
 In practice I support a few dozen mailing lists - operational 
 necessity dictates dropping a lot of stuff silently.

Lists are different, and definitely fall into the category of 'best
effort, but no promises'...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543f9df8.3080...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

Please do not send to me directly, I am on the list.

On 10/15/2014 3:15 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/15/2014 12:40 PM, Tanstaafl wrote:
 Easy enough to prove. By all means, quote the actual text of me saying
 this was 'OK'...

 You said:
 
 However, once a message has been accepted - ie, *after* the DATA phase
 is complete, it should never be bounced, it should be delivered - or,
 worse, quarantined, or worst case, deleted (ie, if it is later found to
 contain a malicious payload).

And nowhere do you see the word 'OK'. As I said, please do NOT put words
in my mouth.

 It is either OK to delete an email or it is not.  You can't have it both
 ways.  If, as according to your other statements, it is not OK to delete
 emails, then you are violating your own rules by deleting mails - for
 ANY reason.

If you are unable to see the difference between a rare, extreme worst
case scenario of having discovered an email that you accepted for
delivery contains a malicious payload, and deleting an email for no
other reason than the recipient has a typo in it, then you have no
business running a mail server.

 Your reason is i.e. if it is later found to contain a malicious
 payload.  My reason is It is addressed to a non-existent user.
 Either both are OK or neither is OK.

So, you obviously have no business running a mail server.

 you keep saying that the RECEIVING server 'sends a message back to
 the originator' - unless maybe you simply have a hard time saying
 what you really mean, which always causes confusion.

 it does send a message back to the originator - it may only be a
 status code, but it is still a message.

 The status code is not *sent* anywhere - it is a response directly to
 the connecting machine.

 Then how does it get back to the sending server?  Magic?

Can you not read? The CONNECTING MACHINE - the one that was directly
talking to YOUR server - is responmsible for that part of the
transaction. Spambots DO NOT DO THIS.

 It is then the responsibility of that machine that was talking to your
 server to pass the response code back to the originating *server* (not
 the sender of the email - there is a difference).

 I didn't say the sender of the email.

Maybe not, but I have no desire to go back through this thread to see
whether you ever did or not. You are apparently incapable of
communicating with semantic precision, so this time I'm really done.

Respond if you like, I won't see it.

 And you still can't quote an RFC which indicates what I am doing breaks
 SMTP.  That's because there isn't one and I am NOT breaking SMTP.

As I said, there is no rule that says that you have to violate an RFC to
break SMTP.

Accepting invalid recipients then silently deleting them breaks SMTP for
the vast majority of internet email users.

You are free to break it all you want... on your server.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543f9ffc.6030...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 4:44 PM, Joe j...@jretrading.com wrote:
 However, if the Reply-To: is forged, i.e. if it is spam, the
 alternative is considerably less OK. Bouncing a spam message simply
 delivers *the* *entire* *message* to an innocent third party, having
 been laundered through your (presumably legitimate and respectable) mail
 server.
 
 So it isn't OK, but there's no alternative to doing it. That's how you
 have it both ways.

Spam doesn't have to be deleted, it can be quarantined. That is the best
way to handle spam once it has been accepted.

I don't even delete the malicious stuff, although I don't deliver it to
the recipient.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fa10c.6010...@libertytrek.org

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 4:58 PM, Joe j...@jretrading.com wrote:
 It's worth some effort, at the moment it is the single most effective
 anti-spam measure. If you outsource your mail, it's worth going to some
 trouble to find a hosting company who will hold and accept updates for
 a list of valid recipients.

Or even easier, just get them to agree to let you perform recipient
verification in realtime.

 if it is spam, there's nobody to tell, and you don't want to send a
 copy of the spam to the forged Reply-To: address.

Of course not - which is why you REJECT it instead of ACCEPT+BOUNCE..

 3. once an email has been accepted for final delivery, every effort
 should be taken to deliver the message to the recipient, whether to
 their Inbox clean or tagged as spam (if a spam threshhold is met),
 or to a spam quarantine,

 Which shouldn't be a problem if there's a valid recipient.

Well, since everything I'm talking about is not accepting mail for
invalid recipients, not sure why you felt the need to say that.

 Yes, and a log kept.

Anyone who runs a mail server and doesn't keep logs shouldn't be running
a mail server.

 *And* the postmaster address monitored,

Anyone who runs a mail server and doesn't monitor the postmaster address
shouldn't be running a mail server.

 and a request to know the disposition of a vanished email should be 
 answered, along with the reason. Especially if the request is 
 accompanied by one of your message IDs...

Absolutely...

 Of course. Already-accepted spam *must* be silently dropped.

Absolutely NOT!

It should be *delivered*, either tagged as spam to the Inbox, or to a
quarantine, but it should be delivered. I only allow tagged delivery for
more sophisticated users. Normal users have to check their quarantine.

The only exception on my system is anything with a verified malicious
payload, which is delivered to an admin mailbox, not to the intended
recipient/victim.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fa2d9.1080...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 5:12 PM, Brad Rogers b...@fineby.me.uk wrote:
 Send an email with a large attachment(1) and there are quite a few
 servers that will silently drop it.

Anyone who does that is breaking SMTP. If you don't want messages over a
certain size, REJECT them, but absolutely do not EVER accept then
silently delete them, that is just plain stupid.

 The worst of it is you can never know for certain if you're going to
 get bitten because routing can vary.

It isn't about routing problems, it is about properly configuring your
toolset.

 (1) 4Meg or so used to do the trick.  Things might be different now as
 more and more messages contain massive amounts of HTML and imagery.

Google accepts 25MB+, as does Outlook.com and most other freemailers
now. That is our limit here too.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fa3d1.9030...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 8:37 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 Tanstaafl couldn't answer it, and you can't either, because it's not
 violating any.

I did answer it, you just ignored it or don't understand it.

Quote:

You do not have to violate an RFC to break SMTP.

Here is a real world example:

Improperly configured TCP filtering features on firewalls and routers
don't violate any specific RFC, but they certainly can break SMTP (and
other things too).


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fa4cd.8010...@libertytrek.org

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Chris Bannister

On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote:
 
 Anyone who runs a mail server and doesn't keep logs shouldn't be running
 a mail server.
 
  *And* the postmaster address monitored,
 
 Anyone who runs a mail server and doesn't monitor the postmaster address
 shouldn't be running a mail server.

Tell that to yahoo, they *don't seem* to have a postmaster address nor an
abuse address. :(

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016113134.GB9534@tal

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Joel Rees

On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl tansta...@libertytrek.org wrote:
 On 10/15/2014 8:37 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 Tanstaafl couldn't answer it, and you can't either, because it's not
 violating any.

 I did answer it, you just ignored it or don't understand it.

 Quote:

 You do not have to violate an RFC to break SMTP.

 Here is a real world example:

 Improperly configured TCP filtering features on firewalls and routers
 don't violate any specific RFC, but they certainly can break SMTP (and
 other things too).

Thus, we can understand that you are an idealist that would rather see
your version of SMTP rules be followed by everyone than try to follow
the RFC yourself.

Where are your SMTP rules spelled out, by the way?

-- 
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iMhgnbTZiDfiG=yyV8cC5O+=-pttkhdaxemzqub6x3...@mail.gmail.com

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Brad Rogers

On Thu, 16 Oct 2014 06:54:09 -0400
Tanstaafl tansta...@libertytrek.org wrote:

Hello Tanstaafl,

On 10/15/2014 5:12 PM, Brad Rogers b...@fineby.me.uk wrote:
 Send an email with a large attachment(1) and there are quite a few
 servers that will silently drop it.  
Anyone who does that is breaking SMTP. If you don't want messages over 

Yes, that's the point.

certain size, REJECT them, but absolutely do not EVER accept then
silently delete them, that is just plain stupid.

Oh I agree, wholeheartedly.  As I said in my reply to Joe, I suspect
it's part of a misguided anti-malware program.

 The worst of it is you can never know for certain if you're going to
 get bitten because routing can vary.  
It isn't about routing problems, it is about properly configuring your
toolset.

What I meant was that, since at any given time a route from A-B can vary
due to, for example a server being down, you can't be sure which route
the mail will take and therefore, which server(s) it'll pass through and
what their reject/drop rules are.  So, not routing per se, but
unpredictable consequences of passing through certain servers.

 (1) 4Meg or so used to do the trick.  Things might be different now s
Google accepts 25MB+, as does Outlook.com and most other freemailers
now. That is our limit here too.

Things are much better than I hoped then.  I'll keep that in mind for
future use.  Thanks.

-- 
 Regards  _
 / )   The blindingly obvious is
/ _)radnever immediately apparent
I must be hallucinating, watching angels celebrating
There Must Be An Angel (Playing With My Heart) - Eurythmics


pgpXoM5d0tsJX.pgp
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-16 Thread Miles Fidelman


Ansgar Burchardt wrote:

Steve Litt sl...@troubleshooters.com writes:

Ansgar Burchardt ans...@debian.org wrote:

Steve Litt sl...@troubleshooters.com writes:

OK, I'll be the first to admit that after Red Hat caused the demise
of ConsoleKit (and probably lots more important software), I am
free to take significant time out of my day job (that feeds my
family) and rescue all sorts of software that Red Hat deliberately
scuttled. Even though, apparently unlike 80% of today's kernel
developers, nobody pays me to do it.

You are free to do so in your free time. It would be a more
constructive use than trying to annoy other people (who spend their
free time on Linux) until they do so for you for free.

So, reading between the lines, you find my saying don't break Linux
annoying.

No, what I find annoying is telling volunteer what they have to do
without doing anything yourself on the issues you raise and repeating
don't break Linux endlessly. I think everybody knows by now you
believe that, there's no (constructive) use in further repeating it.



So, by your logic, if a horde of volunteers blow into town after a 
crisis - then proceed to muck things up, all in the name of helping - 
nobody has a right to complain?


And, it's worth noting that, given how many people working on Linux (and 
other open source projects) are paid by their employers to do so, this 
is not about the actions of volunteers.


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543fb518.8050...@meetinghouse.net

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Jonathan Dowland

Guys -

Please take this off-list. Things have gone way, way past the point where
this is of an interest or relevance to anyone else on this list.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016121446.ga20...@chew.redmars.org

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Scott Ferguson

On 16/10/14 22:31, Chris Bannister wrote:
 On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote:

 Anyone who runs a mail server and doesn't keep logs shouldn't be running
 a mail server.

  *And* the postmaster address monitored,

 Anyone who runs a mail server and doesn't monitor the postmaster address
 shouldn't be running a mail server.
 
 Tell that to yahoo, they *don't seem* to have a postmaster address nor an
 abuse address. :(
 

ab...@yahoo-inc.com
domainad...@yahoo-inc.com
abuse-cen...@yahoo-inc.com
mail-ab...@yahoo-inc.com
domain.t...@yahoo-inc.com

NOTE: I haven't tried them, but they're valid email addresses (don't ask).

If you are having problems lately (last six months) it's likely that you
haven't deployed SPF and DKIM - contentious issues for, um, the more
conservative mail admin. I like SPF and DKIM - guess I'm not that
conservative. Increasingly you'll find you'll need it - more of us, less
conservative mail admin are deploying it and slowly switching to dumping
mail that doesn't. Without SPF  DKIM it's usually trivial to spoof a
sender, one day spammers might work that out.

SMTP Error codes:-
https://help.yahoo.com/kb/postmaster/smtp-error-codes-sln23996.html?impressions=true

You'll find other related links on the same page.


Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fa87b.5060...@gmail.com

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

On 10/16/2014 7:31 AM, Chris Bannister cbannis...@slingshot.co.nz wrote:
 On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote:
 Anyone who runs a mail server and doesn't monitor the postmaster address
 shouldn't be running a mail server.

 Tell that to yahoo, they *don't seem* to have a postmaster address nor an
 abuse address. :(

Then they shouldn't be running a mail server... ;)

And they are in violation of the RFC that mandates that these two
addresses always be available and monitored.

But I'm sure they couldn't care less... ;)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fb99b.1080...@libertytrek.org

Re: piece of mind (Re: Moderated posts?)

2014-10-16 Thread Ansgar Burchardt

On 10/16/2014 14:07, Miles Fidelman wrote:
 Ansgar Burchardt wrote:
 No, what I find annoying is telling volunteer what they have to do
 without doing anything yourself on the issues you raise and repeating
 don't break Linux endlessly. I think everybody knows by now you
 believe that, there's no (constructive) use in further repeating it.
 
 So, by your logic, if a horde of volunteers blow into town after a
 crisis - then proceed to muck things up, all in the name of helping -
 nobody has a right to complain?

No, I'm complaining exactly about that: there's a nice town and some
guests have decided to rampage through town because they don't like what
the people building the town do. The guests also use megaphones during
the night hours when people would like to sleep to point out how wrong
the people building the town are.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fba93.8090...@debian.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/16/2014 7:40 AM, Joel Rees joel.r...@gmail.com wrote:
 On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl tansta...@libertytrek.org wrote:
  On 10/15/2014 8:37 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
  Tanstaafl couldn't answer it, and you can't either, because it's not
  violating any.
 
  I did answer it, you just ignored it or don't understand it.
 
  Quote:
 
  You do not have to violate an RFC to break SMTP.
 
  Here is a real world example:
 
  Improperly configured TCP filtering features on firewalls and routers
  don't violate any specific RFC, but they certainly can break SMTP (and
  other things too).
 Thus, we can understand that you are an idealist that would rather see
 your version of SMTP rules be followed by everyone than try to follow
 the RFC yourself.
 
 Where are your SMTP rules spelled out, by the way?

Ok, I just went and looked it up, and lo and behold...

RFC 2821 is the controlling RFC if I'm not mistaken...

https://tools.ietf.org/html/rfc2821

In there you'll find this:

   The second step in the procedure is the RCPT command.

  RCPT TO:forward-path [ SP rcpt-parameters ] CRLF

   The first or only argument to this command includes a forward-path
   (normally a mailbox and domain, always surrounded by  and 
   brackets) identifying one recipient.  If accepted, the SMTP server
   returns a 250 OK reply and stores the forward-path.  If the recipient
   is known not to be a deliverable address, the SMTP server returns a
   550 reply, typically with a string such as no such user -  and the
   mailbox name (other circumstances and reply codes are possible).
   This step of the procedure can be repeated any number of times.

So, how do you 'interpret' the pertinent part:

If the recipient is known not to be a deliverable address, the SMTP
server returns a 550 reply, typically with a string such as no such
user -  and the mailbox name (other circumstances and reply codes are
possible).

?

Sounds to me like a mandate to reject invalid recipients at the RCPT-TO
stage.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fbb6b.4000...@libertytrek.org

Re: piece of mind (Re: Moderated posts?)

2014-10-16 Thread Chris Bannister

On Thu, Oct 16, 2014 at 02:31:15PM +0200, Ansgar Burchardt wrote:
 On 10/16/2014 14:07, Miles Fidelman wrote:
  Ansgar Burchardt wrote:
  No, what I find annoying is telling volunteer what they have to do
  without doing anything yourself on the issues you raise and repeating
  don't break Linux endlessly. I think everybody knows by now you
  believe that, there's no (constructive) use in further repeating it.
  
  So, by your logic, if a horde of volunteers blow into town after a
  crisis - then proceed to muck things up, all in the name of helping -
  nobody has a right to complain?
 
 No, I'm complaining exactly about that: there's a nice town and some
 guests have decided to rampage through town because they don't like what
 the people building the town do. The guests also use megaphones during
 the night hours when people would like to sleep to point out how wrong
 the people building the town are.

And the people who are trying to sleep in their comfy bachelor luxury
condos get abused when they tell them to keep the noise down.

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016132414.GB11617@tal

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread The Wanderer

On 10/16/2014 at 06:37 AM, Tanstaafl wrote:

 Please do not send to me directly, I am on the list.
 
 On 10/15/2014 3:15 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 
 On 10/15/2014 12:40 PM, Tanstaafl wrote:

 The status code is not *sent* anywhere - it is a response
 directly to the connecting machine.
 
 Then how does it get back to the sending server?  Magic?
 
 Can you not read? The CONNECTING MACHINE - the one that was directly
 talking to YOUR server - is responmsible for that part of the
 transaction. Spambots DO NOT DO THIS.

I think there's a miscommunication here.

I think that what you are calling the connecting machine is the same
thing as what he is calling the sending server.

In both cases, I believe what is being referred to is the machine to
which the 'status code' will be sent.


And I believe he's trying to (implicitly and passive-aggressively) point
out is that the status code itself A: is a message, however tiny, and
B: is sent from your receiving server to the sending
server/connecting machine - and that, thus, a message is sent back.

There are so many terms in this which appear to be being defined
differently by the two sides of the discussion, it's no surprise that
there's been so little real communication here; it's almost more
surprising that there's been as much as there has.

 It is then the responsibility of that machine that was talking to
 your server to pass the response code back to the originating
 *server* (not the sender of the email - there is a difference).
 
 I didn't say the sender of the email.
 
 Maybe not, but I have no desire to go back through this thread to
 see whether you ever did or not. You are apparently incapable of
 communicating with semantic precision, so this time I'm really done.

I don't think he's incapable of it; I think he's trying to browbeat you
into accepting his terminology, by intentionally refusing to explain his
meaning rather than simply point out where you didn't match it, so that
you have to figure out for yourself what that meaning is - probably
because figuring something out for yourself tends to lead to a deeper
and more personally acceptable understanding.

Which is fine enough up to a point, but past that point becomes a form
of bad argument, and IMO we are very much past that point.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-16 Thread Joel Rees

On Thu, Oct 16, 2014 at 9:34 PM, Tanstaafl tansta...@libertytrek.org wrote:
On 10/16/2014 7:40 AM, Joel Rees joel.r...@gmail.com wrote:
On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl tansta...@libertytrek.org wrote:
On 10/15/2014 8:37 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
Tanstaafl couldn't answer it, and you can't either, because it's not
violating any.

I did answer it, you just ignored it or don't understand it.

Quote:

You do not have to violate an RFC to break SMTP.

Here is a real world example:

Improperly configured TCP filtering features on firewalls and routers
don't violate any specific RFC, but they certainly can break SMTP (and
other things too).
Thus, we can understand that you are an idealist that would rather see
your version of SMTP rules be followed by everyone than try to follow
the RFC yourself.

Where are your SMTP rules spelled out, by the way?

Ok, I just went and looked it up, and lo and behold...

RFC 2821 is the controlling RFC if I'm not mistaken...

https://tools.ietf.org/html/rfc2821

In there you'll find this:

The second step in the procedure is the RCPT command.

RCPT TO:forward-path [ SP rcpt-parameters ] CRLF

The first or only argument to this command includes a forward-path
(normally a mailbox and domain, always surrounded by and
brackets) identifying one recipient. If accepted, the SMTP server
returns a 250 OK reply and stores the forward-path. If the recipient
is known not to be a deliverable address, the SMTP server returns a
550 reply, typically with a string such as no such user - and the
mailbox name (other circumstances and reply codes are possible).
This step of the procedure can be repeated any number of times.

So, how do you 'interpret' the pertinent part:

If the recipient is known not to be a deliverable address, the SMTP
server returns a 550 reply, typically with a string such as no such
user - and the mailbox name (other circumstances and reply codes are
possible).

Sounds to me like a mandate to reject invalid recipients at the RCPT-TO
stage.

Well, I'll tell you what. Before I try to engage with you on this, I'm
going to do my part and re-read RFCs 5321, 5322, 4409, and BCP 14 and
several others referred to therein, completely, and make sure I
understand them.

I strongly encourage you to do the same.

--
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caar43ip5ymnc3zvqsvyqwo3bgabwseaf1djcxif_lmsqsou...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Andrei POPESCU

On Ma, 14 oct 14, 17:56:58, Steve Litt wrote:
 
 Because you don't want to inextricably drag a giant monolith into your
 Desktop Environment just to do a few things.

If you compare systemd with a Desktop Environment I'm not quite sure 
who's the giant ;)

 And how were they handling
 this task before systemd? It's not like Desktops, Window Managers and
 whatever things like lightdm are called didn't exist before systemd.

ConsoleKit, unmaintained.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Andrei POPESCU

On Ma, 14 oct 14, 22:56:15, The Wanderer wrote:
 
 Not to mention that just offhand I'm not sure I'd even know how to turn
 off basic tab completion - whereas turning off programmable tab
 completion is pretty much just a matter of not sourcing the
 tab-completion files in the effective bash environment, IIRC. (Though I
 always have to look up where to do it, every time I build a new system.)

Removing the package bash-completion (package name verified by courtesy 
of programmable tab completion) should do it ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Martin Read


On 14/10/14 22:56, Steve Litt wrote:

On Wed, 15 Oct 2014 00:15:40 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

As far as I understand none of the upstreams are actually requiring
systemd itself (or more accurately systemd-logind), but the
interfaces it is providing.


I fail to see the distinction.


As long as the interface is there (and works), they don't care how it's 
implemented. The interface is defined, and it certainly *looks* 
externally reimplementable.



And it also seems to make sense (why
should every Desktop Environment implement it's own solution for
this?).


Because you don't want to inextricably drag a giant monolith into your
Desktop Environment just to do a few things.


If I have seen further than other men, it is by standing on the 
shoulders of giants.


The alleged monolith does a bunch of (probably mostly neither 
interesting nor trivial) stuff for me. That means I don't have to do 
that stuff myself, and can concentrate on doing the things that are 
either interesting or trivial.


Besides, the average DE is pretty beefy itself.


And how were they handling this task before systemd?


They were using ConsoleKit, which was orphaned upstream some time after 
systemd-logind came along.



It's not like Desktops, Window Managers and whatever things like
lightdm are called didn't exist before systemd.


(For reference: things like lightdm, xdm, slim, gdm3, etc. are called 
display managers, and have been since 1988.)



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543e2b7a.50...@zen.co.uk

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:
 Well, this really is OT for debian-users, but  Turns out that SMTP 
 WAS/IS intended to be reliable.

Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).

 I'd always lumped SMTP in the category of unreliable protocols, w/o 
 guaranteed delivery

The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e4da8.2060...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/14/2014 12:03 PM, Tanstaafl tansta...@libertytrek.org wrote:
 The 'silly statements' reference was about your suggestion
 that it is in any way shape or form 'ok' to *accept* mail to invalid
 recipients then send it to dev/null.

Incidentally, yes there may be some circumstances where this could be
considered ok... a hobby server, or your own, personal server.

Your server, your rules.

But I'm talking about mail servers with lots of users who expect to be
able to communicate via email effectively and reliably with others on
the internet.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e4ec5.2000...@libertytrek.org

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?


Tanstaafl wrote:

On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:

Well, this really is OT for debian-users, but  Turns out that SMTP
WAS/IS intended to be reliable.

Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).


I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery

The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.



There is a technical distinction between best efforts (unreliable) 
protocols, such as IP ('fire and forget' if you will), and reliable 
protocols, such as TCP (with explicit acks and retransmits).


At least in the technical circles I run in (BBN - you know, we built the 
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally 
worked for me, for a short period - in a matrixy version of worked 
for), SMTP is usually discussed as providing a best efforts 
(unreliable) service -- which, in reality, it is (particularly in real 
world configurations where mail often gets relayed through multiple 
servers).


So.. I was just a bit surprised to go back and read the RFC and discover 
that SMTP is explicitly intended to provide a reliable service.


As to 100% reliable - nothing is 100% reliable.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543e6219.6030...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Andrew McGlashan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/10/2014 6:02 PM, Andrei POPESCU wrote:
 ConsoleKit, unmaintained.

But fixed, for kFreeBSD

A.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQ+ZOQACgkQqBZry7fv4vtv5gEAqxefTmCV1PLqwNWgJOGeFwGD
zc00RNvDgol9E3waTeUA/3VV1gqBmLnO2dYcydok6SlSN2S53dQGK+IEpSn3kRpg
=Q1fk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e64e7.8060...@affinityvision.com.au

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/14/2014 12:03 PM, Tanstaafl wrote:
 On 10/14/2014 11:17 AM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/14/2014 8:05 AM, Tanstaafl wrote:
 If you think I'm kidding, please by all means go make these silly
 statements on the postfix list and I'll just sit and watch the fun.

 You don't read very well.  This has nothing to do with emails to a valid
 address.  A large amount of that spam goes to invalid addresses.  I see
 them go through the logs regularly.

 I read fine. The 'silly statements' reference was about your suggestion
 that it is in any way shape or form 'ok' to *accept* mail to invalid
 recipients then send it to dev/null.

 But you just said it was OK to delete emails.

Please don't misquote me. I said it was the *worst case*, meaning, only
marginally better than *bouncing* them, which you should never do.

I certainly did not say it was 'OK'.

 Wrong.  Rejecting garbage sends a message back to the originator,

 No, it doesn't. It closes the connection with a response code.

snip

 I know how it works.

Apparently not, since you keep saying that the RECEIVING server 'sends a
message back to the originator' - unless maybe you simply have a hard
time saying what you really mean, which always causes confusion.

 Now how often do you get an email of 1MB?

Like a large percentage of businesses, we get mail *all the time* that
is many MB's in size. Even all of the freemailers have very large max
sizes they accept now (I think gmail is up to 25MB or 30MB?).

But, I'd say 10-15% of our email traffic consists of messages that are 1MB+

And yes, even lots of spam now has larger attachments (even seen them
over 2MB, though not very often).

 If I reject the mail at the RCPT-TO stage, then I only accepted a few
 bytes of traffic before terminating the connection with an SMTP response
 (error) code. The connecting machine then decides whether to pass the
 response back or not (again, a few bytes at most).

 That's your option.

No, it is the right thing to do.

 If you *accept* the mail, then you accepted the entire 1MB of traffic.

 So, who is responsible for more traffic in such a case?

 Sure.

Thank you for acknowledging that at least this argument in support of
breaking recipient validation (that rejecting emails results in more
traffic than accepting/deleting them) is wrong. We're making progress.

 But spammers don't know whether it is a good address or not.

Nor do they if I reject the transaction way before the RCPT-TO stage,
which postscreen does *very* well, which is what happens most of the time.

Also, my understanding is that there the vast majority of spammers no
longer engage in dictionary attacks to harvest valid email addresses.

 I said NOTHING about security.  I just don't want them to know what the
 valid email addresses are.

In my mind saying 'I am doing this because I don't want them to know
what the valid email addresses are' is the exact same thing as saying 'I
am doing this for security purposes.'.

 That way they don't send more SPAM to the good addresses.

It isn't about how much spam is targeted at your users, it is about how
much gets through, and an effective anti-spam solution block 99+% of it
- *without* breaking SMTP. And again, my understanding is that there the
vast majority of spammers no longer engage in dictionary attacks to
harvest valid email addresses, so you are continuing to break smtp for
your users and getting very little to no real world value out of it.

 Passwords, by their very nature, are intended to be
 difficult/impossible to 'guess'.

 To suggest that this is even in the same universe as 'security through
 obscurity' is ludicrous.

 Then what is that if it isn't obscurity?

I didn't say it wasn't 'obscurity', I said it wasn't *security through
obscurity*. The first is a simple word that has a very broad and
general meaning. The second has a very specific and limited meaning.

 You don't necessarily need to explictly violate any give RFC to 'break
 SMTP', Jerry.

 Breaking recipient validation defacto breaks SMTP. It tells the sending
 server that everything is OK, when it isn't. It allows someone who

 Tell me what RFC I am violating.  Unless I am violating an RFC, there is
 no breaking of SMTP.

Objection: asked and answered (see directly above).

 No one should. What I do care about is if the President of NBC typos an
 email address to our President when sending an important email, I want
 him to know the email didn't make it.

 And what if he sends a letter, but misaddresses the letter?

He'll (hopefully) know about it when it gets returned, because his
secretary (hopefully) isn't stupid and puts the correct return address
on it.

 Please explain what is *Seriously Fraudulent* or *otherwise
 inappropriate* about a typo in the recipient address of an otherwise
 perfectly legitimate email, Jerry.

 How many valid emails do you get to a bad email address?

Please answer the

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/14/2014 3:20 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/14/2014 11:24 AM, Tanstaafl wrote:
 However, once a message has been accepted - ie, *after* the DATA phase
 is complete, it should never be bounced, it should be delivered - or,
 worse, quarantined, or worst case, deleted (ie, itf it is later found to
 contain a malicious payload).
 
 But I was speaking mainly toward the botnet junk that postscreen is so
 good at rejecting now, and that is the vast majority...

 And that is exactly what I do - I delete the email.

Right... the 'worst case' (with the exception of bouncing) I mentioned
above.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e6611.9040...@libertytrek.org

Re: piece of mind (Re: Moderated posts?)

On 10/15/2014 at 04:08 AM, Martin Read wrote:

 On 14/10/14 22:56, Steve Litt wrote:
 
 On Wed, 15 Oct 2014 00:15:40 +0300 Andrei POPESCU
 andreimpope...@gmail.com wrote:

 And it also seems to make sense (why should every Desktop
 Environment implement it's own solution for this?).

 And how were they handling this task before systemd?
 
 They were using ConsoleKit, which was orphaned upstream some time
 after systemd-logind came along.

And how were they handling it (or an analogous / equivalent task) before
ConsoleKit, and the other *kit thingies, became a thing?

I suspect that the answer is they just didn't provide the functionality
which ConsoleKit, and later systemd-logind, now enable them to provide,
but I'm not aware - in a clear-understanding, defined-boundaries sense -
of exactly what that functionality is, or of why it would be necessary
or otherwise valuable, or of what the problem is which that
functionality was intended to address.

I have a similar lack of awareness and/or understanding about all of the
*kit packages / projects / tools / what-have-you, actually; I'm not
positive I even know how many there are, much less all of their names.
This has probably contributed to the lack of that awareness /
understanding, since any partial explanation I see for one of them gets
partly conflated with and/or applied to the other(s?), and the whole
thing gets muddied by that mire.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

On 10/14/2014 at 04:15 PM, Olav Vitters wrote:

 On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
 
 Considering that the users are Debians' priority, couldn't this
 issue be a case in which significant concerns from/of the users
 about an issue might initiate a GR?  Wouldn't it speak loudly for
 Debian and its ways and for what it stands for, or used to stand
 for, if it was established procedure that issues arising
 significant concerns amongst the users can lead to a GR?
 
 I'm sure we could find quite a few supporters for having a GR
 amongst the users (here).  And after all, we're all kinda stuck in
 the same boat.  A GR might have the potential to make the gap
 between users and devs/maintainers a lot smaller.  Otherwise, this
 gap will only continue to become wider and wider.
 
 Debian is known for focussing a lot on focussing on quality.
 Upgrading from one version to the next is expected to be utterly
 smooth. Any bug encountered is exceptional.

Definitions of what constitutes utterly smooth may vary, however.


The should upgrading from wheezy to jessie automatically switch the
init system to systemd, unless the admin has taken some sufficiently
clear action to prevent it? question is one possible example. One side
of that debate seems to think that a properly smooth upgrade requires
that such an automatic switch take place (because otherwise the init
system doesn't get upgraded to what would be put in place by a new
install, so the upgrade can't be said to have actually completed);
another seems to think that a properly smooth upgrade requires that such
an automatic switch *not* take place (because of the chance of breaking
existing local configuration, among possibly other things).


For another example: some time ago, on debian-devel, the question arose
of whether it's reasonable to expect people to reboot promptly after
installing e.g. a new kernel, or a new init system. While of course you
can't expect to gain any functionality advantage from the
newly-installed software until the reboot in those cases, it still seems
reasonable to me to expect that no previously-existing functionality
will be *lost* in the window between such an upgrade and the next reboot.

However, at least one of the systemd Debian maintainers stated in that
discussion that while having a keep going as normal and reboot at
leisure scenario work smoothly would be nice, he does not consider it a
hard requirement. (The functionality at hand apparently included, but
was not necessarily limited to, power-management functionality - such as
the reboot button. I think that particular piece of functionality may
have been addressed since then, but the larger principle still exists.)

I think that for such a scenario to not work would place the upgrade
outside the bounds of what constitutes utterly smooth, and I would
consider any such functionality loss to be a bug - quite possibly an RC
bug. The maintainer in question, at least, does not appear to think
that; he does appear to agree that it would be a bug, but a minor one at
best. Thus, definitions vary, Q.E.D..

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote:

 On 10/14/2014 12:03 PM, Tanstaafl wrote:
 
 On 10/14/2014 11:17 AM, Jerry Stuckle jstuc...@attglobal.net
 wrote:

 Wrong on two counts.  First of all, the false notion Security
 through obscurity *never* works.  This has nothing to do with
 security.

 And BTW, that statement is also wrong - why do you think people
 are encouraged to use obscure passwords if it doesn't work? But
 that's another subject.
 
 Lol! Not even in the same ballpark, Jerry. Passwords, by their
 very nature, are intended to be difficult/impossible to 'guess'.
 
 To suggest that this is even in the same universe as 'security
 through obscurity' is ludicrous.
 
 Then what is that if it isn't obscurity?

Security by obscurity isn't no one knows the password or no one
knows the account name; it's something more like no one knows there's
a place to enter an account name or a password.

It isn't no one knows how to unlock the door; it's no one knows where
the door is, or even closer, no one knows that there even is a door.

(There's a mall near where I live which has an out-of-the-way door which
is never locked at any hour, and which does not appear to be covered by
security cameras. As far as I can tell, the after-hours security there
relies entirely on the fact that the general public does not know the
door exists. That's security by obscurity.)

I'm not entirely positive on which side of that distinction this
situation falls, overall. Keeping passwords secret is definitely not
security by obscurity, but concealing the fact that a given account
exists may arguably be.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-15 Thread Joel Rees

On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
Tanstaafl wrote:

On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:

Well, this really is OT for debian-users, but Turns out that SMTP
WAS/IS intended to be reliable.

Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).

I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery

The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.

There are three ways in which machines can be unreliable.

One, they can break.

Two, they can do what they are told to do, but what they are told to
do can be wrong.

Three, they can operate in a context in which they were not designed to operate.

Unfortunately, most machines operated outside the context in which
they were designed to operate. It's a limitation of design. We are the
designers, and we can't think of everything, therefore we cannot
really design for a real context.

Put another way, any context we can design for is necessarily more
constrained than reality.

Fortunately, most of the contexts we design for are close enough to
be useful under many real contexts. But we have to quit being taken by
surprise when our machines hit corner cases, or we end up wasting our
energy being surprised.

That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).

There is a technical distinction between best efforts (unreliable)
protocols, such as IP ('fire and forget' if you will), and reliable
protocols, such as TCP (with explicit acks and retransmits).

At least in the technical circles I run in (BBN - you know, we built the
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
worked for me, for a short period - in a matrixy version of worked for),
SMTP is usually discussed as providing a best efforts (unreliable) service
-- which, in reality, it is (particularly in real world configurations where
mail often gets relayed through multiple servers).

So.. I was just a bit surprised to go back and read the RFC and discover
that SMTP is explicitly intended to provide a reliable service.

If it is, that has changed.

Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.

Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.

If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.

As to 100% reliable - nothing is 100% reliable.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. Yogi Berra

--
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iP9t8iJYmPNLkVw_Pg8UAJYHHZeacftZ=fm_rt2cr1...@mail.gmail.com

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 8:14 AM, Tanstaafl wrote:
 On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/14/2014 12:03 PM, Tanstaafl wrote:
 On 10/14/2014 11:17 AM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/14/2014 8:05 AM, Tanstaafl wrote:
 If you think I'm kidding, please by all means go make these silly
 statements on the postfix list and I'll just sit and watch the fun.

 You don't read very well.  This has nothing to do with emails to a valid
 address.  A large amount of that spam goes to invalid addresses.  I see
 them go through the logs regularly.

 I read fine. The 'silly statements' reference was about your suggestion
 that it is in any way shape or form 'ok' to *accept* mail to invalid
 recipients then send it to dev/null.
 
 But you just said it was OK to delete emails.
 
 Please don't misquote me. I said it was the *worst case*, meaning, only
 marginally better than *bouncing* them, which you should never do.
 
 I certainly did not say it was 'OK'.
 

You said it was OK.  You may try to attack conditions to it - but you
still said it was OK.

 Wrong.  Rejecting garbage sends a message back to the originator,
 
 No, it doesn't. It closes the connection with a response code.
 
 snip
 
 I know how it works.
 
 Apparently not, since you keep saying that the RECEIVING server 'sends a
 message back to the originator' - unless maybe you simply have a hard
 time saying what you really mean, which always causes confusion.
 

Yes, I do.  And it does send a message back to the originator - it may
only be a status code, but it is still a message.

 Now how often do you get an email of 1MB?
 
 Like a large percentage of businesses, we get mail *all the time* that
 is many MB's in size. Even all of the freemailers have very large max
 sizes they accept now (I think gmail is up to 25MB or 30MB?).
 

Provide figures for your claim of a large percentage of businesses.
Seldom do I see messages that big on ANY of my systems.  Additionally,
often times ISPs will limit the size of messages users can send.  And
many systems have limits on how much storage email can take up.  Just
because a couple of free email services accept larger messages does not
mean EVERYONE does.

 But, I'd say 10-15% of our email traffic consists of messages that are 1MB+
 

For my systems, it is  1%.  And the average email size is around 20-30K.

 And yes, even lots of spam now has larger attachments (even seen them
 over 2MB, though not very often).
 

Yes, spam with trojans and viruses often have large attachments.  But
those are quickly taken care of by the antivirus routines.

 If I reject the mail at the RCPT-TO stage, then I only accepted a few
 bytes of traffic before terminating the connection with an SMTP response
 (error) code. The connecting machine then decides whether to pass the
 response back or not (again, a few bytes at most).
 
 That's your option.
 
 No, it is the right thing to do.
 

According to which RFC?  Until you can point me to what RFC I am
violating, it is just your opinion.

 If you *accept* the mail, then you accepted the entire 1MB of traffic.

 So, who is responsible for more traffic in such a case?
 
 Sure.
 
 Thank you for acknowledging that at least this argument in support of
 breaking recipient validation (that rejecting emails results in more
 traffic than accepting/deleting them) is wrong. We're making progress.
 

You don't recognize sarcasm very well.

 But spammers don't know whether it is a good address or not.
 
 Nor do they if I reject the transaction way before the RCPT-TO stage,
 which postscreen does *very* well, which is what happens most of the time.
 

Sure they do.  They get a status message back indicating the message was
rejected and why it was rejected.  The fact they DON'T get that message
indicates they have found a valid EMAIL address.

And validated EMAIL addresses are a spammer's dream.

 Also, my understanding is that there the vast majority of spammers no
 longer engage in dictionary attacks to harvest valid email addresses.
 

Your understanding is incorrect.  I see it regularly.

 I said NOTHING about security.  I just don't want them to know what the
 valid email addresses are.
 
 In my mind saying 'I am doing this because I don't want them to know
 what the valid email addresses are' is the exact same thing as saying 'I
 am doing this for security purposes.'.
 

It has nothing to do with security, no matter is in your mind.

 That way they don't send more SPAM to the good addresses.
 
 It isn't about how much spam is targeted at your users, it is about how
 much gets through, and an effective anti-spam solution block 99+% of it
 - *without* breaking SMTP. And again, my understanding is that there the
 vast majority of spammers no longer engage in dictionary attacks to
 harvest valid email addresses, so you are continuing to break smtp for
 your users and getting very little to no real world value out of it.
 

It's also about how much is targeted at my

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 10:17 AM, The Wanderer wrote:
 On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote:
 
 On 10/14/2014 12:03 PM, Tanstaafl wrote:

 On 10/14/2014 11:17 AM, Jerry Stuckle jstuc...@attglobal.net
 wrote:
 
 Wrong on two counts.  First of all, the false notion Security
 through obscurity *never* works.  This has nothing to do with
 security.
 
 And BTW, that statement is also wrong - why do you think people
 are encouraged to use obscure passwords if it doesn't work? But
 that's another subject.

 Lol! Not even in the same ballpark, Jerry. Passwords, by their
 very nature, are intended to be difficult/impossible to 'guess'.

 To suggest that this is even in the same universe as 'security
 through obscurity' is ludicrous.

 Then what is that if it isn't obscurity?
 
 Security by obscurity isn't no one knows the password or no one
 knows the account name; it's something more like no one knows there's
 a place to enter an account name or a password.


You're limiting it too much.  From Dictionary.com:

obscurity
noun, plural obscurities.
1. the state or quality of being obscure.
2. the condition of being unknown:
...

A complex password is, by definition, obscure according to #2.  And
easily guessable password is not obscure, nor is it secure.


 It isn't no one knows how to unlock the door; it's no one knows where
 the door is, or even closer, no one knows that there even is a door.


See above.

 (There's a mall near where I live which has an out-of-the-way door which
 is never locked at any hour, and which does not appear to be covered by
 security cameras. As far as I can tell, the after-hours security there
 relies entirely on the fact that the general public does not know the
 door exists. That's security by obscurity.)


That's one example.

 I'm not entirely positive on which side of that distinction this
 situation falls, overall. Keeping passwords secret is definitely not
 security by obscurity, but concealing the fact that a given account
 exists may arguably be.
 

See above.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e9cb5.9020...@attglobal.net

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 at 12:11 PM, Jerry Stuckle wrote:

 On 10/15/2014 10:17 AM, The Wanderer wrote:
 
 On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote:

 Then what is that if it isn't obscurity?
 
 Security by obscurity isn't no one knows the password or no
 one knows the account name; it's something more like no one knows
 there's a place to enter an account name or a password.
 
 You're limiting it too much.  From Dictionary.com:
 
 obscurity
 noun, plural obscurities.
 1. the state or quality of being obscure.
 2. the condition of being unknown:
 ...

That's a definition of obscurity, which is indeed fairly broad.

It's not a definition of security by obscurity, which is considerably
more narrow than the generic definition of obscurity would indicate.

In many contexts, the use of the jargon phrase security by obscurity
occurs specifically in order to draw on that more narrow definition. I
believe that this is one such context.

(I think that I also believe that using security by obscurity with a
broader sense than that narrow one is inappropriate, because it
introduces ambiguity as to which meaning is intended, and is therefore
likely to be confusing to a potential reader. But that's a bit of a
tangent.)

Invoking the generic definition of obscurity in the face of a use of
the jargon phrase security by obscurity is completely missing the
intent, and the sense of that phrase.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Steve Litt

On Wed, 15 Oct 2014 10:02:03 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

 On Ma, 14 oct 14, 17:56:58, Steve Litt wrote:
  
  Because you don't want to inextricably drag a giant monolith into
  your Desktop Environment just to do a few things.
 
 If you compare systemd with a Desktop Environment I'm not quite sure 
 who's the giant ;)

Yeah, I wasn't clear. I meant giant relative to what needed to be done.
In other words, you need to verify passwords, so you bring in the
entirety of systemd to do it, instead of just writing the code yourself.

I completely understand not reinventing the wheel, but if all you need
is a spoke, you don't construct an interface to a whole wheel just to
get your spoke.

 
  And how were they handling
  this task before systemd? It's not like Desktops, Window Managers
  and whatever things like lightdm are called didn't exist before
  systemd.
 
 ConsoleKit, unmaintained.

Pre-cisely. I see Red Hat's fingerprints all over that unmaintained
status. If not for Red Hat, somebody would have picked up ConsoleKit.
After all, as shown in
http://spectrum.ieee.org/computing/software/whos-writing-linux ,
there's plenty of money floating around to pay for free software
development.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015123026.5f396...@mydesq2.domain.cxm

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 at 12:06 PM, Jerry Stuckle wrote:

 On 10/15/2014 8:14 AM, Tanstaafl wrote:
 
 On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net
 wrote:

 But you just said it was OK to delete emails.
 
 Please don't misquote me. I said it was the *worst case*, meaning,
 only marginally better than *bouncing* them, which you should never
 do.
 
 I certainly did not say it was 'OK'.
 
 You said it was OK.  You may try to attack conditions to it - but
 you still said it was OK.

In a quick search, I haven't been able to find a mail from him which
uses the term OK, prior to the quoted one which is responding to your
use of that term.

He did say (in close paraphrase) that there are circumstances in which
silently deleting received mails can be barely acceptable. That's a far
cry from saying that it's OK, either in the modern colloquial sense or
in the literal original sense of all correct.

 I said NOTHING about security.  I just don't want them to know
 what the valid email addresses are.
 
 In my mind saying 'I am doing this because I don't want them to
 know what the valid email addresses are' is the exact same thing as
 saying 'I am doing this for security purposes.'.
 
 It has nothing to do with security, no matter is in your mind.

What is the non-security-related reason why you don't want them to know
what the valid E-mail addresses are?

I suspect that the reason is something which Tanstaafl would classify as
falling under security purposes.

Even if you don't come to agreement on whether that reason is a security
reason, it might still be easier to agree to disagree if there's a
clear understanding about exactly what you're disagreeing over, rather
than just conflicting assertions about some consequence of that
underlying point.

 Please explain what is *Seriously Fraudulent* or *otherwise
 inappropriate* about a typo in the recipient address of an
 otherwise perfectly legitimate email, Jerry.
 
 How many valid emails do you get to a bad email address?
 
 Please answer the question.
 
 Any email to a bad email address is fraudulent and/or inappropriate.

That's just repeating the assertion, not answering the question. It does
not provide the requested explanation.

What is fraudulent about a typo?

What is inappropriate about a typo?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 12:25 PM, The Wanderer wande...@fastmail.fm wrote:
 On 10/15/2014 at 12:11 PM, Jerry Stuckle wrote:
 You're limiting it too much.  From Dictionary.com:

 obscurity
 noun, plural obscurities.
 1. the state or quality of being obscure.
 2. the condition of being unknown:
 ...

 That's a definition of obscurity, which is indeed fairly broad.

Thanks, saved me the trouble - although I don't expect Jerry to 'get
it', so this is probably a waste of everyones time to pursue.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ea18f.9050...@libertytrek.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 12:06 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/15/2014 8:14 AM, Tanstaafl wrote:
 On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 But you just said it was OK to delete emails.

 Please don't misquote me. I said it was the *worst case*, meaning, only
 marginally better than *bouncing* them, which you should never do.

 I certainly did not say it was 'OK'.

 You said it was OK.  You may try to attack conditions to it - but you
 still said it was OK.

Easy enough to prove. By all means, quote the actual text of me saying
this was 'OK'...

 you keep saying that the RECEIVING server 'sends a message back to
 the originator' - unless maybe you simply have a hard time saying
 what you really mean, which always causes confusion.

 it does send a message back to the originator - it may only be a
 status code, but it is still a message.

The status code is not *sent* anywhere - it is a response directly to
the connecting machine.

It is then the responsibility of that machine that was talking to your
server to pass the response code back to the originating *server* (not
the sender of the email - there is a difference).

It is then the responsibility of the 'originating server' to generate
the NDR (non-delivery response) email that the sender then receives in
their Inbox.

So, again, no, *your* server doesn't 'send anything back to the
originating server'.

I'm done with this thread, since Jerry is free to believe whatever he
wants and run his servers however he wants.

Thankfully the vast majority of other mail admins use best practices...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ea368.8000...@libertytrek.org

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Steve Litt

On Wed, 15 Oct 2014 09:08:26 +0100
Martin Read zen75...@zen.co.uk wrote:

 On 14/10/14 22:56, Steve Litt wrote:

  And how were they handling this task before systemd?
 
 They were using ConsoleKit, which was orphaned upstream some time
 after systemd-logind came along.

I rest my case.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015124258.53bd8...@mydesq2.domain.cxm

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?


Joel Rees wrote:

On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

Tanstaafl wrote:

On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:

Well, this really is OT for debian-users, but  Turns out that SMTP
WAS/IS intended to be reliable.

Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).


I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery

The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.

There are three ways in which machines can be unreliable.

One, they can break.

Two, they can do what they are told to do, but what they are told to
do can be wrong.

Three, they can operate in a context in which they were not designed to operate.


Oh come on, there are lots more ways that PROTOCOLS can be unreliable.

We're talking about an environment plagued with noise, congestion, bit 
errors, routing errors, filtering - all kinds of things that are 
probabilistic in nature.


Unreliable protocols are generally 'fire-and-forget' in nature (e.g., 
UDP) and promise, at most, best efforts.


Reliable protocols are those that include end-to-end (or, more 
accurately, peer-to-peer) error checking, ACKs and NACKs, 
retransmission, and so forth.  In a protocol context, reliable means, 
essentially, 'once I get an ACK, I can assume that my PDU has been 
delivered to my peer' - and has nothing to do with what happens beyond that.




That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).


Ummm no.  RFCs were RFCs because that's how the early ARPANET RD 
community, and its leadership decided to conduct their business, and the 
model stuck.



There is a technical distinction between best efforts (unreliable)
protocols, such as IP ('fire and forget' if you will), and reliable
protocols, such as TCP (with explicit acks and retransmits).

At least in the technical circles I run in (BBN - you know, we built the
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
worked for me, for a short period - in a matrixy version of worked for),
SMTP is usually discussed as providing a best efforts (unreliable) service
-- which, in reality, it is (particularly in real world configurations where
mail often gets relayed through multiple servers).

So.. I was just a bit surprised to go back and read the RFC and discover
that SMTP is explicitly intended to provide a reliable service.

If it is, that has changed.


Umm no.  The goal statement hasn't changed.  Limitations to that 
goal have been elaborated on - i.e., specific limits and exceptions to 
that reliability have been elaborated on.  But, on the whole, the notion 
of peer-to-peer transmission of email, as a reliable service, with 
acks/nacks/retransmission/error messages/etc/, remains unchanged.


Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.

Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.

If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.

Exactly.  RFC 821 and its successors do not address human-to-human 
communications, they specify a reliable protocol for MTA-to-MTA 
communication.  Period.


I'll close by noting that this branch of discussion started with a focus 
on silently dropping spam, and whether that's a violation of standards.  
It used to be a clear violation of the various MUST statements re. 
sending non-delivery messages.  It looks like more recent standards now 
allow for dropping spam as a specific exception case.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ea5ea.1030...@meetinghouse.net

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 12:50 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:
 I'll close by noting that this branch of discussion started with a focus 
 on silently dropping spam, and whether that's a violation of standards.

Actually, no, this branch started with a focus on whether or not it is a
good idea to break SMTP by accepting email from *invalid recipients*
then silently deleting them, as opposed to rejecting them at the RCPT-TO
stage.

 It used to be a clear violation of the various MUST statements re. 
 sending non-delivery messages.  It looks like more recent standards now 
 allow for dropping spam as a specific exception case.

My position is that:

1. email to invalid recipients should be rejected at the RCPT-TO stage,

2. under *no* circumstances should mail to invalid recipients be
accepted for delivery then silently deleted based solely on that one
criteria,

and

3. once an email has been accepted for final delivery, every effort
should be taken to deliver the message to the recipient, whether to
their Inbox clean or tagged as spam (if a spam threshhold is met), or to
a spam quarantine,

I allow for the very rare 'clear-and-present-danger' exceptional
circumstance that, if an after-queue content scanner determines with a
very high probability that something contains a malicious payload, an
admin might want to not deliver it to the recipient. But, I would also
argue that it should go into a quarantine that only the admin has access
to, and never just silently deleted.

But, as Jerry says, that is just my opinion...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543eb3f3.6050...@libertytrek.org

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Jonathan Dowland

On Wed, Oct 15, 2014 at 12:42:58PM -0400, Steve Litt wrote:
  They were using ConsoleKit, which was orphaned upstream some time
  after systemd-logind came along.
 
 I rest my case.

There's nothing at all (not even Red Hat) preventing anyone (even you!) from
stepping up and taking over development of ConsoleKit. It's a considerably
smaller proposition than taking over GNOME 2, a vastly more complex suite of
software and libraries, and that actually did happen
(http://mate-desktop.org). 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015182720.ga32...@chew.redmars.org

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 12:34 PM, The Wanderer wrote:
 On 10/15/2014 at 12:06 PM, Jerry Stuckle wrote:
 
 On 10/15/2014 8:14 AM, Tanstaafl wrote:

 On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net
 wrote:
 
 But you just said it was OK to delete emails.

 Please don't misquote me. I said it was the *worst case*, meaning,
 only marginally better than *bouncing* them, which you should never
 do.

 I certainly did not say it was 'OK'.

 You said it was OK.  You may try to attack conditions to it - but
 you still said it was OK.
 
 In a quick search, I haven't been able to find a mail from him which
 uses the term OK, prior to the quoted one which is responding to your
 use of that term.
 
 He did say (in close paraphrase) that there are circumstances in which
 silently deleting received mails can be barely acceptable. That's a far
 cry from saying that it's OK, either in the modern colloquial sense or
 in the literal original sense of all correct.
 
 I said NOTHING about security.  I just don't want them to know
 what the valid email addresses are.

 In my mind saying 'I am doing this because I don't want them to
 know what the valid email addresses are' is the exact same thing as
 saying 'I am doing this for security purposes.'.

 It has nothing to do with security, no matter is in your mind.
 
 What is the non-security-related reason why you don't want them to know
 what the valid E-mail addresses are?


Spammers buy and sell lists of email addresses.  Clean lists - that
is, ones with few invalid email addresses, are worth more and are used
more than dirty lists.

Spammers often test email servers by sending email to garbage addresses,
to see if they get a bounce.  If they don't, they know the server does
not drop emails, and any address in that domain is suspect.  So the
domain doesn't make a lot of the clean lists.

 I suspect that the reason is something which Tanstaafl would classify as
 falling under security purposes.
 

There is no security involved here.  Simply another means of
discouraging SPAM.

 Even if you don't come to agreement on whether that reason is a security
 reason, it might still be easier to agree to disagree if there's a
 clear understanding about exactly what you're disagreeing over, rather
 than just conflicting assertions about some consequence of that
 underlying point.
 

He thinks what I am doing breaks SMTP - but he can't point to any RFC
I am violating.

 Please explain what is *Seriously Fraudulent* or *otherwise
 inappropriate* about a typo in the recipient address of an
 otherwise perfectly legitimate email, Jerry.

 How many valid emails do you get to a bad email address?

 Please answer the question.

 Any email to a bad email address is fraudulent and/or inappropriate.
 
 That's just repeating the assertion, not answering the question. It does
 not provide the requested explanation.
 
 What is fraudulent about a typo?
 
 What is inappropriate about a typo?
 

Nothing.  But if you get a lot of typos, then you should be looking for
better quality customers.  I don't see that at all in our logs.

All I see are fraudulent and/or inappropriate emails to addresses which
aren't even close to the ones on the servers.

Jerry



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ec5fc.20...@attglobal.net

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?


Tanstaafl wrote:

On 10/15/2014 12:50 PM, Miles Fidelman mfidel...@meetinghouse.net wrote:

I'll close by noting that this branch of discussion started with a focus
on silently dropping spam, and whether that's a violation of standards.

Actually, no, this branch started with a focus on whether or not it is a
good idea to break SMTP by accepting email from *invalid recipients*
then silently deleting them, as opposed to rejecting them at the RCPT-TO
stage.


It used to be a clear violation of the various MUST statements re.
sending non-delivery messages.  It looks like more recent standards now
allow for dropping spam as a specific exception case.

My position is that:

1. email to invalid recipients should be rejected at the RCPT-TO stage,


Easier said then done - at least when a server does relaying, but 
clearly ideal when possible.




2. under *no* circumstances should mail to invalid recipients be
accepted for delivery then silently deleted based solely on that one
criteria,

and

3. once an email has been accepted for final delivery, every effort
should be taken to deliver the message to the recipient, whether to
their Inbox clean or tagged as spam (if a spam threshhold is met), or to
a spam quarantine,

I allow for the very rare 'clear-and-present-danger' exceptional
circumstance that, if an after-queue content scanner determines with a
very high probability that something contains a malicious payload, an
admin might want to not deliver it to the recipient. But, I would also
argue that it should go into a quarantine that only the admin has access
to, and never just silently deleted.

But, as Jerry says, that is just my opinion...



Generally agree with you in principle.  And that's certainly the 
standards-compliant policy.


In practice I support a few dozen mailing lists - operational 
necessity dictates dropping a lot of stuff silently.


Cheers

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ec757.80...@meetinghouse.net

Re: Recipient validation - WAS: Re: Moderated posts?

On 10/15/2014 12:40 PM, Tanstaafl wrote:
 On 10/15/2014 12:06 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 10/15/2014 8:14 AM, Tanstaafl wrote:
 On 10/14/2014 3:28 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 But you just said it was OK to delete emails.
 
 Please don't misquote me. I said it was the *worst case*, meaning, only
 marginally better than *bouncing* them, which you should never do.

 I certainly did not say it was 'OK'.
 
 You said it was OK.  You may try to attack conditions to it - but you
 still said it was OK.
 
 Easy enough to prove. By all means, quote the actual text of me saying
 this was 'OK'...
 

You said:

However, once a message has been accepted - ie, *after* the DATA phase
is complete, it should never be bounced, it should be delivered - or,
worse, quarantined, or worst case, deleted (ie, itf it is later found to
contain a malicious payload).

It is either OK to delete an email or it is not.  You can't have it both
ways.  If, as according to your other statements, it is not OK to delete
emails, then you are violating your own rules by deleting mails - for
ANY reason.

Your reason is i.e. if it is later found to contain a malicious
payload.  My reason is It is addressed to a non-existent user.
Either both are OK or neither is OK.

 you keep saying that the RECEIVING server 'sends a message back to
 the originator' - unless maybe you simply have a hard time saying
 what you really mean, which always causes confusion.
 
 it does send a message back to the originator - it may only be a
 status code, but it is still a message.
 
 The status code is not *sent* anywhere - it is a response directly to
 the connecting machine.
 

Then how does it get back to the sending server?  Magic?

 It is then the responsibility of that machine that was talking to your
 server to pass the response code back to the originating *server* (not
 the sender of the email - there is a difference).
 

I didn't say the sender of the email.

 It is then the responsibility of the 'originating server' to generate
 the NDR (non-delivery response) email that the sender then receives in
 their Inbox.


I never said otherwise.

 So, again, no, *your* server doesn't 'send anything back to the
 originating server'.
 

So how does it get back to the sending server?  Magic?

 I'm done with this thread, since Jerry is free to believe whatever he
 wants and run his servers however he wants.
 
 Thankfully the vast majority of other mail admins use best practices...
 
 

And you still can't quote an RFC which indicates what I am doing breaks
SMTP.  That's because there isn't one and I am NOT breaking SMTP.
Properly addressed email still gets to its destination.

BTW - what happened to all those statistics you quoted?  Where are your
references for them?


Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ec7cc.3030...@attglobal.net

Re: piece of mind (Re: Moderated posts?)


Jonathan Dowland wrote:

On Wed, Oct 15, 2014 at 12:42:58PM -0400, Steve Litt wrote:

They were using ConsoleKit, which was orphaned upstream some time
after systemd-logind came along.

I rest my case.

There's nothing at all (not even Red Hat) preventing anyone (even you!) from
stepping up and taking over development of ConsoleKit. It's a considerably
smaller proposition than taking over GNOME 2, a vastly more complex suite of
software and libraries, and that actually did happen
(http://mate-desktop.org).



In theory.  But in practice, folks make practical decisions as to 
expenditure of time and resources.  For example, once Debian committed 
to systemd, Ubuntu followed suit - I expect that upstart will promptly 
whither and die.


Whether a conspiracy or not, decisions by big players (in this case the 
Debian TC), can have serious and widespread impacts.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ec816.5020...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Martin Read


On 15/10/14 17:30, Steve Litt wrote:

Pre-cisely. I see Red Hat's fingerprints all over that unmaintained
status. If not for Red Hat, somebody would have picked up ConsoleKit.
After all, as shown in
http://spectrum.ieee.org/computing/software/whos-writing-linux ,
there's plenty of money floating around to pay for free software
development.


A question for you:

Which funder of free software development do you believe would 
realistically stand to make a measurably-greater-than-unity return on 
investment (either in reasonably foreseeable losses averted or 
reasonably foreseeable new profits obtained) by choosing to underwrite 
(or assign employees to) resumed development of ConsoleKit?


I have a couple of observations which I think may be relevant:

* The set of people hostile to systemd seems to include a lot of people 
who don't see much need for the likes of ConsoleKit either.


* ConsoleKit isn't, in terms of its size, particularly intimidating; the 
actual C source code is only about 20% larger than the 
autotools-associated shell scripts.




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ecad3.8020...@zen.co.uk

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Jonathan Dowland

On Wed, Oct 15, 2014 at 03:16:38PM -0400, Miles Fidelman wrote:
 In theory.  But in practice, folks make practical decisions as to
 expenditure of time and resources.  For example, once Debian
 committed to systemd, Ubuntu followed suit - I expect that upstart
 will promptly whither and die.

You're right (and I agree re upstart. Having said that I really
resent having to fix upstart bugs at work, now, and it will live
on a while in LTS Ubuntu releases. I'm starting to think that
reported bugs will get less attention nowtoo). But the consolekit
deprecation happened a long time before the tech-ctte decision
about systemd. Some one/people could have picked it up long ago.
If they had, the context in which the tech-ctte decision was made
could have been very different.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015194937.gc...@chew.redmars.org

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Andrew McGlashan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/10/2014 6:49 AM, Jonathan Dowland wrote:
 reported bugs will get less attention nowtoo). But the consolekit
 deprecation happened a long time before the tech-ctte decision
 about systemd. Some one/people could have picked it up long ago.
 If they had, the context in which the tech-ctte decision was made
 could have been very different.

ConsoleKit has been fixed for kFreeBSD build, I expect fixing it in
normal Debian/GNU wouldn't have been harder than choosing systemd.

A.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQ+154ACgkQqBZry7fv4vuDTAD+PgRuxA+5/DfsI+VGk3rwyw/f
6UEzhSHpuYMhXin2YqoA+gMV12rwbI4llFwLlf43QwhurpmS6ltjhHESYAOIUDwW
=Ik37
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ed79f.4080...@affinityvision.com.au

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Jonathan Dowland

On Thu, Oct 16, 2014 at 07:22:55AM +1100, Andrew McGlashan wrote:
 ConsoleKit has been fixed for kFreeBSD build, I expect fixing it in
 normal Debian/GNU wouldn't have been harder than choosing systemd.

It really needs (needed) adopting upstream, not just in Debian, because it's
upstream where people make decisions about what their software will support; so
that's where people have made the move to systemd, and that's the context which
I'm talking about.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015203813.gc1...@chew.redmars.org

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Mark Carroll

Martin Read zen75...@zen.co.uk writes:
(snip)
 * The set of people hostile to systemd seems to include a lot of people 
 who don't see much need for the likes of ConsoleKit either.
(snip)

This is actually a rather good point. The machines I am most
conservative about, and wanting to make sure that they boot well and can
easily be repaired when not, are pretty much exactly those I wouldn't
exactly have a heavyweight desktop environment on either.

And, indeed, even on the laptop from which I'm writing this message,
there's no consolekit or policykit or suchlike. So long as I can keep it
minimal and tractable, I'm happy: what I like about Linux is getting to
understand and control much of what goes on under the hood, and with
luck I'll get to continue being able to do exactly that. (This is one
nice thing about init systems that make heavy use of shell scripts: at
least I can easily read and understand and adjust them!)

I assume others have different desires, and in its present form systemd
may well support them better, with apparently having been designed with
different goals in mind.

-- Mark


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94xoyii@ixod.org

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-15 Thread Joe

On Wed, 15 Oct 2014 15:15:24 -0400
Jerry Stuckle jstuc...@attglobal.net wrote:


 
 It is either OK to delete an email or it is not.  You can't have it
 both ways.  

It is *not* OK to silently delete an already accepted email, it does
indeed break SMTP as a reliable protocol ('reliable' as in: 'either we
deliver it or we tell you we didn't').

However, if the Reply-To: is forged, i.e. if it is spam, the
alternative is considerably less OK. Bouncing a spam message simply
delivers *the* *entire* *message* to an innocent third party, having
been laundered through your (presumably legitimate and respectable) mail
server.

So it isn't OK, but there's no alternative to doing it. That's how you
have it both ways.

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015214430.2eb6a...@jresid.jretrading.com

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-15 Thread Joe

On Wed, 15 Oct 2014 15:13:27 -0400
Miles Fidelman mfidel...@meetinghouse.net wrote:

 Tanstaafl wrote:

  My position is that:
 
  1. email to invalid recipients should be rejected at the RCPT-TO
  stage,
 
 Easier said then done - at least when a server does relaying, but 
 clearly ideal when possible.
 
It's worth some effort, at the moment it is the single most effective
anti-spam measure. If you outsource your mail, it's worth going to some
trouble to find a hosting company who will hold and accept updates for
a list of valid recipients.

 
  2. under *no* circumstances should mail to invalid recipients be
  accepted for delivery then silently deleted based solely on that one
  criteria,

Not on that alone, no, it could be a typo, in which case the sender
needs to be informed. But if it is spam, there's nobody to tell, and
you don't want to send a copy of the spam to the forged Reply-To:
address.
 
  and
 
  3. once an email has been accepted for final delivery, every effort
  should be taken to deliver the message to the recipient, whether to
  their Inbox clean or tagged as spam (if a spam threshhold is met),
  or to a spam quarantine,

Which shouldn't be a problem if there's a valid recipient.

 
  I allow for the very rare 'clear-and-present-danger' exceptional
  circumstance that, if an after-queue content scanner determines
  with a very high probability that something contains a malicious
  payload, an admin might want to not deliver it to the recipient.
  But, I would also argue that it should go into a quarantine that
  only the admin has access to, and never just silently deleted.
 
Yes, and a log kept. *And* the postmaster address monitored, and a
request to know the disposition of a vanished email should be
answered, along with the reason. Especially if the request is
accompanied by one of your message IDs...

  But, as Jerry says, that is just my opinion...

Indeed. Within his domain, the email admin is king...
 
 
 Generally agree with you in principle.  And that's certainly the 
 standards-compliant policy.
 
 In practice I support a few dozen mailing lists - operational 
 necessity dictates dropping a lot of stuff silently.

Of course. Already-accepted spam *must* be silently dropped.

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015215812.021c2...@jresid.jretrading.com

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Andrei POPESCU

On Mi, 15 oct 14, 09:46:47, The Wanderer wrote:
 
 I suspect that the answer is they just didn't provide the functionality
 which ConsoleKit, and later systemd-logind, now enable them to provide,
 but I'm not aware - in a clear-understanding, defined-boundaries sense -
 of exactly what that functionality is, or of why it would be necessary
 or otherwise valuable, or of what the problem is which that
 functionality was intended to address.

A problem that ConsoleKit and logind is trying to address is handling 
permissions to access devices.

Traditionally on *nix machines this was done with user groups, e.g. 
members of 'audio' would have full (read/write) access to all audio 
devices and members of 'video' would have full access to video cards or 
web-cams.

The problem with this approach is that it's not fine-grained enough, 
i.e. it can't distinguish between users logged in locally or via ssh. 
This means Mallory could easily spy on Alice remotely, just by being a 
member of 'audio' and 'video'.

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-15 Thread Brad Rogers

On Wed, 15 Oct 2014 21:44:30 +0100
Joe j...@jretrading.com wrote:

Hello Joe,

It is *not* OK to silently delete an already accepted email, it does

Unfortunately, it happens;  Send an email with a large attachment(1) and
there are quite a few servers that will silently drop it.  The worst of
it is you can never know for certain if you're going to get bitten
because routing can vary.

(1) 4Meg or so used to do the trick.  Things might be different now as
more and more messages contain massive amounts of HTML and imagery.

-- 
 Regards  _
 / )   The blindingly obvious is
/ _)radnever immediately apparent
You destroyed my confidence, you broke my nerve
Nervous Wreck - Radio Stars


pgp_apVXIOFzl.pgp
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Bob Holtzman

On Wed, Oct 15, 2014 at 12:42:58PM -0400, Steve Litt wrote:
 On Wed, 15 Oct 2014 09:08:26 +0100
 Martin Read zen75...@zen.co.uk wrote:
 
  On 14/10/14 22:56, Steve Litt wrote:
 
   And how were they handling this task before systemd?
  
  They were using ConsoleKit, which was orphaned upstream some time
  after systemd-logind came along.
 
 I rest my case.

That's along the lines of what I was wondering, re: the sysv 
option being maintained for more than a short period.

-- 
Bob Holtzman
Giant intergalactic brain-sucking hyperbacteria 
came to Earth to rape our women and create a race 
of mindless zombies.  Look!  It's working!


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Joel Rees

2014/10/16 5:59 Andrei POPESCU andreimpope...@gmail.com:

 On Mi, 15 oct 14, 09:46:47, The Wanderer wrote:
 
  I suspect that the answer is they just didn't provide the functionality
  which ConsoleKit, and later systemd-logind, now enable them to provide,
  but I'm not aware - in a clear-understanding, defined-boundaries sense -
  of exactly what that functionality is, or of why it would be necessary
  or otherwise valuable, or of what the problem is which that
  functionality was intended to address.

 A problem that ConsoleKit and logind is trying to address is handling
 permissions to access devices.

 Traditionally on *nix machines this was done with user groups, e.g.
 members of 'audio' would have full (read/write) access to all audio
 devices and members of 'video' would have full access to video cards or
 web-cams.

 The problem with this approach is that it's not fine-grained enough,
 i.e. it can't distinguish between users logged in locally or via ssh.
 This means Mallory could easily spy on Alice remotely, just by being a
 member of 'audio' and 'video'.

 Hope this explains,
 Andrei

Two thoughts that this problem brings to mind --

(1) Why should it matter? Local? Remote? A hole is a hole.

(1.5) How does ssh deal with making connections private? Any clues there?

(2) There are times when I don't want to have to be logged in as an admin
user to be able to make an ephemeral group. I've understood that for ten
years. When am I going to make the time to construct the package to manage
it within the standard unix permissions model?

:-(

Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Chris Bannister

On Wed, Oct 15, 2014 at 12:30:26PM -0400, Steve Litt wrote:
 
 I completely understand not reinventing the wheel, but if all you need
 is a spoke, you don't construct an interface to a whole wheel just to
 get your spoke.

A wise old owl lived in an oak
The more he saw the less he spoke
The less he spoke the more he heard.
Why can't we all be like that wise old bird?

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015231334.GG27779@tal

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Joel Rees

2014/10/16 8:14 Chris Bannister cbannis...@slingshot.co.nz:

 On Wed, Oct 15, 2014 at 12:30:26PM -0400, Steve Litt wrote:
 
  I completely understand not reinventing the wheel, but if all you need
  is a spoke, you don't construct an interface to a whole wheel just to
  get your spoke.

 A wise old owl lived in an oak
 The more he saw the less he spoke
 The less he spoke the more he heard.
 Why can't we all be like that wise old bird?

There are generalisms like monolithic is a problem.

And then there are generalisms like Engage brain, then engage mouth.

I might wonder which is more on-topic here.

 --
 If you're not careful, the newspapers will have you hating the people
 who are being oppressed, and loving the people who are doing the
 oppressing. --- Malcolm X

--
Joel Rees

Re: piece of mind (Re: Moderated posts?)

2014-10-15 Thread Jonathan de Boyne Pollard


wande...@fastmail.fm:

I have a similar lack of  awareness and/or understanding about all of

 the *kit packages / projects / tools / what-have-you, actually; I'm
 not positive I even know how many there are, much less all of their
 names.

This should help:

Put yourself in the position of someone writing a desktop system for 
Linux and the BSDs.  You've reached the part where you're writing a 
control panel gadget for allowing system administrators (and 
appropriately privileged users) to manage things like the system time, 
the hostname, the default locale, and so forth; and another computer 
management gadget for letting the desktop user see who is logged on 
where and suchlike.  It's a right old mess. You have to determine not 
only what kernel you are running on but what distribution you are 
running on, and access different things in different places.  You could 
find yourself variously having to make your programs read and parse 
/etc/locale.conf, /etc/default/locale, /etc/sysconfig/i18n, 
/etc/sysconfig/language, or /etc/sysconf/i18n, for just one example.  
Then there are things like fundamental differences in the utmpx binary 
logs (The BSDs have revamped theirs and got rid of some stuff.), the 
system account database (It's an actual database on most BSDs.), the 
naming systems for virtual console devices, subtle differences in 
configuration file syntax (to some, a configuration file may be a shell 
script that sets shell variables, to others, it's a list of key=value 
pairs), ...


Enter the kits, twice since renamed.

Skipping a lot of history, such as where ConsoleKit begat systemd-logind 
became logind for one, what we have now is a suite of remote procedure 
calls that your gadgets can call.  There's a hostname API, a 
timedate API, a locale API, and a login API.  They're a whole 
bunch of RPC calls that are made using an inter-process communication 
system known as the desktop bus, D-Bus.  (D-Bus, in its turn, is built 
on top of sockets.  It has all of the usual RPC stuff that has been 
done several times before, such as marshalling and unmarshalling, 
mechanisms for rendezvous between clients and servers, and API 
definitions.  It incorporates a security system to allow servers to 
restrict access to certain RPC functions to only suitably privileged 
clients.)


* http://freedesktop.org/wiki/Software/systemd/hostnamed/
* http://freedesktop.org/wiki/Software/systemd/timedated/
* http://freedesktop.org/wiki/Software/systemd/localed/
* http://freedesktop.org/wiki/Software/systemd/logind/

These RPCs are supplied by server daemons, that communicate with client 
programs (e.g. the aforementioned gadgets) over D-Bus.  The operating 
system specific stuff, such as exactly what configuration file contains 
the static hostname on the system, is intended to be contained within 
these server daemons.  All that a client knows is that it makes the set 
the static hostname RPC call, and some server does the necessary work 
whatever that is. The Debian systemd package comes with its own 
implementation of these server daemons. Contrary to the recommendation 
of the GNOME people almost three years ago, but in line with what the 
systemd people prefer, on Debian they aren't packaged separately and are 
indivisible from the remainder of the package.


* 
https://mail.gnome.org/archives/distributor-list/2012-January/msg3.html


This is what three years' worth of hoo-hah has, at its root, all been 
about: a packaging decision.  I'm not going to summarize or re-hash the 
hoo-hah here.  Suffice it to say that there are both engineering 
rationales and socio-political rationales for the decision, and the 
major problem is logind, the systemd server daemon that provides the 
login API.  Even though the other three somewhat are (modulo the fact 
that they all pick the particular choices of configuration file 
locations that match what other programs in the systemd package, such as 
systemd-machine-id-setup, use), logind is not at all severable from the 
rest of the systemd package, because the operating-system specific 
underpinnings of it (These daemons are intended to be abstracting a 
whole bunch of operating-system-specific non-portable stuff, remember.) 
target a Linux system that is running the systemd daemon and its 
ancillary daemons and utilities.  Naturally enough.


The systemd versions of these daemons are not the only ones in 
existence.  A chap with the unlikely name of Ian Kremlin, for one, is in 
the process of writing his own implementations of these four daemons, 
speaking the same RPC APIs over D-Bus but having the operating-system 
specific underpinnings that are suitable for the BSDs.  This a good 
thing from the point of view of keeping the protocol specifications 
honest (as a heterogeneous set of implementations often does), and it is 
an example of what the GNOME people and the systemd people expected: a 
separate suite of operating-system-specific daemon programs for each

Re: Moderated posts?

2014-10-15 Thread lee

Andrei POPESCU andreimpope...@gmail.com writes:

 On Du, 12 oct 14, 18:47:09, lee wrote:
 Andrei POPESCU andreimpope...@gmail.com writes:
 
  On Mi, 08 oct 14, 16:01:37, Jonathan Dowland wrote:
  
  The tech-ctte exploration was extremely thorough, entirely transparent 
  and I
 
  In addition, the tech-ctte took special precautions to make sure their 
  decision is over-ridable by simple majority (50% + 1), despite the 
  Constitution requiring a 2:1 majority.
 
 So they weren't entirely sure about their decision?

 It's all in the debate, but I'll spare you reading it all just for this: 
 they wanted to avoid a situation where more than half of the developers 
 might vote against their decision (whatever it would be), but not enough 
 to reach the majority required by the constitution.

Thank you.  And why did they want this?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tq8zzc9@yun.yagibdah.de

Re: Moderated posts?

2014-10-15 Thread Don Armstrong

On Thu, 16 Oct 2014, lee wrote:
 Thank you.  And why did they want this?

If the CTTE had chosen a solution which was unacceptable to the majority
of the project, we wanted that majority to be able to override us even
if it wasn't a 2:1 majority.

You can see this discussion in the bug too, and in the IRC logs where we
were drafting the options.

-- 
Don Armstrong  http://www.donarmstrong.com

nothing except the impossible shall occur
 -- e.e. cummings XLII _1 x 1_


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016003424.gn4...@teltox.donarmstrong.com

Re: Recipient validation - WAS: Re: Moderated posts?