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).

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

You could write some other web app that allows users to create a user account/record in a separate database/table/ldap and then point OTRS at that data source for customer information. That would allow you to easily customise the logic behind account creation. Or hack the OTRS code to add in some email address checking to the user registration component (remember to diff your changes so you can reapply on an update). Steve On 28 August 2012 20:40, brianmortonb2b-atwork@yahoo.dk wrote:

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 To: "brianmortonb2b-atwork@yahoo.dk" ; User questions and discussions about OTRS. 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 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

--------------------------------------------------------------------- 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

Thank you for that. I'm quite new to OTRS but thrilled about the quality of documentation, responsiveness of the community, etc. I've only just 'discovered' the OTRS IdeasScale site and I will log the idea there. The fact that OTRS Ideas site exist (and seems to get good attention) is just another credit to the community and the company behind OTRS. Ok, the idea proposed in this thread is now in https://otrsteam.ideascale.com/. Thx Brian ________________________________ From: Michiel Beijen To: "brianmortonb2b-atwork@yahoo.dk" ; User questions and discussions about OTRS. Sent: Wednesday, August 29, 2012 8:37 AM Subject: Re: [otrs] Restricting the self-registration feature Hi Brian, On Tue, Aug 28, 2012 at 5:33 PM, brianmortonb2b-atwork@yahoo.dk wrote:

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.

As stated, this functionality is not built-in to OTRS; it would be possible and not very difficult to add it. I could see how you can store a domain (or multiple domains, i.e. in your example, also ikea.dk or ikea-office.com or...) on the customer company record, then check at registration time against the known valid domains, and then reject or accept the registration for new customers based on the domain. However, it is not an OTRS feature, so it would require some development to add it in. -- MIke

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 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

...

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

When I setup a new Mail Account I can chose Dispatching Dispatching by selected Queue or Dispatching by email To: field Today I have choosen Dispatching by selected Queue on both queue. Would it solve mu problem if I change to the other option? Thanks 2012/8/28 David Boyes

If two separate messages are delivered to two separate inboxes, then yes, there should be one response per incoming email per mailbox. If the email is delivered to one of the mailboxes with multiple addresses in the To: field, no, I wouldn’t expect that to happen (at least it wouldn’t be useful in my environment). ****

** **

Is the idea that support@company1.com and support@company2.com are two completely separate POP accounts that point to different queues in the same OTRS instance, and if the email is sent to both addresses, you want two responses? I guess I’m not following what you’re trying to accomplish here. ****

** **

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Jean BROW *Sent:* Tuesday, August 28, 2012 4:00 PM *To:* User questions and discussions about OTRS. *Subject:* Re: [otrs] Get emails double****

** **

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?****

** **

** **

--------------------------------------------------------------------- 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

We have to POP 3 addresses in the system - support@companyONE.com support@companyTWO.com If a customer send e-mail to support@companyONE.com he get the auto-replay from this queue. If the customer send e-mail to support@companyTWO.com he get auto-replay from this queue. If a customer send e-mail at the same time to support@companyONE.com and support@companyTWO.com (he write both e-mail addresses in the "to felt") then he will ONLY get auto-replay from support@companyONE.com, and it will be generated 2 uniqe tickets in the queue who belong to support@companyONE.com. What I want - If a customer send e-mail to support@companyONE.com and support@companyTWO.com at the SAME time (in the "to felt") it should be sent out one auto replay from each queue, and generated an ticket number in each queue. Thanks in advance for all good help. Greetings from Australia. 2012/8/30 Steven Carr

I'm not quite sure what the problem is to be honest, you haven't detailed why you wouldn't want this to happen. You need to explain what you would expect/like to happen when an email is sent to both addresses, then we can see if we can help with the configuration.

But it sounds like in your case, dispatch incoming emails direct to the queue. The reason being is that the To address on the CC'd email will be the address of the first queue, so you need to force that email to be dispatched into the second queue so that the correct response is sent back.

Steve

On 30 August 2012 21:46, Jean BROW wrote:

...

When I setup a new Mail Account I can chose

Dispatching Dispatching by selected Queue or Dispatching by email To: field

Today I have choosen Dispatching by selected Queue on both queue. Would it solve mu problem if I change to the other option?

Thanks

--------------------------------------------------------------------- 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