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