Simplify filtering of notifications from web services
Any serious web service has its own email notification system. Sending emails accompanies user registration, is used to recover a password and confirm important actions, and alert letters remind you of certain events. Even more messages are received by administrators and moderators of services - they are often informed about the “every sneeze” of their wards.
This whole stream of messages, flavored with personal letters and densely mixed with spam, falls into a single mailbox, after which the task of “separating the wheat from the chaff” arises and bringing the former into some structure, allowing later to figure out where what. To filter letters, they must have some information that allows an email client to determine how to process this email. The options, in fact, are few, and they are all reflected in the list of message filter conditions. You can send emails with different topics from different addresses (use a different name in name@domain.tld for each type of message). You can use the subject line or add special prefixes like [SERVICE-EVENT] to it. All this does not improve the readability of messages and can lead to various problems. However, there is a way free from these disadvantages.
According to the standards for email messages (for example, RFC 2822), any number of optional fields are allowed in the message header, which can contain any information. The main condition is that the names of such fields should not coincide with the standard ones. For the guaranteed absence of coincidence, we agreed that such fields will begin with the prefix “X-” (Latin letter “X” and the sign “minus”). It is clear that the fields must also follow general standards, in particular, have a length of not more than 998 characters (no more than 78 characters are recommended). When transferring the value to the next line, the CRLF combination (carriage return, code 13, then line feed, code 10) must be inserted before the whitespace character.
')
With regard to our problem of filtering messages, the following is proposed: include in each message sent by the service at least an identifier field of an event type (for example, X-Event-Type), in which to describe (of course, a short phrase in Latin - we write for a computer, not for a person) What caused this message. For example, for the administrator, X-Event-Type: NewUser will accompany the registration of a new user, and for the forum moderator, X-Event-Type: MsgBadWords will notify you when an obscene word filter is triggered for a new message. Then, in the mail client filter, it is easy to create a rule that will select letters with the required value of the specified field and put them in the appropriate folder. In particular, in the popular Thunderbird, to set a new field name, select the “Customize” line at the very end of the list of fields in the condition. A pleasant additional effect will be automatic spam protection, because none of the spammers will send out emails with the personal meaning for you of “some kind of field that cannot be described anywhere”.
On implementation: additional fields in the message header are easily added by means of your language — read the documentation on the functions by which you send mail. For example, in PHP, the mail function, with its fourth argument, takes a string with additional header fields, separated by CRLF. If you manually compose a message before giving it to sendmail or another MTA, then it is even easier to enter the necessary fields in the header.
Of course, it is possible and necessary to add other header fields, if this helps in processing the messages, in accordance with the nature of the web service. I do not provide a ready-made solution, but only present an idea, a way that can help you to improve your project.
This whole stream of messages, flavored with personal letters and densely mixed with spam, falls into a single mailbox, after which the task of “separating the wheat from the chaff” arises and bringing the former into some structure, allowing later to figure out where what. To filter letters, they must have some information that allows an email client to determine how to process this email. The options, in fact, are few, and they are all reflected in the list of message filter conditions. You can send emails with different topics from different addresses (use a different name in name@domain.tld for each type of message). You can use the subject line or add special prefixes like [SERVICE-EVENT] to it. All this does not improve the readability of messages and can lead to various problems. However, there is a way free from these disadvantages.
According to the standards for email messages (for example, RFC 2822), any number of optional fields are allowed in the message header, which can contain any information. The main condition is that the names of such fields should not coincide with the standard ones. For the guaranteed absence of coincidence, we agreed that such fields will begin with the prefix “X-” (Latin letter “X” and the sign “minus”). It is clear that the fields must also follow general standards, in particular, have a length of not more than 998 characters (no more than 78 characters are recommended). When transferring the value to the next line, the CRLF combination (carriage return, code 13, then line feed, code 10) must be inserted before the whitespace character.
')
With regard to our problem of filtering messages, the following is proposed: include in each message sent by the service at least an identifier field of an event type (for example, X-Event-Type), in which to describe (of course, a short phrase in Latin - we write for a computer, not for a person) What caused this message. For example, for the administrator, X-Event-Type: NewUser will accompany the registration of a new user, and for the forum moderator, X-Event-Type: MsgBadWords will notify you when an obscene word filter is triggered for a new message. Then, in the mail client filter, it is easy to create a rule that will select letters with the required value of the specified field and put them in the appropriate folder. In particular, in the popular Thunderbird, to set a new field name, select the “Customize” line at the very end of the list of fields in the condition. A pleasant additional effect will be automatic spam protection, because none of the spammers will send out emails with the personal meaning for you of “some kind of field that cannot be described anywhere”.
On implementation: additional fields in the message header are easily added by means of your language — read the documentation on the functions by which you send mail. For example, in PHP, the mail function, with its fourth argument, takes a string with additional header fields, separated by CRLF. If you manually compose a message before giving it to sendmail or another MTA, then it is even easier to enter the necessary fields in the header.
Of course, it is possible and necessary to add other header fields, if this helps in processing the messages, in accordance with the nature of the web service. I do not provide a ready-made solution, but only present an idea, a way that can help you to improve your project.
Source: https://habr.com/ru/post/63352/
All Articles