Programmers with network engineering skills
Steve Bertrand
steve.bertrand at gmail.com
Tue Mar 13 22:20:15 UTC 2012
On 2012-03-13 16:33, Joe Greco wrote:
>> Joe Greco wrote:
>>> The ideal world contains a mix of techniques.
>>
>> Yes and copying parts of relevant code of an MTA could be one.
>
> May actually be one of the few sane ones.
>
>>> You cannot just blindly leave it to the MTA to decide what's valid.
>>> Along that path lies madness. How do you pass the address to the MTA?
>>> Don't do it as a system() call unless you want someone to own your
>>> box with a semicolon.
>>
>> Well, the whole world can pass whatever it wants to an MTA, it's
>> supposed to be listening on internet facing port 25 all the time, that's
>> it's mean reason of existence. An MTA is particularly well suited to
>> take any kind of abuse, because that's exactly what it's expecting.
imo, this discussion of outbound SMTP has been sounding akin to me
saying I should let my upstream ensure that all of my BGP announcements
are good, instead of filtering my own outbound.
>> Unless in cases such as Owen mentioned I'd say it's a pretty good
>> solution. The madness to me lies in making your own email validating code...
>
> This is probably one of those things where the spec was good when it
> was written for reasons that were good at the time, but now many years
> later in a generally completely FQDN-ified world, there's little valid
> reason to need to be able to support some of the odd possible syntaxes
> that we used twenty or thirty years ago.
>
> The problem is, current programmers look at the evil spec, say "fooey
> with that," and then code up something that is too unreasonably
> restrictive in the opposite direction.
There are ready-made solutions that abstract away the need for the
programmer to write their own regex or compliance checks to meet the specs.
In Perl for example, there is Email::Valid. One line of code and you
know whether the address is to RFC or not. Less bugs and changes, I feel
it is better to give the remote host known-good data then have to have
them tell me it is bad.
Steve
disclaimer: I've wrote patches for said module over the years, and I
named it only for example purposes.
More information about the NANOG
mailing list