From:	<otrs-request@otrs.org>
To:	<otrs@otrs.org>
Date:	2012/08/28 10:08 PM
Subject:	otrs Digest, Vol 47, Issue 54

Send otrs mailing list submissions to
otrs@otrs.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.otrs.org/cgi-bin/listinfo/otrs
or, via email, send a message with subject or body 'help' to
otrs-request@otrs.org

You can reach the person managing the list at
otrs-owner@otrs.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of otrs digest..."

Today's Topics:

   1. Re: Require service/sla (Shawn Beasley)
   2. Re: Restricting the self-registration feature
      (brianmortonb2b-atwork@yahoo.dk)
   3. Re: Get emails double (Jean BROW)
   4. Re: Get emails double (Steven Carr)

----------------------------------------------------------------------

Message: 1
Date: Tue, 28 Aug 2012 20:37:51 +0200
From: Shawn Beasley <shawn.beasley@otrs.com>
Subject: Re: [otrs] Require service/sla
To: "User questions and discussions about OTRS." <otrs@otrs.org>
Message-ID: <5DF90D89-70F8-4355-88F8-B4E8E8E4F555@otrs.com>
Content-Type: text/plain; charset="us-ascii"

you are welcome!

On Aug 28, 2012, at 20:36 , "Gadow, Shawn" <sgadow@ocusd.net> wrote:

> Worked like a charm thank you much
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.otrs.org/pipermail/otrs/attachments/20120828/0c56946d/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 28 Aug 2012 20:40:31 +0100 (BST)
From: "brianmortonb2b-atwork@yahoo.dk"
<brianmortonb2b-atwork@yahoo.dk>
Subject: Re: [otrs] Restricting the self-registration feature
To: "User questions and discussions about OTRS." <otrs@otrs.org>
Message-ID:
<1346182831.91311.YahooMailNeo@web133001.mail.ir2.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

Hmm, I think you are missing the point. Our customers (the organisations) are very well-known to us. The individual users within those organisations are not. We are contractually committed to give support to ANY user from within our customer's organisations. For some of our customers there are literally hundreds of users that we serve within a single customer organisation. We would kill ourselves if we were to set up customer users on a person-by-person basis. And it would probably infuriate our customers to wait for us to do so every time.

There's no way that our customers would hand out anything that looks like a user registry, e.g LDAP or similar. These are well-guarded secrets that cannot even be offered to the government unless required to by law. Corporations treat even the usernames that they use internally as well-guarded secrets that are not to leave the doorstep of the organisation. (the idea is that knowing internal user names within a corporation moves a potential hacker one step closer to his target).

This may all sound as if I cannot use your answer. Far from it. I can use the CAPTCHA idea and will look into it.

Thank you.

Brian

________________________________
From: Gerald Young <crythias@gmail.com>
To: "brianmortonb2b-atwork@yahoo.dk" <brianmortonb2b-atwork@yahoo.dk>; User questions and discussions about OTRS. <otrs@otrs.org>
Sent: Tuesday, August 28, 2012 5:57 PM
Subject: Re: [otrs] Restricting the self-registration feature

http://forums.otterhub.org/viewtopic.php?f=60&t=5941?(reCAPTCHA)
http://forums.otterhub.org/viewtopic.php?f=60&t=6586?(Accept customer only emails as tickets)

or, ddt (don't do that). "our customers should be able to self serve as much as possible."
?"our customers" and "self serve" are contradictory in this sense. If they're your customers, you should already know who they are and have them as customers (link to or import from existing data source). They shouldn't have to register themselves if they're known to you. (Personal opinion). Now, in the case of (large multinational corporation) this may be a bit difficult to obtain and sync all the customers who will be able to create tickets with your company, but on the other hand, if you're that intimate, you may ask to get an ldap connection for Customer queries. That will be helpful in this case:
1) add/remove users is not up to you
2) password management is customer-side (ldap)
3) customer knows her password is the same as office
4) no registration
5) zero administrative communication when users change
6) list is always uptodate
7) you don't burden your customers with registration

On Tue, Aug 28, 2012 at 11:33 AM, brianmortonb2b-atwork@yahoo.dk <brianmortonb2b-atwork@yahoo.dk> wrote:

>Maybe I'm thick but I cannot figure this one out:
>
>I really like the self-registration feature. The idea is that our customers should be able to self serve as much as possible.
>However at the moment anyone can register and I fear that when we go live there will be lots of self-registration attempts by spammers.
>
>In the company I work for the customer organizations are well-known (a dozen or so). The users within them are not (several hundreds).
>
>What I would like is that only users (customers) who register with e-mail domains that are known to the OTRS system are allowed to self-register on the portal.
>Example : We would allow john.doe@ikea.com to self-register because IKEA is a customer of ours and thus "@ikea.com" is a well-known e-mail domain. Conversely if joe.hacker@harmful.com tries to register he should be rejected. (IKEA is not really a customer of ours in real world :-))
>
>Having the above functionality would of course require that OTRS would store a list of known e-mail domains for each customer organization.
>
>But, but. There may be other ways to prevent misuse of the self-registration feature. Perhaps some functionality that already exist?? Any ideas ?
>
>Thx.
>
>
>Brian
>
>
>
>
>
>---------------------------------------------------------------------
>OTRS mailing list: otrs - Webpage: http://otrs.org/
>Archive: http://lists.otrs.org/pipermail/otrs
>To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.otrs.org/pipermail/otrs/attachments/20120828/719536b9/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 28 Aug 2012 22:00:29 +0200
From: Jean BROW <everydaywow@gmail.com>
Subject: Re: [otrs] Get emails double
To: "User questions and discussions about OTRS." <otrs@otrs.org>
Message-ID:
<CAPrubvpOnrwDv+6jXifQJT6E8AY09n7NcbMwc0ArHmjVxxop6A@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

We have 2 different companys running on same OTRS version. Sometimes a
customer send email to both companies at same time in the "to" felt.
Shouldn't OTRS send out 2 seperate auto replay then from each e-mail
addresse in the "to" felt?

Thanks

2012/8/28 David Boyes <dboyes@sinenomine.net>

> You could check the Message-ID: field in the incoming message against a
> search of the current tickets in the OTRS postmaster code, but that would
> be very time-consuming for any volume of mail. I?d go with Gerald?s
> comment: tell them not to do that, and deprecate one of the two addresses
> and remove it in a systematic way (or turn one into an alias of the other
> if for some good business reason both still need to exist). ****
>
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.otrs.org/pipermail/otrs/attachments/20120828/d17a2579/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 28 Aug 2012 21:06:36 +0100
From: Steven Carr <sjcarr@gmail.com>
Subject: Re: [otrs] Get emails double
To: "User questions and discussions about OTRS." <otrs@otrs.org>
Message-ID:
<CALMep07MCF6mL8P=m-kL+TVkoDgrb+1JrjxGiDUuhBRfm3e4=Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

It will only send out different replies if that's how you have
configured it. For example, if you just have 1 queue and both email
addresses filter into that queue then you are only going to have a
single autoresponse from 1 of the addresses. If you have 2 queues and
each email address filters into it's own queue then you can set the
autoresponse for each queue to the appropriate email address.

Steve

On 28 August 2012 21:00, Jean BROW <everydaywow@gmail.com> wrote:
> We have 2 different companys running on same OTRS version. Sometimes a
> customer send email to both companies at same time in the "to" felt.
> Shouldn't OTRS send out 2 seperate auto replay then from each e-mail
> addresse in the "to" felt?
>
> Thanks
>
> 2012/8/28 David Boyes <dboyes@sinenomine.net>
>>
>> You could check the Message-ID: field in the incoming message against a
>> search of the current tickets in the OTRS postmaster code, but that would be
>> very time-consuming for any volume of mail. I?d go with Gerald?s comment:
>> tell them not to do that, and deprecate one of the two addresses and remove
>> it in a systematic way (or turn one into an alias of the other if for some
>> good business reason both still need to exist).
>>
>>
>> ---------------------------------------------------------------------
>> OTRS mailing list: otrs - Webpage: http://otrs.org/
>> Archive: http://lists.otrs.org/pipermail/otrs
>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
>
>
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

------------------------------

---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

End of otrs Digest, Vol 47, Issue 54
************************************

______________________________________________________________________
This inbound email has been scanned by the IS Mail Control service.
For more information please visit http://www.is.co.za
______________________________________________________________________

This message may contain information which is confidential, private or privileged in nature. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message or file which is attached to this message. If you have received this message in error, please immediately notify the sender by e-mail, facsimile or telephone and thereafter return and/or destroy the original message.

Any views contained in this communication are those of the sender except where the sender specifically states them to be those of South African Social Security Agency (SASSA).

While every care has been taken in preparing this document, no representation, warranty or undertaking (express or implied) is given and no responsibility or liability is accepted by the South African Social Security Agency as to the accuracy of the information contained herein, that the mail is virus-free, or for any loss arising therefrom.