BCC Maximum (E-Mail) ?

[cdgrit]

Ik heb een eigen server waar o.a. sendmail op draait. Voor een klant maak ik een PHP script die straks maandelijks een mailing gaat versturen. Dit naar ongeveer 1000 e-mail adressen/klanten.

Kan ik al deze 1000 adressen in een BCC proppen of gaat mijn servertje het dan erg zwaar krijgen? Wat is het maximum aantal adressen dat je in de BCC kwijt kunt?

[Anoniem: 30890]

Opzich moet dat wel kunnen, maar om de server te ontlasten kun je beter in batches zenden van bijvoorbeeld 20 per minuut. Ook slim is om de batches te soorteren op @domein.nl ivm de manier waarop bcc werkt

[ Voor 26% gewijzigd door Anoniem: 30890 op 12-06-2003 11:07 ]

[paella]

Zit er ook niet een max aantal tekens voor een header-regel? Misschien niet volgens de RFC, maar er zijn vast MTAs die erover kunnen vallen als het te lang wordt? Voor de zekerheid ook daarom dus wat minderen.

[cdgrit]

De scripts zijn klaar en de mailing gaat verzonden worden naar 1.800 e-mail adressen. Op dit moment zet ik al deze adressen in 1 lange regel gewoon in een BCC. Gaat dit werken? Er draait sendmail 8.12.3 op.

Hoe zou ik het eventueel kunnen opsplitsen? Zodra er op een verzend button geklikt wordt word er een PHP script aangeroepen die de mailing start. Opsplitsen wordt lastig, omdat je niet nu op 'verzenden' kunt klikken en dan +/- 500 mailtjes versturen en dan 20 minuten later automatisch de volgende 500. Hoe zou ik dat kunnen oplossen?

[Stewie!]

Batches van 20/minuut is onzin, het werkt allemaal veel sneller, wat ie niet zo snel aan klan gaat in de queue. Gewoon 18 emails van 100 bccs versturen, dan werkt alles snel en goed -> binnen 10 seconde klaar

als je 1 mail verstuurt met 1800 bcc, dan verstuur je maar één mail. De smtp van je isp zorgt voor de rest

[ Voor 22% gewijzigd door Stewie! op 24-06-2003 18:08 ]

[intoxicated]

RFC 2821 (Simple Mail Transfer Protocol), 4.5.3.1 Size limits and minimums :
message content
The maximum total length of a message content (including any
message headers as well as the message body) MUST BE at least 64K
octets. Since the introduction of Internet standards for
multimedia mail [12], message lengths on the Internet have grown
dramatically, and message size restrictions should be avoided if
at all possible. SMTP server systems that must impose
restrictions SHOULD implement the "SIZE" service extension [18],
and SMTP client systems that will send large messages SHOULD
utilize it when possible.

Het zou dus mogelijk kunnen zijn dat een mail met headers die totaal meer dan 64KB is, wordt geweigerd. Maar vziw gebeurt dat tegenwoordig idd vrijwel nooit meer.

recipients buffer
The minimum total number of recipients that must be buffered is
100 recipients. Rejection of messages (for excessive recipients)
with fewer than 100 RCPT commands is a violation of this
specification. The general principle that relaying SMTP servers
MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
tests on message headers suggests that rejecting a message based
on the total number of recipients shown in header fields is to be
discouraged. A server which imposes a limit on the number of
recipients MUST behave in an orderly fashion, such as to reject
additional addresses over its limit rather than silently
discarding addresses previously accepted. A client that needs to
deliver a message containing over 100 RCPT commands SHOULD be
prepared to transmit in 100-recipient "chunks" if the server
declines to accept more than 100 recipients in a single message.

Dus, als je geen Error 452 of 552 krijgt, kan je er vanuit gaan dat je mail goed aankomt.

[cdgrit]

intoxicated schreef op 24 June 2003 @ 18:13:
[...]
Het zou dus mogelijk kunnen zijn dat een mail met headers die totaal meer dan 64KB is, wordt geweigerd. Maar vziw gebeurt dat tegenwoordig idd vrijwel nooit meer.

Even getest: De headers worden +/- 45 KB groot dus dat zal wel goed komen.

[Anoniem: 30890]

DaMorpheus schreef op 24 June 2003 @ 18:08:
Batches van 20/minuut is onzin, het werkt allemaal veel sneller, wat ie niet zo snel aan klan gaat in de queue.

Dat is geen onzin, de serverload schiet als een gek omhoog (met alle gevolgen vandien) als je ineens honderden mails tegelijk zend, ook al komen ze in de queue. Als je dit vooraf afvangt, werkt het het beste.

[Stewie!]

Anoniem: 30890 schreef op 24 juni 2003 @ 18:43:
[...]

nou, ik verzend op het werk vaker 100.000+ mails
denk dat ik wel weet wat de serverload dan doet
NIKS
Je dns/remote smtp/inetconnectie zijn langzamer dan je compu aankan.
En dan vormt zich een mooie queue En die heeft met geheugen te maken, niks met processor. Als je geheugen vol loopt wordt automagisch de hgd gebruikt natuurlijk

Het is dus wel onzin

[ Voor 37% gewijzigd door Stewie! op 24-06-2003 21:23 ]

[Stewie!]

oeps

[ Voor 171% gewijzigd door Stewie! op 24-06-2003 21:23 ]

[Anoniem: 30890]

DaMorpheus schreef op 24 June 2003 @ 21:20:
[...]

nou, ik verzend op het werk vaker 100.000+ mails
denk dat ik wel weet wat de serverload dan doet
NIKS
Je dns/remote smtp/inetconnectie zijn langzamer dan je compu aankan.
En dan vormt zich een mooie queue En die heeft met geheugen te maken, niks met processor. Als je geheugen vol loopt wordt automagisch de hgd gebruikt natuurlijk

Het is dus wel onzin

Ik kan je uit ervaring vertellen dat het wel degelijk de load zwaar beinvloed. Heb veel klanten met mailinglijsten en grote mailinglijsten verhogen de load zo erg, dat het merkbaar word bij het opvragen van webpagina's vanaf de betreffende server.

[Stewie!]

Anoniem: 30890 schreef op 24 June 2003 @ 21:47:
[...]

Ik kan je uit ervaring vertellen dat het wel degelijk de load zwaar beinvloed. Heb veel klanten met mailinglijsten en grote mailinglijsten verhogen de load zo erg, dat het merkbaar word bij het opvragen van webpagina's vanaf de betreffende server.

kwestie van limiteren van recources voor de mailapp.
Anders zet je toch een dedicated server neer in de serverparkje.

Zo doen wij het namelijk wel

Bovendien, via de bcc methode verstuur je ipv 100 000 mails, bijv. nog maar 1000

[ Voor 11% gewijzigd door Stewie! op 24-06-2003 22:12 ]

[cdgrit]

intoxicated schreef op 24 June 2003 @ 18:13:
Het zou dus mogelijk kunnen zijn dat een mail met headers die totaal meer dan 64KB is, wordt geweigerd. Maar vziw gebeurt dat tegenwoordig idd vrijwel nooit meer.

Hmm.... Het werkt dus niet. Ik krijg de melding "552 5.6.0 Headers Too large (32768 Max)".

Heb in sendmail.cf de waarde van MAX_HEADERS_LENGTH veranderd in 65536 en hoop dat het nu wel werkt. Ik ga het morgen testen...

[Stewie!]

cdgrit schreef op 26 June 2003 @ 18:32:
[...]

Hmm.... Het werkt dus niet. Ik krijg de melding "552 5.6.0 Headers Too large (32768 Max)".

Heb in sendmail.cf de waarde van MAX_HEADERS_LENGTH veranderd in 65536 en hoop dat het nu wel werkt. Ik ga het morgen testen...

waarom niet minder dan 30000 headers gewoon, schrijf het scriptje gewoon eenmaal en je kan later bij 100 000+ mails ook nog gewoon sturen met hetzelfde script!

[cdgrit]

Hmmm... Het werkt nog steeds niet. Ik krijg nog steeds de melding dat 32768 het maximum is terwijl ik deze in sendmail.cf toch heb verhoogd. Uiteraard heb ik sendmail reload. Iemand die weet hoe ik het maximum kan verhogen?

[paella]

Komt die melding wel van jouw sendmail?

[cdgrit]

paella schreef op 27 juni 2003 @ 12:11:
Komt die melding wel van jouw sendmail?

Ja, komt van mijn sendmail...