Hello Robin,

Of course you want to focus on adding field support since you've
made a public commitment to do so, but does that mean I have to

If you'd like to, that's an option :)

It seems to me that your address validation code is just plain
wrong to be rejecting/trashing valid email addresses,

None of the email address validity code is mine - this is marked in
the code itself

You didn't address my concern that the regex expression you're
using for address validation is indecipherable to humans In your
source code there's a comment that points to a URL that is supposed
to help explain it, but that link is invalid In any case, that
particular line of code looks like gibberish, an unwise design
choice See code enclosed below

Yeah - I have no idea what it says To say it's, "indecipherable to
humans" is probably incorrect, since, I think it was written by one
Saying it is, "indecipherable to most humans, just by glancing
over the code" - yeah, you're probably correct :)

But, like I state, the code isn't mine If you look at the bottom of
that file, you'll see this:

[snip]

=head1 CREDITS

Significant portions of this module are based on the ckaddr program written by Tom Christiansen and the RFC822 address pattern developed by Jeffrey Friedl Neither were involved in the construction of this module; all errors are mine

Thanks very much to the following people for their suggestions and bug fixes:

Otis Gospodnetic otis@DOMINIS com Kim Ryan kimaryan@PROTECTED au Pete Ehlke pde@PROTECTED Lupe Christoph David Birnbaum Achim Elizabeth Mattijsen (liz@dijkmat nl)

[/snip]

Saying all that, this code isn't even used in Dada Mail - it
actually has it's own email-validity check, which is located in dada/ DADA/App/Guts pm and looks sort of like this:

[snip]

sub check_for_valid_email {

This subroutine is modified out of BulkMail 2 0 by

James A Thomason III (jim3@psynet net)

Thanks James

 my $email = shift or undef;
 my $email_check = 0;

 my $atom = q<[!#$%&'*+\-/=?^`{|}~\w]>;
 my $qstring = q/"(?:[^"\\\\\015]|\\\
)+"/;
 my $word = "($atom+|$qstring)";
 $email =~ m/^$word\s*\<\s*(
+)\s*\>\s*$/;            #match  

beginning phrases

 $email = $2 if $2;                                    #if we've  

got a phrase, we've extracted the e-mail address #and stuck
it in $2, so set $email to it #if we
didn't have a phrase, the whole thing is the e-mail address

unless($email =~ m< ^\s*($word #any word
(see above) (?: $word)* #optionally
followed by a dot, and more words, as many times as we'd like @ #and an at
symbol $atom+ #followed
by as many atoms as we want (?: $atom+)* #optionally
followed by a dot, and more atoms, as many times as we'd like [a-zA-Z]{2,4})\s*$ #followed by
2 or 4 letters

xo){ $email_check = 1;

}

 my %exceptions;
 foreach(@EMAIL_EXCEPTIONS){$exceptions{$_}++}
 $email_check = 0 if exists($exceptions{$email});
 return $email_check;

}

[/snip]

Which is a lot simpler and is speckled with comments to help clarify
what's going on

The, Email::Valid module, that you're referencing is only used for
the mx_check method, I believe

Just an opinion, your code generally uses a little too much Perl
wizardry and hackerisms to be easy to maintain for others I've
seen worse in other projects, but better is possible It would be
helpful if all the code was in subroutines so there are clear entry
and exit points Perl doesn't require this, but doing so makes
large projects easier to understand

I hope I addressed most of these concerns, but I do disagree with
almost everything you say in these statements :) My Perl skills and
style are fairly straightforward The Email::Valid module (the one
that is not mine) - especially that bit of code, even though is
incredibly complex in how it does, what it does was written by
someone much much much smarter than me and has been peer reviewed by
people just as smart as him - so much so, that it's been published in
book-form, and the book is on its second edition Email::Valid is
packaged in a reusable module, and for me, or anyone to use it, I
don't have to know exactly how it works - it's a black box All I
need to know is the API, which is explained pretty simply here:

http://search
cpan
org/~maurice/Email-Valid-0
15/Valid
pm

This is pretty commonplace in programming If this wasn't
commonplace, to build anything, I'd have to start with creating an
operating system first, and then the program - safe to say, not many
programs would be created :)

In order to be able to use dada mail I have to be able to import
email addresses non-destructively What you suggest would lose
information To strip off the person names to have bare email
addresses is in no way an acceptable work-around

I'm sorry, at the current state, Dada Mail's the wrong tool to solve
your problem I posted what I thought would be a good solution to a
similar problem, and people agreed with me If you'd like to add this
feature into Dada Mail - I am 100% for it, but I'm currently not
going to do it (probably) at this time I cite this as a design
decision and your arguments have yet to sway me :) In fact, your
argument was, "I don't like how you do things, so change it ", which
isn't really moving me and isn't how I operate

Can you give me any suggestions where in your code I'll need to
make modifications to fix this bug?

* Well, you'd have to change the backend that works with the  

subscription list - most all of that code is in the dada/DADA/ MailingList/Subscribers directory There are currently 3 different
backends for the subscription list, so they'll all have to be adjusted

* You'd also have to change how Dada Mail creates the confirmation  

links to allow for subscribing and unsubscribing That's mostly in
dada/DADA/App/FromatMessages pm

* You'd also have to change how Dada Mail creates the mail headers,  

so it knows that maybe(?) more information than just the address is
present in the subscription information and adjusts this You can
probably change that in, dada/DADA/Mail/Send pm

and anything else I haven't foreseen
 It's a lot of work