You make it sound like typing is the hardest part of developing software. If only that were true. Think of pair programming as a code review that happens instantaneously rather than weeks later when the mistakes in the design have become so much harder to fix (the 1, 10, 100 rule). Think of how much easier it is for you to offer (and your pair to accept) a suggested change before hours of work (and ego) have been invested into a particular design. Successful pair programming isn't about being a typing cop (most of the time I'd bite my tongue on stuff like that). It's about the give and take of two people trying to solve a problem.
Congratulations, you've just broken SMTP! As with the recent Verisign debacle, it's becoming quite clear that people who don't know much about the internet are trying to fix it.
There are a number of problems with the proposed "solution". The most obvious being that it has holes biggest to drive a truck through. Take for instance the following from RFC 821:
One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:
So now I (Joe Spammer) connect to your SMTP server and deliver you some SPAM dressed up as a helpful undeliverable notification (i.e. a bounce). Good luck trying to lookup my domain's SPF record. So you now have the choice:
(a) block bounce messages (your user's will really appreciate that)
(b) block my IP (I'll get another one)
(c) accept the message and let the end user's filters deal with it.
I'm not sure that the SPF scheme does much given the constraints of life on the real internet.
Slashdot Mirror
You make it sound like typing is the hardest part of developing software. If only that were true. Think of pair programming as a code review that happens instantaneously rather than weeks later when the mistakes in the design have become so much harder to fix (the 1, 10, 100 rule). Think of how much easier it is for you to offer (and your pair to accept) a suggested change before hours of work (and ego) have been invested into a particular design. Successful pair programming isn't about being a typing cop (most of the time I'd bite my tongue on stuff like that). It's about the give and take of two people trying to solve a problem.