Bs_Smtp

Methods inherited from Bs_NetApplication

Methods inherited from Bs_Object

Public Method Summary

Private Method Summary

Fields inherited from Bs_NetApplication

Public Field Summary

Private Field Summary

Private Constant Summary

Public Method Details

Private Method Details

(same as _sendRcptHelperArrays() so see there.)

TRUE

TRUE

TRUE

(same as _sendRcptHelperArrays() so see there.)

(see above)

TRUE

TRUE

TRUE @trhows bs_exception

TRUE on success (or if we are already logged in), FALSE on failure or if not supported or something.

(may be empty)

lines )

Warning: documentation is missing.

Warning: documentation is missing.

Warning: documentation is missing.

Warning: documentation is missing.

Warning: documentation is missing.

Public Field Details

>><<

The domain name as which we identify ourself to the mailserver.
i'm not sure if the receiving mailserver does anything with it, eg compares itwith our real ip/host address. but the mailserver sees our ip anyway, so whynot send the same information here.

>><<

the subject field is not mandatory (rfc).

>><<

the so called body of the email message.
rfc2822 section 2.3:- CR and LF MUST only occur together as CRLF; they MUST NOT appearindependently in the body.- Lines of characters in the body MUST be limited to 998 characters,and SHOULD be limited to 78 characters, excluding the CRLF.

Private Field Details

>>'localhost'<<

overwrite default value.

>>25<<

overwrite default value.

>>'BlueShoes Mail 4.0'<<

the mailclient name and version.
will be sent as a header line like:X-Mailer: BlueShoes Mail 4.0

>>FALSE<<

if we should log in (authenticate) to the mailserver.

>><<

>><<

>><<

stores detected features of the smtp server.
hash holding vector 0-n elements.hash key = ehlo-keyword, vector elements = ehlo-params.all ehlo-keyword and ehlo-params values are stored in uppercase to makeout life easier. i believe that most servers send them uppercase anyway,but the rfc specifies that any case must be accepted.

>><<

the senders addresses. mandatory.
used for both, the from header line and mail from command.see var $_to, but not the advanced data structure part of course.example header line:From: frommm <from@blueshoes.org>From: from1 <from1@blueshoes.org>, from2 <from2@blueshoes.org>example MAIL command line:MAIL FROM: <from@blueshoes.org>only the first mail address is used here.there can be 1-n addresses. if there is more than one, $sender becomes mandatory.

>><<

i don't think you'll ever need this one.
for example if a secretary sends an email for her boss, the sender isthe secretary's email address while the from is the chef's one.it is mandatory if $from is a list of addresses. see rfc2822 section 3.6.2.but the mailserver i'm testing with (mail.swissonline.ch) does not complain.so what we do is: if $_from is a list and $sender is not set, we use the firstaddress from $_from as the $sender address. just as we do it for the MAIL FROMcommand.example header line:Sender: senderrr <sender@blueshoes.org>

>><<

email addresses to where the receiving user should reply his answer email.
see var $_to, but not the advanced data structure part of course.adds the Reply-To: header line. example://Reply-To: <answers@blueshoes.org>

>><<

the To: receiver(s) of the email.
used for both, the to header line and rcpt to command.rfc2822 sections 3.6.3. and 3.4. and 3.4.1.examples for valid TO: header lines:To: "Joe Q. Public" <john.q.public@example.com>To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>To: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;to me it looks not that easy to be rfc compliant here.example RCPT command line:RCPT TO: <to@blueshoes.org>there is only one address per rcpt-to command, and it must be in <> tags.DATA STRUCTUREthe data structure of this var is a bit complicated. here we go with an example:when you add an address using $this->addTo(), the data array looks like this:$_to[]['email'] = 'info@blue-shoes.com'; //email address$_to[]['caption'] = 'info at blueshoes'; //textual nameso for the first addTo() it is $_to[0], then $_to[1] and so on, but we don't lookat this here. we only play with one address in this example.once the email was sent using $this->send(), you might get a bs_exception back. thismeans that no mail was sent at all, and thus this var is of no use for you anymore.if you got no exception, then it must be a bool TRUE or FALSE return value. thefollowing one OR two elements are added to each address entry in the array, dependingon what happened:$_to[]['status'] = FALSE; //bool TRUE or FALSE. tells if the address in [0] (info@blue-shoes.com)//was accepted or not.$_to[]['sub']['email'] = 'admin@blueshoes.org'; //in this case it was not accepted. in rfc lingo we got a 551 reply. the//server knew the users new email address and gave it to us. if the server//just sends a 550 (no valid address) this 3rd element [3] is not here at all.$_to[]['sub']['status'] = TRUE; //because we have the new address, we automatically try to use it. this bool//value tells if the new address worked.$_to[]['sub']['sub']['email'] = 'info@blueshoes.org'; //if there is a new address for the new address (think about it) then we have//it here. so here goes the recursive loop. max recursive calls is a hardcoded 5.//if an address is seen twice (ping-pong) then we stop immediatly.here is a longer example with more addresses:$_to[0]['email'] = 'info@blue-shoes.com';$_to[0]['caption'] = 'info at blueshoes';$_to[0]['status'] = TRUE; //everything ok.$_to[1]['email'] = 'webmaster@blue-shoes.com';$_to[1]['caption'] = ''; //no textual name, only email address available.$_to[1]['status'] = TRUE;$_to[1]['sub']['email'] = 'webmaster@blue-shoes.com'; //the address was accepted, but in the future we should use this address (251).$_to[2]['email'] = 'some_user@blue-shoes.com';$_to[2]['caption'] = 'some user';$_to[2]['status'] = FALSE; //not accepted, and we don't know what to do (550).$_to[3]['email'] = 'karen-smith@blue-shoes.com';$_to[3]['caption'] = 'karen smith';$_to[3]['status'] = FALSE; //not accepted, but server knows her new address (551).$_to[3]['sub']['email'] = 'karen-thomson@blue-shoes.com'; //she's married now... bad luck :-)$_to[3]['sub']['status'] = TRUE; //new address worked...$_to[3]['sub']['sub']['email'] = 'karen-thomson@blueshoes.org'; //...but server has a newer address again. domain name changed. (251)

>><<

see var $_to.

>><<

see var $_to.

>><<

the orig-date header field is mandatory (rfc). if not set by the user, it
will be set by the application itself (current datetime).specification: rfc2822 section 3.3.example header line:Date: Fri, 21 Nov 1997 09:55:06 -0600

>><<

the email priority.
only sent if it is set.number from 1 to 5 (including) where 1 is the highest priority.ms-outlook xp sends the following headers if you set it to 'high':X-Priority: 1 (Highest)X-MSMail-Priority: HighImportance: High

>><<

the email sensitivity.
only sent if it is set.one of 'personal', normal privat vertraulich

>><<

vector

>><<

hash holding additional key/value pairs to attach to the mail header.
note that all the vars like '_from', '_to' etc are all headers too. sodon't add them here again. it would result in an error message from theserver because most header lines can't be sent twice.special case: there may be a key called '_noKey' which holds a vector withplain header lines to attach. example $_header value:$_header['MIME-Version'] = '1.0';$_header['X-Mimeole'] = 'Produced By Microsoft MimeOLE V4.72.2106.4';$_header['_noKey'][0] = 'X-Msmail-Priority: Normal';

>>'7bit'<<

>><<

Private Constant Details