ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Dolf Schimmel
Hey Guys,

I'm busy on refactoring Zend_Mail. and couldn't help noticing that
email adresses are filtered while adding them. What do you think of
this practice, and should we continue doing it? I'm against filtering,
though I could see reasons to validate. On the other hand, isn't
validating email addresses part of the application responsibilities
instead of that of the component (just like any other user input)?
Obviously, there's no need to validate the same string twice.

What do you think, should Zend_Mail filter, should it validate? Or
should it just leave it up to the app.

Regards,

Dolf
-- Freeaqingme

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Kim Blomqvist
> What do you think, should Zend_Mail filter, should it validate? Or
> should it just leave it up to the app.

+1 leave it up to the app

--
Regards,

Kim


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

cbichis
In reply to this post by Dolf Schimmel
Hi,

If it's added filtering should be optional anyway.

Let's give you a sample where filtering the email address is bad: the
email address could be just an internal alias on the server like: root...

Personally i think filtering should up to the application and not the
Zend_Mail component...

Cristian

> Hey Guys,
>
> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
> email adresses are filtered while adding them. What do you think of
> this practice, and should we continue doing it? I'm against filtering,
> though I could see reasons to validate. On the other hand, isn't
> validating email addresses part of the application responsibilities
> instead of that of the component (just like any other user input)?
> Obviously, there's no need to validate the same string twice.
>
> What do you think, should Zend_Mail filter, should it validate? Or
> should it just leave it up to the app.
>
> Regards,
>
> Dolf
> -- Freeaqingme
>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Wil Moore III
In reply to this post by Dolf Schimmel
> On the other hand, isn't validating email addresses part of the application
> responsibilities instead of that of the component
>

Good catch. This should definitely be left up to the application. +1
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Dolf Schimmel
In reply to this post by Dolf Schimmel
In-app it is then. Thank you all!

Dolf
-- Freeaqingme

2011/5/28 Benoît Durand <[hidden email]>:
> I agree in app.
>
> Greetings
> --
> Benoît Durand

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Bento Vilas Boas
Hi,

For me, it does no make sense to filter emails, passwords or other similar
content (besides functions that don't change content, like trim). They
should be validated.

So, I'm with keeping it in-app.

Best Regards,
Bento Vilas Boas



On 11/05/28 18:44, "Dolf Schimmel" <[hidden email]> wrote:

>In-app it is then. Thank you all!
>
>Dolf
>-- Freeaqingme
>
>2011/5/28 Benoît Durand <[hidden email]>:
>> I agree in app.
>>
>> Greetings
>> --
>> Benoît Durand
>
>--
>List: [hidden email]
>Info: http://framework.zend.com/archives
>Unsubscribe: [hidden email]
>
>

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Thomas D.
In reply to this post by Dolf Schimmel
Hi,

Dolf Schimmel wrote:

> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
> email adresses are filtered while adding them. What do you think of
> this practice, and should we continue doing it? I'm against filtering,
> though I could see reasons to validate. On the other hand, isn't
> validating email addresses part of the application responsibilities
> instead of that of the component (just like any other user input)?
> Obviously, there's no need to validate the same string twice.
>
> What do you think, should Zend_Mail filter, should it validate? Or
> should it just leave it up to the app.

In general I would also say, that it should leave it up to the application. But:

Zend_Mail will - on the other hand - work with other components (PHP's mail() function, multiple mail transports...), which all require valid addresses as parameters. So without validation, we would carry invalid data through our application and Zend_Mail could make invalid calls to other components.

I guess it is not a simple question. It's a question about responsibility and reliability.

When I would set something as address ($mail->setTo()), the setter should make sure, that only valid data will be set. Why? Because when I get the data ($mail->getTo()) I would assume, that I only get valid data.

If Zend_Mail would accept any input, the component wouldn't be reliable and everything which is using Zend_Mail would have to check everything again.

Well, in the end we don't trust anything, so every used component like the mail() function or at least the mail server will do its own check... but when dealing with objects, we *should* assume, that an object only contains valid data.

That's my point of view, I hope you understand what I trying to tell. :-)


--
Regards,
Thomas



--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Regards,
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Marten Lienen
In reply to this post by Dolf Schimmel
I agree with Thomas. The mail object should not be able to have invalid data, but further filtering should be up to the application.

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Dolf Schimmel
In reply to this post by Thomas D.
In your example what setTo() would check for would imho if it's a
string (or an object with a __toString method). The application cannot
be aware of the type of recipients the mailserver software accepts.
Please be aware that a recipient can also be a mailbox rather than an
address, so 'root' would also be valid. So yes: we should check if the
input is a string. No: we can't do anything else (I think) because we
don't know the capabilities of the mailserver software.

Opinions?

Dolf
-- Freeaqingme

On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]> wrote:

> Hi,
>
> Dolf Schimmel wrote:
>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
>> email adresses are filtered while adding them. What do you think of
>> this practice, and should we continue doing it? I'm against filtering,
>> though I could see reasons to validate. On the other hand, isn't
>> validating email addresses part of the application responsibilities
>> instead of that of the component (just like any other user input)?
>> Obviously, there's no need to validate the same string twice.
>>
>> What do you think, should Zend_Mail filter, should it validate? Or
>> should it just leave it up to the app.
>
> In general I would also say, that it should leave it up to the application. But:
>
> Zend_Mail will - on the other hand - work with other components (PHP's mail() function, multiple mail transports...), which all require valid addresses as parameters. So without validation, we would carry invalid data through our application and Zend_Mail could make invalid calls to other components.
>
> I guess it is not a simple question. It's a question about responsibility and reliability.
>
> When I would set something as address ($mail->setTo()), the setter should make sure, that only valid data will be set. Why? Because when I get the data ($mail->getTo()) I would assume, that I only get valid data.
>
> If Zend_Mail would accept any input, the component wouldn't be reliable and everything which is using Zend_Mail would have to check everything again.
>
> Well, in the end we don't trust anything, so every used component like the mail() function or at least the mail server will do its own check... but when dealing with objects, we *should* assume, that an object only contains valid data.
>
> That's my point of view, I hope you understand what I trying to tell. :-)
>
>
> --
> Regards,
> Thomas
>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Thomas D.
Hi,

Dolf Schimmel wrote:
> In your example what setTo() would check for would imho if it's a
> string (or an object with a __toString method). The application cannot
> be aware of the type of recipients the mailserver software accepts.
> Please be aware that a recipient can also be a mailbox rather than an
> address, so 'root' would also be valid. So yes: we should check if the
> input is a string. No: we can't do anything else (I think) because we
> don't know the capabilities of the mailserver software.

I agree with you, but we can do more:

The setTo() method in my example should use Zend validator like

  $validator = new Zend_Validate_EmailAddress();
  $validator->setOptions(array('domain' => FALSE));

This will only check the local part (lcf), but it will *really* check it (the local part is not just a string, don't forget the restricted length and restricted characters...).

Result:
[x] Object is always in a valid state.
[x] Getter will always return valid values.
[x] No invalid calls from Zend_Mail.


--
Regards,
Thomas



--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Regards,
Thomas
Reply | Threaded
Open this post in threaded view
|

RE: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Hector Virgen
This post has NOT been accepted by the mailing list yet.

If we want to ensure that a Zend_Mail object is always in a "valid state", then what if considered "valid" for all applications? Your mail server may support the address "root" but mine may not. "Valid state" may be entirely different from application to application.

I don't think Zend_Mail should be responsible for determining what is considered a valid address simply because it cannot do so for each mail server. Instead, it should be a "dumb" component that simply does what it's told -- only raising an exception when it absolutely can't continue.

--
Hector Virgen

--
Hector Virgen
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

drm-4
In reply to this post by Dolf Schimmel


It's a simple matter of separation of concern. Zend\Mail is a bridge to the mail server and that should be its one and only concern, and it does not entail validation imho. It might constitute inconsistencies between Zend\Mail and the delivery service; you can't be certain about the limits of the delivery, so you shouldn't bother with validation at that point. If delivery or sending fails (regardless whether it is a validation issue), the bridge should throw an exception.

Validation on the application level is the concern of the application and might require a whole other set of preconditions (eg. Valid email, no mailinator, no hotmail....). That has, really, nothing to do with the actual delivery.

So I agree with Dolf on this.

----- Reply message -----
From: "Dolf Schimmel" <[hidden email]>
To: "Thomas D." <[hidden email]>
Cc: <[hidden email]>
Subject: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)
Date: Mon, May 30, 2011 20:25


In your example what setTo() would check for would imho if it's a
string (or an object with a __toString method). The application cannot
be aware of the type of recipients the mailserver software accepts.
Please be aware that a recipient can also be a mailbox rather than an
address, so 'root' would also be valid. So yes: we should check if the
input is a string. No: we can't do anything else (I think) because we
don't know the capabilities of the mailserver software.

Opinions?

Dolf
-- Freeaqingme

On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]> wrote:

> Hi,
>
> Dolf Schimmel wrote:
>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
>> email adresses are filtered while adding them. What do you think of
>> this practice, and should we continue doing it? I'm against filtering,
>> though I could see reasons to validate. On the other hand, isn't
>> validating email addresses part of the application responsibilities
>> instead of that of the component (just like any other user input)?
>> Obviously, there's no need to validate the same string twice.
>>
>> What do you think, should Zend_Mail filter, should it validate? Or
>> should it just leave it up to the app.
>
> In general I would also say, that it should leave it up to the application. But:
>
> Zend_Mail will - on the other hand - work with other components (PHP's mail() function, multiple mail transports...), which all require valid addresses as parameters. So without validation, we would carry invalid data through our application and Zend_Mail could make invalid calls to other components.
>
> I guess it is not a simple question. It's a question about responsibility and reliability.
>
> When I would set something as address ($mail->setTo()), the setter should make sure, that only valid data will be set. Why? Because when I get the data ($mail->getTo()) I would assume, that I only get valid data.
>
> If Zend_Mail would accept any input, the component wouldn't be reliable and everything which is using Zend_Mail would have to check everything again.
>
> Well, in the end we don't trust anything, so every used component like the mail() function or at least the mail server will do its own check... but when dealing with objects, we *should* assume, that an object only contains valid data.
>
> That's my point of view, I hope you understand what I trying to tell. :-)
>
>
> --
> Regards,
> Thomas
>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

padraicb
In reply to this post by Dolf Schimmel
Would it not make sense to simply package validation/filtering separately into
some helper class and offer the ability to override or ignore specifics (or just
the whole thing - though specific exceptions are nice to isolate what we want to
flex) with configuration flags? I understand that these concerns need to be
flexible but using some sane defaults doesn't seem likely to cause harm and can
save developers (who don't need have any need for filtering exceptions) a bunch
of time chewing on what needs filtering/validation and how they can do it
reliably. I don't see this as being a one or the other choice - having internal
filters is good, having the flexibility to impose more suitable ones is good -
do both?

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Dolf Schimmel <[hidden email]>
To: Thomas D. <[hidden email]>
Cc: [hidden email]
Sent: Mon, May 30, 2011 1:25:09 PM
Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not to
strip/validate (email adresses)

In your example what setTo() would check for would imho if it's a
string (or an object with a __toString method). The application cannot
be aware of the type of recipients the mailserver software accepts.
Please be aware that a recipient can also be a mailbox rather than an
address, so 'root' would also be valid. So yes: we should check if the
input is a string. No: we can't do anything else (I think) because we
don't know the capabilities of the mailserver software.

Opinions?

Dolf
-- Freeaqingme

On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]> wrote:

> Hi,
>
> Dolf Schimmel wrote:
>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
>> email adresses are filtered while adding them. What do you think of
>> this practice, and should we continue doing it? I'm against filtering,
>> though I could see reasons to validate. On the other hand, isn't
>> validating email addresses part of the application responsibilities
>> instead of that of the component (just like any other user input)?
>> Obviously, there's no need to validate the same string twice.
>>
>> What do you think, should Zend_Mail filter, should it validate? Or
>> should it just leave it up to the app.
>
> In general I would also say, that it should leave it up to the application.
>But:
>
> Zend_Mail will - on the other hand - work with other components (PHP's mail()
>function, multiple mail transports...), which all require valid addresses as
>parameters. So without validation, we would carry invalid data through our
>application and Zend_Mail could make invalid calls to other components.
>
> I guess it is not a simple question. It's a question about responsibility and
>reliability.
>
> When I would set something as address ($mail->setTo()), the setter should make
>sure, that only valid data will be set. Why? Because when I get the data
>($mail->getTo()) I would assume, that I only get valid data.
>
> If Zend_Mail would accept any input, the component wouldn't be reliable and
>everything which is using Zend_Mail would have to check everything again.
>
> Well, in the end we don't trust anything, so every used component like the
>mail() function or at least the mail server will do its own check... but when
>dealing with objects, we *should* assume, that an object only contains valid
>data.
>
> That's my point of view, I hope you understand what I trying to tell. :-)
>
>
> --
> Regards,
> Thomas
>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Thomas D.
In reply to this post by Thomas D.
Hi,

Will Moore III wrote:

> > The setTo() method in my example should use Zend validator like
> >
> >  $validator = new Zend_Validate_EmailAddress();
> >  $validator->setOptions(array('domain' => FALSE));
> >
> > This will only check the local part (lcf), but it will *really*
> > check it (the local part is not just a string, don't forget the
> > restricted length and restricted characters...).
>
> I see three potential problems with this:
>
> 1. Introduces a hard dependency on the Validator component.

Right. But why is it a problem? Other components like OAuth, many Zend Services are having such dependencies too.


> 2. Tightly couples the validation to Zend not giving way to a
>    user's provided validations.
>
> 3. We could allow a user to override the default validation with
> their own; however, that means the component has to deal with
> multiple paths of execution which simply makes it more complex
> than it needs to be.

Right. If a user wants to completely validate "[hidden email]", this validator cannot be used just for "root". Providing a flexible way, which will allow something like that is fairly complex and not my intension.


> I believe that at the end of the day, the following is the way
> to look at this:
> http://www.erlang.se/doc/programming_rules.shtml#HDR11

Good point. If we don't want defensive programming the answer is simple: No validation.

But I am not sure if we want that: For me, "do not program defensively" just apply to type-safe languages. But because PHP isn't one, I have the opinion "do program defensively" (that should apply to every kind of non-type-safe languages). Yes, that's maybe a kind of philosophic question...

If we wouldn't validate, the object might be in an invalid state, which violates against the OO idea, don't you agree?


P.s.:
Currently Zend_Mail is already validating. It's just not doing it "right". So why should Zend_Mail write its own validator, when it can re-use existing functionality? OK, this is an obsolete question, if you are against validation at all (this would include the current state) in this component.


--
Regards,
Thomas




--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Regards,
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Wil Moore III
This post has NOT been accepted by the mailing list yet.

Right. But why is it a problem? Other components like OAuth, many Zend Services are having such dependencies too.

As for OAuth, maybe the dependencies are justified there. I can't speak to that one since I've not used it nor have I looked at that code.

I can only speak for myself on this one; but I would think others might agree. For example, ZF2 some hidden gems; some of which, I am using in current projects. Ideally, I'd love to be able to "git submodule add..." these, and be done; however, that isn't the situation at this time. If I want the "git submodule add ..." effect, I need to jump through hoops and play with subtree hacks: http://h2ik.co/2011/03/having-fun-with-git-subtree/ -- It isn't terribly difficult to pull off, but at the same time, it won't give you the warm and fuzzies :). I felt that the effort vs. value ratio just wasn't there and ended up pragmatically pulling in the entire ZF2 distro into a version-stamped directory, adding the reference to the autoloader, then commit. Had it been one simple file, I'd have just pulled it in; however, the one simple file, depends on several others in the same component, and that component depends on another component. Fine, if there are a few dependencies, that is OK, but, the way it is being done is counterproductive. What I'm saying is, the dependencies are cool if it is easy to pull them in and maintain them, otherwise, it is best to avoid that situation.

On another note, I feel like the less dependencies a component has, the more creative the end-user can be with that component. I am more keen to continue to pull in a component if it works like grep or sed in that it does one simple thing and does it well.


If we wouldn't validate, the object might be in an invalid state, which violates against the OO idea, don't you agree?


I think the component should validate that the string is safe and doesn't contain any XSS issues or things of that sort. 


But because PHP isn't one, I have the opinion "do program defensively" (that should apply to every kind of non-type-safe languages). 


I agree with the sentiment of do not program defensively; however, in practice, there are things we do need to look out for (e.g. XSS). I think the rest can be handled at the unit-test level.

--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Marc Bennewitz (private)
In reply to this post by padraicb
Hi,

Why we don't have an own class for mail addresses which validates input
against option configuration like the mail validator has ?
The validation is only done once and than the object will be used over all.
Additionally it also could be useful to move email validations into this
component.

e.g.:
Zend\Email\Address
Zend\Email\Validator

Greetings
Marc

On 30.05.2011 19:51, Pádraic Brady wrote:

> Would it not make sense to simply package validation/filtering separately into
> some helper class and offer the ability to override or ignore specifics (or just
> the whole thing - though specific exceptions are nice to isolate what we want to
> flex) with configuration flags? I understand that these concerns need to be
> flexible but using some sane defaults doesn't seem likely to cause harm and can
> save developers (who don't need have any need for filtering exceptions) a bunch
> of time chewing on what needs filtering/validation and how they can do it
> reliably. I don't see this as being a one or the other choice - having internal
> filters is good, having the flexibility to impose more suitable ones is good -
> do both?
>
> Paddy
>
>  Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
>
>
> ________________________________
> From: Dolf Schimmel <[hidden email]>
> To: Thomas D. <[hidden email]>
> Cc: [hidden email]
> Sent: Mon, May 30, 2011 1:25:09 PM
> Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not to
> strip/validate (email adresses)
>
> In your example what setTo() would check for would imho if it's a
> string (or an object with a __toString method). The application cannot
> be aware of the type of recipients the mailserver software accepts.
> Please be aware that a recipient can also be a mailbox rather than an
> address, so 'root' would also be valid. So yes: we should check if the
> input is a string. No: we can't do anything else (I think) because we
> don't know the capabilities of the mailserver software.
>
> Opinions?
>
> Dolf
> -- Freeaqingme
>
> On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]> wrote:
>> Hi,
>>
>> Dolf Schimmel wrote:
>>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
>>> email adresses are filtered while adding them. What do you think of
>>> this practice, and should we continue doing it? I'm against filtering,
>>> though I could see reasons to validate. On the other hand, isn't
>>> validating email addresses part of the application responsibilities
>>> instead of that of the component (just like any other user input)?
>>> Obviously, there's no need to validate the same string twice.
>>>
>>> What do you think, should Zend_Mail filter, should it validate? Or
>>> should it just leave it up to the app.
>> In general I would also say, that it should leave it up to the application.
>> But:
>>
>> Zend_Mail will - on the other hand - work with other components (PHP's mail()
>> function, multiple mail transports...), which all require valid addresses as
>> parameters. So without validation, we would carry invalid data through our
>> application and Zend_Mail could make invalid calls to other components.
>>
>> I guess it is not a simple question. It's a question about responsibility and
>> reliability.
>>
>> When I would set something as address ($mail->setTo()), the setter should make
>> sure, that only valid data will be set. Why? Because when I get the data
>> ($mail->getTo()) I would assume, that I only get valid data.
>>
>> If Zend_Mail would accept any input, the component wouldn't be reliable and
>> everything which is using Zend_Mail would have to check everything again.
>>
>> Well, in the end we don't trust anything, so every used component like the
>> mail() function or at least the mail server will do its own check... but when
>> dealing with objects, we *should* assume, that an object only contains valid
>> data.
>>
>> That's my point of view, I hope you understand what I trying to tell. :-)
>>
>>
>> --
>> Regards,
>> Thomas
>>
>>
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Vijay Bose
Hey,

+1.

I think Marc is having a valid point. So we can provide both functionality.

Regards,
Vijay

On Tue, May 31, 2011 at 10:22 AM, Marc Bennewitz <[hidden email]>wrote:

> Hi,
>
> Why we don't have an own class for mail addresses which validates input
> against option configuration like the mail validator has ?
> The validation is only done once and than the object will be used over all.
> Additionally it also could be useful to move email validations into this
> component.
>
> e.g.:
> Zend\Email\Address
> Zend\Email\Validator
>
> Greetings
> Marc
>
> On 30.05.2011 19:51, Pádraic Brady wrote:
> > Would it not make sense to simply package validation/filtering separately
> into
> > some helper class and offer the ability to override or ignore specifics
> (or just
> > the whole thing - though specific exceptions are nice to isolate what we
> want to
> > flex) with configuration flags? I understand that these concerns need to
> be
> > flexible but using some sane defaults doesn't seem likely to cause harm
> and can
> > save developers (who don't need have any need for filtering exceptions) a
> bunch
> > of time chewing on what needs filtering/validation and how they can do it
> > reliably. I don't see this as being a one or the other choice - having
> internal
> > filters is good, having the flexibility to impose more suitable ones is
> good -
> > do both?
> >
> > Paddy
> >
> >  Pádraic Brady
> >
> > http://blog.astrumfutura.com
> > http://www.survivethedeepend.com
> > Zend Framework Community Review Team
> >
> >
> >
> >
> >
> > ________________________________
> > From: Dolf Schimmel <[hidden email]>
> > To: Thomas D. <[hidden email]>
> > Cc: [hidden email]
> > Sent: Mon, May 30, 2011 1:25:09 PM
> > Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not to
> > strip/validate (email adresses)
> >
> > In your example what setTo() would check for would imho if it's a
> > string (or an object with a __toString method). The application cannot
> > be aware of the type of recipients the mailserver software accepts.
> > Please be aware that a recipient can also be a mailbox rather than an
> > address, so 'root' would also be valid. So yes: we should check if the
> > input is a string. No: we can't do anything else (I think) because we
> > don't know the capabilities of the mailserver software.
> >
> > Opinions?
> >
> > Dolf
> > -- Freeaqingme
> >
> > On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]>
> wrote:
> >> Hi,
> >>
> >> Dolf Schimmel wrote:
> >>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
> >>> email adresses are filtered while adding them. What do you think of
> >>> this practice, and should we continue doing it? I'm against filtering,
> >>> though I could see reasons to validate. On the other hand, isn't
> >>> validating email addresses part of the application responsibilities
> >>> instead of that of the component (just like any other user input)?
> >>> Obviously, there's no need to validate the same string twice.
> >>>
> >>> What do you think, should Zend_Mail filter, should it validate? Or
> >>> should it just leave it up to the app.
> >> In general I would also say, that it should leave it up to the
> application.
> >> But:
> >>
> >> Zend_Mail will - on the other hand - work with other components (PHP's
> mail()
> >> function, multiple mail transports...), which all require valid
> addresses as
> >> parameters. So without validation, we would carry invalid data through
> our
> >> application and Zend_Mail could make invalid calls to other components.
> >>
> >> I guess it is not a simple question. It's a question about
> responsibility and
> >> reliability.
> >>
> >> When I would set something as address ($mail->setTo()), the setter
> should make
> >> sure, that only valid data will be set. Why? Because when I get the data
> >> ($mail->getTo()) I would assume, that I only get valid data.
> >>
> >> If Zend_Mail would accept any input, the component wouldn't be reliable
> and
> >> everything which is using Zend_Mail would have to check everything
> again.
> >>
> >> Well, in the end we don't trust anything, so every used component like
> the
> >> mail() function or at least the mail server will do its own check... but
> when
> >> dealing with objects, we *should* assume, that an object only contains
> valid
> >> data.
> >>
> >> That's my point of view, I hope you understand what I trying to tell.
> :-)
> >>
> >>
> >> --
> >> Regards,
> >> Thomas
> >>
> >>
> >>
> >> --
> >> List: [hidden email]
> >> Info: http://framework.zend.com/archives
> >> Unsubscribe: [hidden email]
> >>
> >>
> >>
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Vijay Bose.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

gargoyle-3
I got half way up this thread and started to think exactly what Marc said. When you stop thinking of an email address as a string and more of the complex entity that it is, then it is obvious that there should be some kind of Zend/Email/Address class.

Zend/Mail::setTo() could then accept an instance of this class or a string. Passing a string would simply attempt to create an instance of Zend/Mail/Address, but would keep the learning curve low.

Paul
(Gargoyle)


On 23 Jul 2011, at 11:53, Ganesh Vijaya Bose wrote:

> Hey,
>
> +1.
>
> I think Marc is having a valid point. So we can provide both functionality.
>
> Regards,
> Vijay
>
> On Tue, May 31, 2011 at 10:22 AM, Marc Bennewitz <[hidden email]>wrote:
>
>> Hi,
>>
>> Why we don't have an own class for mail addresses which validates input
>> against option configuration like the mail validator has ?
>> The validation is only done once and than the object will be used over all.
>> Additionally it also could be useful to move email validations into this
>> component.
>>
>> e.g.:
>> Zend\Email\Address
>> Zend\Email\Validator
>>
>> Greetings
>> Marc
>>
>> On 30.05.2011 19:51, Pádraic Brady wrote:
>>> Would it not make sense to simply package validation/filtering separately
>> into
>>> some helper class and offer the ability to override or ignore specifics
>> (or just
>>> the whole thing - though specific exceptions are nice to isolate what we
>> want to
>>> flex) with configuration flags? I understand that these concerns need to
>> be
>>> flexible but using some sane defaults doesn't seem likely to cause harm
>> and can
>>> save developers (who don't need have any need for filtering exceptions) a
>> bunch
>>> of time chewing on what needs filtering/validation and how they can do it
>>> reliably. I don't see this as being a one or the other choice - having
>> internal
>>> filters is good, having the flexibility to impose more suitable ones is
>> good -
>>> do both?
>>>
>>> Paddy
>>>
>>> Pádraic Brady
>>>
>>> http://blog.astrumfutura.com
>>> http://www.survivethedeepend.com
>>> Zend Framework Community Review Team
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Dolf Schimmel <[hidden email]>
>>> To: Thomas D. <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Mon, May 30, 2011 1:25:09 PM
>>> Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not to
>>> strip/validate (email adresses)
>>>
>>> In your example what setTo() would check for would imho if it's a
>>> string (or an object with a __toString method). The application cannot
>>> be aware of the type of recipients the mailserver software accepts.
>>> Please be aware that a recipient can also be a mailbox rather than an
>>> address, so 'root' would also be valid. So yes: we should check if the
>>> input is a string. No: we can't do anything else (I think) because we
>>> don't know the capabilities of the mailserver software.
>>>
>>> Opinions?
>>>
>>> Dolf
>>> -- Freeaqingme
>>>
>>> On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]>
>> wrote:
>>>> Hi,
>>>>
>>>> Dolf Schimmel wrote:
>>>>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
>>>>> email adresses are filtered while adding them. What do you think of
>>>>> this practice, and should we continue doing it? I'm against filtering,
>>>>> though I could see reasons to validate. On the other hand, isn't
>>>>> validating email addresses part of the application responsibilities
>>>>> instead of that of the component (just like any other user input)?
>>>>> Obviously, there's no need to validate the same string twice.
>>>>>
>>>>> What do you think, should Zend_Mail filter, should it validate? Or
>>>>> should it just leave it up to the app.
>>>> In general I would also say, that it should leave it up to the
>> application.
>>>> But:
>>>>
>>>> Zend_Mail will - on the other hand - work with other components (PHP's
>> mail()
>>>> function, multiple mail transports...), which all require valid
>> addresses as
>>>> parameters. So without validation, we would carry invalid data through
>> our
>>>> application and Zend_Mail could make invalid calls to other components.
>>>>
>>>> I guess it is not a simple question. It's a question about
>> responsibility and
>>>> reliability.
>>>>
>>>> When I would set something as address ($mail->setTo()), the setter
>> should make
>>>> sure, that only valid data will be set. Why? Because when I get the data
>>>> ($mail->getTo()) I would assume, that I only get valid data.
>>>>
>>>> If Zend_Mail would accept any input, the component wouldn't be reliable
>> and
>>>> everything which is using Zend_Mail would have to check everything
>> again.
>>>>
>>>> Well, in the end we don't trust anything, so every used component like
>> the
>>>> mail() function or at least the mail server will do its own check... but
>> when
>>>> dealing with objects, we *should* assume, that an object only contains
>> valid
>>>> data.
>>>>
>>>> That's my point of view, I hope you understand what I trying to tell.
>> :-)
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>> --
>>>> List: [hidden email]
>>>> Info: http://framework.zend.com/archives
>>>> Unsubscribe: [hidden email]
>>>>
>>>>
>>>>
>>> --
>>> List: [hidden email]
>>> Info: http://framework.zend.com/archives
>>> Unsubscribe: [hidden email]
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Tomáš Fejfar
I really like the idea from the point "hey there is an email address -> it z
Zend/Email/Address object" :) Also the API would be more obvious than using
validators. Like $emailObject->hasValidMxRecord() etc. BUT

It's bad idea to namespace Email validator under Email namespace. There is
some consistency in the Validators namespace - whatever's there, validates.
So email would be then only a DTO/proxy to Zend/Validate calls. Question is
if that is needed. I don't think so.

What added value would that object deliver? Wouldn't it be just syntactic
sugar to make users use something that validates automatically? :)

On Mon, Jul 25, 2011 at 10:42 AM, Paul Court <[hidden email]> wrote:

> I got half way up this thread and started to think exactly what Marc said.
> When you stop thinking of an email address as a string and more of the
> complex entity that it is, then it is obvious that there should be some kind
> of Zend/Email/Address class.
>
> Zend/Mail::setTo() could then accept an instance of this class or a string.
> Passing a string would simply attempt to create an instance of
> Zend/Mail/Address, but would keep the learning curve low.
>
> Paul
> (Gargoyle)
>
>
> On 23 Jul 2011, at 11:53, Ganesh Vijaya Bose wrote:
>
> > Hey,
> >
> > +1.
> >
> > I think Marc is having a valid point. So we can provide both
> functionality.
> >
> > Regards,
> > Vijay
> >
> > On Tue, May 31, 2011 at 10:22 AM, Marc Bennewitz <
> [hidden email]>wrote:
> >
> >> Hi,
> >>
> >> Why we don't have an own class for mail addresses which validates input
> >> against option configuration like the mail validator has ?
> >> The validation is only done once and than the object will be used over
> all.
> >> Additionally it also could be useful to move email validations into this
> >> component.
> >>
> >> e.g.:
> >> Zend\Email\Address
> >> Zend\Email\Validator
> >>
> >> Greetings
> >> Marc
> >>
> >> On 30.05.2011 19:51, Pádraic Brady wrote:
> >>> Would it not make sense to simply package validation/filtering
> separately
> >> into
> >>> some helper class and offer the ability to override or ignore specifics
> >> (or just
> >>> the whole thing - though specific exceptions are nice to isolate what
> we
> >> want to
> >>> flex) with configuration flags? I understand that these concerns need
> to
> >> be
> >>> flexible but using some sane defaults doesn't seem likely to cause harm
> >> and can
> >>> save developers (who don't need have any need for filtering exceptions)
> a
> >> bunch
> >>> of time chewing on what needs filtering/validation and how they can do
> it
> >>> reliably. I don't see this as being a one or the other choice - having
> >> internal
> >>> filters is good, having the flexibility to impose more suitable ones is
> >> good -
> >>> do both?
> >>>
> >>> Paddy
> >>>
> >>> Pádraic Brady
> >>>
> >>> http://blog.astrumfutura.com
> >>> http://www.survivethedeepend.com
> >>> Zend Framework Community Review Team
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ________________________________
> >>> From: Dolf Schimmel <[hidden email]>
> >>> To: Thomas D. <[hidden email]>
> >>> Cc: [hidden email]
> >>> Sent: Mon, May 30, 2011 1:25:09 PM
> >>> Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or not
> to
> >>> strip/validate (email adresses)
> >>>
> >>> In your example what setTo() would check for would imho if it's a
> >>> string (or an object with a __toString method). The application cannot
> >>> be aware of the type of recipients the mailserver software accepts.
> >>> Please be aware that a recipient can also be a mailbox rather than an
> >>> address, so 'root' would also be valid. So yes: we should check if the
> >>> input is a string. No: we can't do anything else (I think) because we
> >>> don't know the capabilities of the mailserver software.
> >>>
> >>> Opinions?
> >>>
> >>> Dolf
> >>> -- Freeaqingme
> >>>
> >>> On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]>
> >> wrote:
> >>>> Hi,
> >>>>
> >>>> Dolf Schimmel wrote:
> >>>>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
> >>>>> email adresses are filtered while adding them. What do you think of
> >>>>> this practice, and should we continue doing it? I'm against
> filtering,
> >>>>> though I could see reasons to validate. On the other hand, isn't
> >>>>> validating email addresses part of the application responsibilities
> >>>>> instead of that of the component (just like any other user input)?
> >>>>> Obviously, there's no need to validate the same string twice.
> >>>>>
> >>>>> What do you think, should Zend_Mail filter, should it validate? Or
> >>>>> should it just leave it up to the app.
> >>>> In general I would also say, that it should leave it up to the
> >> application.
> >>>> But:
> >>>>
> >>>> Zend_Mail will - on the other hand - work with other components (PHP's
> >> mail()
> >>>> function, multiple mail transports...), which all require valid
> >> addresses as
> >>>> parameters. So without validation, we would carry invalid data through
> >> our
> >>>> application and Zend_Mail could make invalid calls to other
> components.
> >>>>
> >>>> I guess it is not a simple question. It's a question about
> >> responsibility and
> >>>> reliability.
> >>>>
> >>>> When I would set something as address ($mail->setTo()), the setter
> >> should make
> >>>> sure, that only valid data will be set. Why? Because when I get the
> data
> >>>> ($mail->getTo()) I would assume, that I only get valid data.
> >>>>
> >>>> If Zend_Mail would accept any input, the component wouldn't be
> reliable
> >> and
> >>>> everything which is using Zend_Mail would have to check everything
> >> again.
> >>>>
> >>>> Well, in the end we don't trust anything, so every used component like
> >> the
> >>>> mail() function or at least the mail server will do its own check...
> but
> >> when
> >>>> dealing with objects, we *should* assume, that an object only contains
> >> valid
> >>>> data.
> >>>>
> >>>> That's my point of view, I hope you understand what I trying to tell.
> >> :-)
> >>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Thomas
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> List: [hidden email]
> >>>> Info: http://framework.zend.com/archives
> >>>> Unsubscribe: [hidden email]
> >>>>
> >>>>
> >>>>
> >>> --
> >>> List: [hidden email]
> >>> Info: http://framework.zend.com/archives
> >>> Unsubscribe: [hidden email]
> >>
> >> --
> >> List: [hidden email]
> >> Info: http://framework.zend.com/archives
> >> Unsubscribe: [hidden email]
> >>
> >>
> >>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Zend\Mail: To strip/validate or not to strip/validate (email adresses)

Artur Bodera
Please keep global framework consistency in mind and drawbacks.

Email addresses are universally recognized as strings.
There is little difference in parsing a string or object in Mail.

Why?

Because with string you'd  $validator->validate($string);
with object you'd  $emailObj->validate();   (because you might have
half-baked Email instance).

We could do it java-way, and encapsulate everything in objects, think IP
addresses, URI/URL, phone numbers, file names (files/streams in general)
etc.
But.. not every string domain needs encapsulation/helper object.

The general idea of using encapsulation is streamlining parsing and
manipulation. That's probably why there is \Zend\Uri, because it is re-used
over and over again by other components. \Mail\Address would only be
feasible if we plan intra-component usage and a general usability advantage
over using just simple "[hidden email]".

Remember encapsulation increases mem usage (imagine email campaign with
10000 recipients), requires more cycles (constructors, accessors,.. ) and
can increase learning curve (i.e. substr((string)$mail->email,0,10)  and
such.)

Cheers.

--

      __
     /.)\   +48 695 600 936
     \(./   [hidden email]


2011/7/25 Tomáš Fejfar <[hidden email]>

> I really like the idea from the point "hey there is an email address -> it
> z
> Zend/Email/Address object" :) Also the API would be more obvious than using
> validators. Like $emailObject->hasValidMxRecord() etc. BUT
>
> It's bad idea to namespace Email validator under Email namespace. There is
> some consistency in the Validators namespace - whatever's there, validates.
> So email would be then only a DTO/proxy to Zend/Validate calls. Question is
> if that is needed. I don't think so.
>
> What added value would that object deliver? Wouldn't it be just syntactic
> sugar to make users use something that validates automatically? :)
>
> On Mon, Jul 25, 2011 at 10:42 AM, Paul Court <[hidden email]> wrote:
>
> > I got half way up this thread and started to think exactly what Marc
> said.
> > When you stop thinking of an email address as a string and more of the
> > complex entity that it is, then it is obvious that there should be some
> kind
> > of Zend/Email/Address class.
> >
> > Zend/Mail::setTo() could then accept an instance of this class or a
> string.
> > Passing a string would simply attempt to create an instance of
> > Zend/Mail/Address, but would keep the learning curve low.
> >
> > Paul
> > (Gargoyle)
> >
> >
> > On 23 Jul 2011, at 11:53, Ganesh Vijaya Bose wrote:
> >
> > > Hey,
> > >
> > > +1.
> > >
> > > I think Marc is having a valid point. So we can provide both
> > functionality.
> > >
> > > Regards,
> > > Vijay
> > >
> > > On Tue, May 31, 2011 at 10:22 AM, Marc Bennewitz <
> > [hidden email]>wrote:
> > >
> > >> Hi,
> > >>
> > >> Why we don't have an own class for mail addresses which validates
> input
> > >> against option configuration like the mail validator has ?
> > >> The validation is only done once and than the object will be used over
> > all.
> > >> Additionally it also could be useful to move email validations into
> this
> > >> component.
> > >>
> > >> e.g.:
> > >> Zend\Email\Address
> > >> Zend\Email\Validator
> > >>
> > >> Greetings
> > >> Marc
> > >>
> > >> On 30.05.2011 19:51, Pádraic Brady wrote:
> > >>> Would it not make sense to simply package validation/filtering
> > separately
> > >> into
> > >>> some helper class and offer the ability to override or ignore
> specifics
> > >> (or just
> > >>> the whole thing - though specific exceptions are nice to isolate what
> > we
> > >> want to
> > >>> flex) with configuration flags? I understand that these concerns need
> > to
> > >> be
> > >>> flexible but using some sane defaults doesn't seem likely to cause
> harm
> > >> and can
> > >>> save developers (who don't need have any need for filtering
> exceptions)
> > a
> > >> bunch
> > >>> of time chewing on what needs filtering/validation and how they can
> do
> > it
> > >>> reliably. I don't see this as being a one or the other choice -
> having
> > >> internal
> > >>> filters is good, having the flexibility to impose more suitable ones
> is
> > >> good -
> > >>> do both?
> > >>>
> > >>> Paddy
> > >>>
> > >>> Pádraic Brady
> > >>>
> > >>> http://blog.astrumfutura.com
> > >>> http://www.survivethedeepend.com
> > >>> Zend Framework Community Review Team
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ________________________________
> > >>> From: Dolf Schimmel <[hidden email]>
> > >>> To: Thomas D. <[hidden email]>
> > >>> Cc: [hidden email]
> > >>> Sent: Mon, May 30, 2011 1:25:09 PM
> > >>> Subject: Re: [zf-contributors] ZF2 Zend\Mail: To strip/validate or
> not
> > to
> > >>> strip/validate (email adresses)
> > >>>
> > >>> In your example what setTo() would check for would imho if it's a
> > >>> string (or an object with a __toString method). The application
> cannot
> > >>> be aware of the type of recipients the mailserver software accepts.
> > >>> Please be aware that a recipient can also be a mailbox rather than an
> > >>> address, so 'root' would also be valid. So yes: we should check if
> the
> > >>> input is a string. No: we can't do anything else (I think) because we
> > >>> don't know the capabilities of the mailserver software.
> > >>>
> > >>> Opinions?
> > >>>
> > >>> Dolf
> > >>> -- Freeaqingme
> > >>>
> > >>> On Mon, May 30, 2011 at 1:29 PM, Thomas D. <[hidden email]>
> > >> wrote:
> > >>>> Hi,
> > >>>>
> > >>>> Dolf Schimmel wrote:
> > >>>>> I'm busy on refactoring Zend_Mail. and couldn't help noticing that
> > >>>>> email adresses are filtered while adding them. What do you think of
> > >>>>> this practice, and should we continue doing it? I'm against
> > filtering,
> > >>>>> though I could see reasons to validate. On the other hand, isn't
> > >>>>> validating email addresses part of the application responsibilities
> > >>>>> instead of that of the component (just like any other user input)?
> > >>>>> Obviously, there's no need to validate the same string twice.
> > >>>>>
> > >>>>> What do you think, should Zend_Mail filter, should it validate? Or
> > >>>>> should it just leave it up to the app.
> > >>>> In general I would also say, that it should leave it up to the
> > >> application.
> > >>>> But:
> > >>>>
> > >>>> Zend_Mail will - on the other hand - work with other components
> (PHP's
> > >> mail()
> > >>>> function, multiple mail transports...), which all require valid
> > >> addresses as
> > >>>> parameters. So without validation, we would carry invalid data
> through
> > >> our
> > >>>> application and Zend_Mail could make invalid calls to other
> > components.
> > >>>>
> > >>>> I guess it is not a simple question. It's a question about
> > >> responsibility and
> > >>>> reliability.
> > >>>>
> > >>>> When I would set something as address ($mail->setTo()), the setter
> > >> should make
> > >>>> sure, that only valid data will be set. Why? Because when I get the
> > data
> > >>>> ($mail->getTo()) I would assume, that I only get valid data.
> > >>>>
> > >>>> If Zend_Mail would accept any input, the component wouldn't be
> > reliable
> > >> and
> > >>>> everything which is using Zend_Mail would have to check everything
> > >> again.
> > >>>>
> > >>>> Well, in the end we don't trust anything, so every used component
> like
> > >> the
> > >>>> mail() function or at least the mail server will do its own check...
> > but
> > >> when
> > >>>> dealing with objects, we *should* assume, that an object only
> contains
> > >> valid
> > >>>> data.
> > >>>>
> > >>>> That's my point of view, I hope you understand what I trying to
> tell.
> > >> :-)
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Regards,
> > >>>> Thomas
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> List: [hidden email]
> > >>>> Info: http://framework.zend.com/archives
> > >>>> Unsubscribe: [hidden email]
> > >>>>
> > >>>>
> > >>>>
> > >>> --
> > >>> List: [hidden email]
> > >>> Info: http://framework.zend.com/archives
> > >>> Unsubscribe: [hidden email]
> > >>
> > >> --
> > >> List: [hidden email]
> > >> Info: http://framework.zend.com/archives
> > >> Unsubscribe: [hidden email]
> > >>
> > >>
> > >>
> >
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
> >
>
12