From: "Ronald F. Guilmette" <r...@tristatelogic.com>
>
> In message <7E7181F2497441C88988DD1F16E4A743@octavianf303f0>, you wrote:
>
>>From: "Janek Schleicher" <janek_schleic...@yahoo.de>
>>
>>> Am 24.10.2013 15:07, schrieb Shawn H Corey:
>>>>> my $email = Email::Simple->create(
>>>>> header => [
>>>>> From => $sender_addr,
>>>>> To => 'ad...@tristatelogic.com',
>>>>> X-Server-Protocol => $server_protocol,
>>>>> X-Http-User-Agent => $http_user_agent,
>>>>> X-Http-Referer => $http_referer,
>>>>> X-Remote-Addr => $remote_addr,
>>>>> X-Remote-Host => $remote_host,
>>>>> ],
>>>>> body => $message
>>>>> );
>>>>
>>>> Why are you using an anonymous array for the header? Wouldn't an
>>>> anonymous hash be better? A hash would insist on an even number of
>>>> elements.
>>>
>>> I just followed the synopsis of the documentation of this CPAN-Module as
>>> you can find it here: https://metacpan.org/pod/Email::Simple :-)
>>>
>>> I agree to you, that a ref to a hash like header => { ... } would somehow
>>> be more logic, but I didn't wrote this CPAN module.
>>>
>>>
>>
>>Aren't duplicate headers allowed in email headers?
>
> Yes.
>
> The vast majority of all the e-mail I have in my big piles of e-mails
> has multiple Received: headers, in particular. And yes, order matters
> with respect to interpreting those (but also it matters in the case of
> other headres sometimes too.)
>
>
> But, getting back to my original 2 questions...
>
> I want to stress that I did not ask how to formulate and/or send a
> properly formatted e-mail message. I can handle that part, even if
> perhaps only in my own clumsey way.
>
> What is of more interest to me, again, is the question of how to properly
> validate (a) a string that's given on a form and which is meant to
> represent a person's name, an also (b) a string that is given in a form
> and that is supposed to represent a person's e-mail address.
>
> Assume that I want to do both these things *and*, to the maximum extent
> possible, I want to reject any & all strings that are implausible name
> and/or e-mail address strings.
>
> How? What's the code to do each of these things.
>
> These certainly should both be well-solved problems by now, but in case
> they aren't, I'd like to take my own humble wack at developing good
> solutions for both problems.
I think that what you want is not possible. :-)
I mean, I don't think it is possible to create a rule that simply filters out
all strings which can't be names or all strings that can't be email addresses,
without filtering out good names and email addresses, of course.
There are many language scripts that can be use to write the names with, and
that filter should not filter the names written with
chinese/japanese/arabic/kirilic/hebrew and many other exotic scripts used with
8-bit encodings or with Unicode.
If you just want to filter the names which are not English-like names, you can
deny anything which is not [a-zA-Z0-9\s.'-].
If you want to also allow some Unicode letters and not only A-Za-z, you can use
\p{L} or \p{Letter} instead of A-Za-z.
But there may be strange chars composed from a letter followed one or more
diacritic signs, so the regexp may need to be more complex.
Regarding the email addresses... the RFCs allow many types of email addresses
which are almost never used now.
I don't know if there is a current RFC or standard that defines the rules for
an email address which is currently used by most email services. The filter
could be based on that rule, but it might filter out some valid exotic email
addresses. On the other hand, if the existing rules are used, they may allow
strings which look like a valid email address, even if that kind of email
address is not used by nobody these days.
So these filters could be strict and allow only the most expected name and
email formats, but they might disallow some valid emails and names, or they can
accept all the possible formats (like Email::Valid does in case of an email
address), but then you can get strange formats that your software can't handle.
It could be helpful if you'd have the rules for the email formats accepted by
your email server.
If the email addresses follow that rule it means that they are OK. If they
don't follow it, then it doesn't matter that the addresses are valid, because
they can't be handled anyway.
Octavian
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
