(conditionally) forbidding the creation of tickets via e-mail
Olivier Macchioni <[email protected]>
| Newsgroups | gmane.comp.otrs.user |
|---|---|
| Message-ID | <[email protected]> |
Hello dear OTRS list, I'm faced with the current challenge. For incoming e-mails read by OTRS (IMAP or POP), I need the following behaviour: 1- OTRS ticket number in the ticket -> add an article to the corresponding ticket, as usual 2- Whitelisted sender e-mail address -> create a new ticket, as usual 3- Other sender e-mail address -> send a specific e-mail to the sender, ie "You cannot create a ticket this way, please use our contact form" and don't record anything in OTRS And do this only for certain specific IMAP / POP boxes... It would possibly be acceptable to still accept the e-mails in the case (3) but move them to another queue or auto-close them. This doesn't seem to be a feature available out-of-the box. Does anyone have an idea on how to manage such cases? I'm thinking I could work with Kernel::System::PostMaster::Filter::CMD - the script would analyse if the mail falls in category (3) and if yes, set X-OTRS-Ignore Of course to evaluate (1) I'll need to do some heuristics based on the format of the ticket... or connect to the OTRS DB and do a lookup, which is a bit more complex. but the heuristic should more or less work. Would this be the best approach?... Any other suggestion? Thanks, Olivier --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs
signature.asc
(application/pgp-signature, 842 B)
-----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJX/P1+AAoJENdndzcwiKNexTsP/2vMxESU5S1pdhTq1HR5sttj Gnoy+o5tRmQSsoRP3c4tp21w71haS/Z76zWLZNVH4NPlg7n80gMbJcmTWnb+iPGp 7kgq/UvlT31WvokwSjAq4aDFQSrbwtmwQymW7sdWaoWGQkOPubKnEr638eJIUHdz 0osWHt+25zCCcIL+RkT3srlGyqF6tn31E2Y+Ymmo1KZA1GhtglX5Xo8Du21QUEcT uUFqSXc+vBh2etV0WUtS4atGxcGcMuyLB1lRONR4+VT/LmxqI2t7q/OYC1ybUC0x JXLOh8Eqc5JCUdDMrdJ2WI+mLGlO/BxqTGabmYYrRvuNgXbLKoIyu+E2ZD2EDiLq KZgrFfn8rD3udcwzpDQ0GbHec3q6Vp1C2hh5wzO1jS4+06fsxFjfk5gXZHzi6/2E XhQw0gX2luekswP8DbLrpXTTJ1db2C/Tl0ZMTshjfPJaVv1bD/XFnSEuUQM0sTlR qBpVAzXqMRB84WVBEhD1zKlXQH0OLQ1W6t0CGToecvPGXsMrF40vxnOxntqFqmBZ LvnSP+YXty2Ij8wIS0aA12gRO9rWo/LMnHc6BQyB+l1LcCBZhsBPqA/HOB8ARNTI dzLMsYPFdn7uY7CAw6mfY2FPiKQIcKWXBesFOIZknatmv/PnEiRl/LbGaD06q7l9 e9sguOSg/jVndhBnjnSK =QQ1Y -----END PGP SIGNATURE-----