Re: Breaking The Rules

[chromatic]

In summary, don't blindly follow the rules or be afraid to break them.

Unless you're writing an e-mail address parser or a form data parser or a network server or dealing with external, tainted data or plan to use your program more than once or have to deal with a well-established file format, or....

[Limbic~Region]

chromatic,
The rest of that two line paragraph you omitted reads: Think for yourself and make sound judgements.

Let me make it clear that I am not suggesting these rules don't exist for good reason or that following them is not a good idea. My point was that the exceptions are not universal and that careful experimentation results in experience to know what to follow and when. Being careful requires the coupling of common sense and prudence.

Unless you're writing an e-mail address parser...

In my meditation, I state that while looking for the things that could go wrong (prudence), you will need to utilize your situation specific context to know how, if at all, to apply this information. So what are my existing wheels for parsing email addresses:

• Email::Valid
• Regexp::Common::Email::Address
• Email::Address
• Data::Validate::Email

All but the last deal with RFC-822 and/or RFC-2822. These would be useless if the purpose I was parsing was to find addresses attempting to expliot an open-relay. This is because addressesses such as [e-mail]%blah.net are valid by the RFC but result in the vulnerable MTA responsible for the blah.net MX record in stripping off the %blah.net and redirecting the message for [e-mail].

Ok, so I use Data::Validate::Email which supports RFC 822 addresses but has "real-world" flavor as well. This still we do me no good if my objective is to find addresses that fit a specific pattern. It is a case of the general purpose tool not working for the specific problem space.

I have updated the original meditation with a closing paragraph and provided a reply that I believe helps explain my position.