sending mails via bcc

Hi there,

i'm almost out of ideas.
i digged into the class and found that it is impossible to use the class without a to: header.
i mean it forces me to do a setHeader("to",...)
which is not required! if you send a mail in a loop to many users in bcc, everytime a to address is required, but not really needed.
i didsabled check for valid to: and count($to) in smtp_message.php but it fails now.

the to: header is not send, but instead after the C a linebreak is send or something similar.
this make the message not shown correctly in any MUA.

How can i do this?
e.g. we have 1000 recipients, rfc says max rcpt to: is 100 addresses befor it comes to violation.
so i prepare a mail to 99 recipients in BCC and send 11 Mails, each mail to 99 recp + a last mail for the rest.
This works if we use setHeader(to:) too, ok
but if i don't set a To: header, which only means adding that to: into header_data, so its simply added to rcpt to: loop too when sending recipients, after C an unnecessary \r\n or similar is send.

to disable the to-headercheck i commented out these checks as mentioned, or you get a message like 'not a valid to header is set' etc.

im confused, weird stuff.
where does this linebreak after C come from?

here is a debug output:

tellmatic.pastebin.com/f49c2f209
relevant lines which makes the message unreadable by the MUA are hightlighted.....

it would be nice if you have a quick solution here, i tried around for hours now.

thanks a lot, vizzy
tellmatic.org

debug output moved to: http://tellmatic.pastebin.com/f6f65ff16

here is what i have changed to must not use a to: header (when using cc or bcc!)
tellmatic.pastebin.com/f24a474ba

and here is how i use it, snippet: http://tellmatic.pastebin.com/f7d430ca6

thanks a lot in advance,

volker, aka vizzy

Every message must have a To: header even if it is a bogus e-mail address.

Anyway, if you are sending messages to many recipients, nowadays putting the recipient addresses in the Bcc: headers is not a good idea because many mail systems with consider spam messages on which the recipient address does not appear in visible headers like To: or Cc: .

Hello, ...

thanks for your respnse. But it does not really answer my question or mention a solution.

Yes, a to: is required, but unfortunately your class rejects a bogus emailaddress , like 'undisclosed recipients:;' which is often used to set a header for bcc mails. This makes it impossible to set a bogus email and still forces a to:.

sending mails with 100k addresses in to: needs sending each mail as a single job and is evil slow and inperformant and really not needed to use with a massmailing.

this may be a problem with some very restrictive spamcheckers, i also own and administrate a spamassassin but have never seen problems with it. if the big freemailers will do so, ok, i don't care. the user should have a look at theire spambox.

So you haven't a solution ? I hacked your class right now to not check the not needed to: header, so it is not getting rejected when set to undisclosed recipients. But its a bit weird, i dont know where this empty 'to' index is set in the headers array... where is it defined?
so i disabled the to-header checking in your class, and added a function to strip empty indexes from header ['To']
and if no To is set, i add a fake header To: undisclosed recipients:;

This works very good and i don't see Problems.

I recommend to change the Class in some way to set up a pure bcc mailing.
The to: is not needed then, and should be undisclosed.
This is common practice.
A forced to: address i n the class is a bit weird and annoying.

Anyway, the coder who uses the class should know what he is doing when not set a to: header, but this is in the coders responsibility. But it would be a good ides to support it.

Also i found that your smtp class sends about 100 rcpt to: in the server session and flushes them before waiting for OK from server. This may violate SMTP.
Unfortunately your mimessage class does not have this property, but i found one in smtp.php, great :)- i added it to smtp_message or how that file is called and all was fine.
(This may be a bug)
At about 100 rcpt to: the rfc mentions a protocol violation.
Using a default of 1 here makes it a valid smtp connection (remember tarpiting etc).

Maybe you could change that in your Class and add a method to use bcc mailings not require a valid to addresss (the class does not allow that, and gets unusable for massmailings then..., think of it: if you were an admin sending a massmail to 100k users and get a copy each 100 recipients... ;-)
setting the to: to a fake address doesn't really help, it bounces and floods the mailbox and makes a good bouncemanagement impossible.

thanks
volker
ps: sorry, my english is bad

Hello Manuel,

here are my changes to the class:

email_message.php:
tellmatic.cvs.sourceforge.net/tellm ...

and smtp_message.php
tellmatic.cvs.sourceforge.net/tellm ...


here is the function i use to strip empty indexes from the headers array:

//removes empty indexes from array, needed sometime...
//http://www.php.net/manual/en/function.array-splice.php
function array_remove_empty($inarray) {
if (is_array($inarray)) {
foreach($inarray as $k=>$v) {
if (!(empty($v))) {
$out[$k]=$v;
}
}
return $out;
} else {
return $inarray;
}
}


and here are my changes to the send routine, setting maximum_piped_recipients=1 , not using a to: header and only add a bcc header.
tellmatic.cvs.sourceforge.net/tellm ...
--
Maybe you could find a better way to do this. I mean i simply have disabled some checks for a valid recipient. But i'm sure you could find a much better way. I thought of something like a property ->useBCConly=1 or true, and if this is set to true, you could just leave out chcking for that Class-specific to: header is existing, and add a fake to: undisclosed-rec....

At least the empty index would break the message header and body because of the \n\r after C in SMTP. (see pastebin example where no to: is defined.)

If we could have a method and/or property to use the class with only bcc would be very cool.
I personally don't send spam, and i know a lot of people who send 80k non spam per day but need bcc.

Thanks in advance, i respect your work and the class is great and i really like it. it's the only really useful mail library i know because of the easy handling and especially the supported authentication features.

Oh, i forgot, ... if the smtp class supports BCConly massmailings, the mail_ and sendmail_ classes should support it too :)
Maybe its easy done, i don't know yet because i didn't look at these classes (i only use smtp now but want to support sendmail in the near future in tellmatic), maybe you can set up a filter for to=='undisclosed-recipients:;' and then don't check that email-address for rfc validity :)

My changes to the classes are only quick hacks. But it works :) I do my own email validation before adding the addresses to the header, so this way it would be 'ok' to not use internal checking methods.

Volker, aka vizzy

I changed the classes to check if there is at least one valid recipient in To:, Cc: and Bcc: headers. The fixed version was just uploaded.

Regarding queueing RCPT requests without waiting for server responses, that is supported by the SMTP server that exposes the SMTP PIPELINING extension.

If you do not want to handle bounces of messages sent to invalid addresses, just set the Return-Path header to a an address associated to a mailbox that discards messages.

Other than that, if you omit recipients from visible headers, at least Hotmail will discard the messages. I think the messages will not even appear in the junk folder.

Another point is that when you relay messages to an SMTP server, you are not really delivering the messages. They just are queued in the MTA that serves the SMTP server. The actual deliver of the messages to all recipients may take days to finish, probably when the MTA gives up attempting to deliver to undeliverable addresses.

Despite it takes more time to queue all messages, sending separate messages to each recipient is a more reliable way to have your messages accepted by most of the recipients.

The class provides body caching support to minimize the overhead of queuing messages to many recipients.