No idea, if it is required. I only have access to a couple of mail servers.

There is no SMTP that does not "interfere" in some way. SMTP is a standard that is supported in name only. Every server is more or less "forgiving" about what they expect versus what they receive.

If it makes you feel any better, when we wrote and tested @sendmail, we were on Road Runner (the same as you), up here in Ohio - so if there is any descrepency, RR introduced it recently or locally to Florida.

If there is a problem with Road Runner and the inclusion of a BCC with no CC, it is because of a double semicolon in the RCPT list (a portion of the SMTP protocol). The standard allows for this, but Verizon nor Adelphia's SMTP servers accept that as legal - though both will still send to the "TO" address, but skip the BCC - returning no error.

SMTP is not at fault. Variations in SMTP are at fault. SMTP is a conversation based on a set of rules. There is a great deal of "slack" in those rules.

Sesame is sending the email strictly to the SMTP standard, but that does not mean that the server is prepared to interpret what is sent. In the case of the BCC with no CC, Sesame will send an "empty" RCPT. It may well be that your server does not like that - even though it is legal SMTP.

Your dedicated email program may not send the empty RCPT, also perfectly legal.

It might be. It might not be.

Without being able to see the conversation between Sesame and any mail servers other than the several I have access to - I cannot say.

I did just try it.

But since you have already said that it didn't work for you even when you did specify both a CC and a BCC... there's not much point in pursuing this direction.

Quote:

No. They are not the same thing. One is derived from the other.
Quote:

There is a solution. The problem is that there are many solutions, and what works on your SMTP server, may not work on mine. When SMTP was first developed, a client could connect to any SMTP server in the world, and use it to send email. Later, they discovered that that was being abused by spammers, and some SMTP servers (like yours in FLA) decided that they would only except email from servers in the same stated domain - and did so without a change in SMTP. Later still, other servers decided that that was too inconvenient and started requiring a password and login (the EHLO format). Later still, others needed that login and password to be pre-encrypted. Even later, others decided to use a different encryption scheme. On and on...

The changes I just described, encompass only one portion of the SMTP format - the first line sent by a client to the server. SMTP has several hundred other "portions". Many of which have undergone similar transitions over the years.

Dedicated email programs can afford tens of thousands of lines of code needed to accomodate the variations, developments, and new capabilities of SMTP servers. Sesame has to, and should, develop to the most common denominators. When the @sendmail code was originally written, the "HELO" format was most common. Now, the "EHLO" format is most common. Because that is a major change, Sesame 2.0 implements a "dropback" - using EHLO as the default, but dropping back to HELO if EHLO does not succeed.

Because dedicated email programs usually support either command line or DDE, Sesame users can (in an some cases should), use @Shell or @ASynchShell (or in 2.0 - @CreateProcess) to take advantage of the familiarity and capabilities of their own email programs. If your email program cannot be used from command line, here are the first results from a simple Google search for "command line email client":

http://www.febooti.com/products/command-line-email/
http://www.beyondlogic.org/solutions/cmdlinemail/cmdlinemail.htm
http://email-tools.softlandmark.com/command_line_mail_tools/Softabar_Command_Lin...
http://caspian.dotconf.net/menu/Software/SendEmail/
http://www.exclamationsoft.com/exclamationsoft/default.asp
http://www.blat.net/194/
http://www.softpedia.com/get/Internet/E-mail/E-mail-Clients/AutoMail.shtml
http://www.alphaworks.ibm.com/tech/NotesCliEmail?open&S_TACT=105AGX13&S_CMP=LSDL...
http://www.soft32.com/download_9676.html

There are many hundreds of these, ranging in price from free to $50. Linux comes with the original "mail" program as part of the OS.

Quote:


As I stated, it worked for me on the two mail servers I have access to at home (Verizon and Adelphia). Both of which require the EHLO format, as opposed to the HELO format your mail server uses (I checked yours as well using telnet). So when you stated that putting a CC in the @sendmail did not work for you, I believed that your server was having a different problem.

We will look into this, Spencer.

What you need to be aware of is that it is a moving target. We may be able to put in a protocol change that will make your specific case work. However, tomorrow, your ISP may implement a new spam filtering technique and/or make a change to their configuration file that will break it again. BCC is especially subject to aggresive spam filtering. What we are doing now is perfectly legal and does not return an error. The ISP has simply decided that they, in particular, choose to not respect a BCC without a CC. We have no idea what they may choose not to respect tomorrow. Let alone the thousands of other ISPs, each of whom can make thier own choices. Each ISP is able to define their own specific rulesets. No two ISPs deal with mail in the exact same way.

While you may not care about these types of issues, we must make every effort to solve these things in ways that will serve our user base as a whole. We don't have the luxury of saying "Well, it works for Spencer and everyone else will just have to live with it." The sendmail protocol is incredibly complex and utterly configurable. Add to that the myriad of special spam filtering techniques, and we have quite a needle to thread.

We understand that you have an issue. We need to do some research to find out not only what we can do about it, but what we should do about it. This one may not get taken care of until 2.0, where the @SendMail command has been expanded to cover other current issues like authentication.