July 1, 2009 at 17:14Simplify filtering notifications from web services
Any serious web service has its own email notification system. Sending email messages accompanies user registration, is used to reset the password and confirm important actions, alert letters remind you of the occurrence of certain events. Administrators and service moderators receive even more messages - they are often informed about “every sneeze” of their wards.
This entire stream of messages, flavored with personal letters and densely mixed with spam, falls into a single mailbox, after which the task arises of “separating the grains from the chaff” and bringing the first to some structure, which then allows you to figure out where what is. To filter letters, they must contain some information that allows the mail client to determine how to process this letter. In fact, there are few options, and all of them are reflected in the list of message filter conditions. You can send letters with different topics from different addresses (use different names 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 method free from these disadvantages.
According to the standards for email messages (for example, RFC 2822), any number of optional fields that may contain any information are allowed in the message header. The main condition is that the names of such fields should not coincide with the standard ones. For the guaranteed absence of matches, we agreed that such fields will begin with the prefix “X-” (the Latin letter “X” and the minus sign). It is clear that the fields must also follow common standards, in particular, have a string length of not more than 998 characters (recommended no more than 78 characters). 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 space character.
In relation to our problem of filtering messages, the following is proposed: in each message sent by the service, include at least an identifier field for the type of event (for example, X-Event-Type) in which to describe (of course, with a short phrase in Latin - for the computer we write, not for the person) what caused the arrival of this message. For example, for the administrator, X-Event-Type: NewUser will accompany letters about registering a new user, and for the moderator of the forum, X-Event-Type: MsgBadWords will notify you when the filter of obscene words for a new message is activated. Then in the filter of the mail client a rule is easily created that will select letters with the desired 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 "Configure" line at the very end of the field list in the condition. An automatic anti-spam protection will be a nice additional effect, because none of the spammers will send out emails with a personal value for you as “some incomprehensible not described anywhere” field.
About the implementation: additional fields in the message header can be easily added using your language - read the documentation for 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 sending it to sendmail or another MTA, then entering the necessary fields into the header is even easier.
Of course, it is possible and necessary to add other header fields if this helps the processing of messages, in accordance with the nature of the web service. I don’t bring a ready-made solution, but only present an idea, a way that can help you improve your project.
This entire stream of messages, flavored with personal letters and densely mixed with spam, falls into a single mailbox, after which the task arises of “separating the grains from the chaff” and bringing the first to some structure, which then allows you to figure out where what is. To filter letters, they must contain some information that allows the mail client to determine how to process this letter. In fact, there are few options, and all of them are reflected in the list of message filter conditions. You can send letters with different topics from different addresses (use different names 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 method free from these disadvantages.
According to the standards for email messages (for example, RFC 2822), any number of optional fields that may contain any information are allowed in the message header. The main condition is that the names of such fields should not coincide with the standard ones. For the guaranteed absence of matches, we agreed that such fields will begin with the prefix “X-” (the Latin letter “X” and the minus sign). It is clear that the fields must also follow common standards, in particular, have a string length of not more than 998 characters (recommended no more than 78 characters). 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 space character.
In relation to our problem of filtering messages, the following is proposed: in each message sent by the service, include at least an identifier field for the type of event (for example, X-Event-Type) in which to describe (of course, with a short phrase in Latin - for the computer we write, not for the person) what caused the arrival of this message. For example, for the administrator, X-Event-Type: NewUser will accompany letters about registering a new user, and for the moderator of the forum, X-Event-Type: MsgBadWords will notify you when the filter of obscene words for a new message is activated. Then in the filter of the mail client a rule is easily created that will select letters with the desired 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 "Configure" line at the very end of the field list in the condition. An automatic anti-spam protection will be a nice additional effect, because none of the spammers will send out emails with a personal value for you as “some incomprehensible not described anywhere” field.
About the implementation: additional fields in the message header can be easily added using your language - read the documentation for 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 sending it to sendmail or another MTA, then entering the necessary fields into the header is even easier.
Of course, it is possible and necessary to add other header fields if this helps the processing of messages, in accordance with the nature of the web service. I don’t bring a ready-made solution, but only present an idea, a way that can help you improve your project.