Submissions per connection/session

[twisted1919]

@frm.mwz / @VVT - The limit in mailwizz is 1 by default, so it's exactly what happens now, one message per connection. You can now adjust this for any smtp server from backend, and change from 1 to whatever your server supports.
Swiftmailer doesn't have a keep alive feature unfortunately, so i am not sure how we will go about it. We don't destroy the connection for swiftmailer either, so if swiftmailer doesn't close it after sending we should be good, but i think it does.
If @VVT can run a few tests with swift as well, this would help.

 

[frm.mwz]

#1
how do these two work together:

By default we allow 100 emails per connections.

and

The limit in mailwizz is 1 by default

?


#2.1

Swiftmailer doesn't have a keep alive feature unfortunately

have you seen my post re the swiftmailer plugins
which allow to
!keep alive a connection! until a specified # of msgs is submitted?
from
https://forum.mailwizz.com/posts/13253
-----
swiftmailer has plugins to
(limit the number of emails per connection,
which incidentally do
until that number of emails has been transferred)
keep alive the connection...
and they are mentioned in the documentation here
\apps\common\vendors\SwiftMailer-5x\doc\plugins.rst
though am not sure if they are used already
what do u think @twisted1919
-----
are they in use
?

#2.2
specifically the 'AntiFlood Plugin'
as this seems to be usable for exactly the purpose here
!keeping the connection open! until a set # of msgs is transferred
?

#2.3
or is there a reason why it cannot be used
?


#3

You can now adjust this for any smtp server from backend, and change from 1 to whatever your server supports.

that's great!


thx

 

[twisted1919]

#1
how do these two work together:
and
?

That changed, from now on we start with one email/connection which can be modified from the smtp server settings.

#2.1
have you seen my post re the swiftmailer plugins
which allow to
!keep alive a connection! until a specified # of msgs is submitted?
from
https://forum.mailwizz.com/posts/13253
-----

We use all of those, but none of them is meant to keep alive the connection as far as i can see.

#2.2
specifically the 'AntiFlood Plugin'
as this seems to be usable for exactly the purpose here
!keeping the connection open! until a set # of msgs is transferred
?

Not quite, the anti-flood plugin keeps an internal counter of messages sent per defined period of time. When sending the message the connection is opened , message send, connection closed.

or is there a reason why it cannot be used
?

What exactly?

 

[frm.mwz]

We use all of those, but none of them is meant to keep alive the connection as far as i can see.

The AntiPloodPlugin will
!keep alive! any single connection until the specified # of msgs is sent.
I thought that was what was wanted:
maximize # msgs / min # connections.

per defined period of time

"per defined period of time" is not a variable of the AntiFloodPlugin
The AntiFloodPlugin
knows only two parameters:
the number of emails to pause after, and optionally
the number of seconds to pause for.

From this you can see, that
SwiftMailer was actually made with !keep alive connections! in mind,
it is only that mwz was looping in a way

each email a new connection is spawned

one message per connection

that it was disconnecting after each msg.

none of them is meant to keep alive the connection as far as i can see

See here, from the plugin description:
"
When Swift Mailer sends messages it will count the number of messages that
have been sent since the last re-connect. Once the number hits your specified
threshold it will disconnect and re-connect, optionally pausing for a
specified amount of time.
"

Also, having had it at default 100, perhaps it was the reason (in some
cases) that pcntl balloned out of control?

In any case,

from now on we start with one email/connection which can be modified from the smtp server settings.

and is there a way (except) asking/reading, to test the max # msgs/connection right there in the settings with a button (and a test script behind it)?

 

[VVT]

the rfc is 100 (gmail e.g. will accept only 100 recipients max per message),
but what the delivery server admins (e.g. gmail, sendgrid, cluster) set is up to them (as usual).

as stated before, if it is your own solution (own delivery server, cluster, etc), that may differ,
but if it cannot be set in mwz for each delivery server (which will only now come up),
then it is wise to leave it at the rfc recommendation (100), as this avoids problems.
(and this is what @twisted1919 did, see above)

it's not personal, just trying to provide facts, to help avoid trouble-making settings,
if e.g. someone reads this thread and thinks, hey, let's slap 10k in there

Just wanted to tell that it wasn't the 100 conn thing stopping me from gaining more speed. Also, guess we're messing the concepts here - recipients per message and messages per connections are different things, like gmail (unless relaying) and MTA. Obviously postfix is not my OWN solution and it supports until 1k (haven't tested after that limit) msgs/conn by default. And this limit may differ from one another. So, if stability is the idea, best is to keep 1 msg/conn as default as it does now.

@twisted1919 I'll test Swiftmailer. But I was using that in the past and haven't seen any performance boost. So don't think it keeps the conn alive (may be in our case). Good news is that PHPMailer is now an ongoing project and can see frequent commits in Github. In the case of SwiftMailer, AntiFlood plugin gives a hint that SwiftMailer will keep the conn alive by default and the so called plugin can control that behaviour. May be the server change thing is affecting Swift as well as it did for PHPMailer ?

 

[twisted1919]

@frm.mwz - if that plugin keeps the connection alive, then we should be fine, as i said, we're using it. Anyway, it seems very dumb to work like advertised. I mean, you open a connection, send x messages then keep the connection open just to wait...? Anyway.
@VVT - see above.

 

[frm.mwz]

recipients per message and messages per connections are different things

if a mail server accepts only 100 recipients per message, then that is
because it has to create then 100 messages to be sent out

Obviously postfix is not my OWN solution

own solution does not mean you programmed it, it means someone is in
control of the settings for that postfix instance
(e.g. you at your own server w postfix)

this limit may differ from one another

exactly what i said

if stability is the idea, best is to keep 1 msg/conn as default as it does now

yes, of course, but the idea of the thread was...to max msgs/min conn.

AntiFlood plugin gives a hint that SwiftMailer will keep the conn alive by default and the so called plugin can control that behaviour

It does exactly what you see in my post above, as that is from the
description of the plugin. Only two variables: # msgs/conn; pause time.

May be the server change thing is affecting Swift as well as it did for PHPMailer

that is exactly what @twisted1919 wrote some post above

it seems very dumb to work like advertised. I mean, you open a connection, send x messages then keep the connection open just to wait...? Anyway.

The idea of being connected for # msgs, then disconnect, and then reconnect,
is most likely to be found in "readiness" to send further more...i.e. SPEED
...not so dumb after all?!?

 

[VVT]

@frm.mwz Ok Sir . Not replying point to point to spam this thread , but mentioning 100 "To" emails on a message and submitting 100 emails with 1 "To" email on a single connection are different things - the first one is the problematic setting most SMTPs putting low limit on.

 

[frm.mwz]

@frm.mwz Ok Sir . Not replying point to point to spam this thread , but mentioning 100 "To" emails on a message and submitting 100 emails with 1 "To" email on a single connection are different things - the first one is the problematic setting most SMTPs putting low limit on.

whenever you have good points to add, that would not be viewed as spam by anyone reasonable

not sure where a misunderstanding is...
...if a server accepts only 100 smtp emails per connection, then it does not matter if it is 100 unique messages during the whole connection or 1 message with 100 recipients...as it has to send out 100 messages thereafter

the server settings in general were not my point, as they are individual per ISP/ESP (yes, they are not all RFC compliant)

 

[VVT]

@frm.mwz - if that plugin keeps the connection alive, then we should be fine, as i said, we're using it. Anyway, it seems very dumb to work like advertised. I mean, you open a connection, send x messages then keep the connection open just to wait...? Anyway.
@VVT - see above.

#1 I switched to Swift and could see individual connections per delivery.
#2 Guess (as the doc reads) it's not the plugin that keeps the conn alive, but the plugin breaks the conn after x msgs to prevent 'flooding'.
http://swiftmailer.org/docs/plugins.html#antiflood-plugin
#3 My Settings > Common page on the admin dashboard has been broken since I replaced the 'mailer' folder. Please suggest a fix.


@frm.mwz Yeah, I thought we made our points clear

 

[frm.mwz]

My Settings > Common page on the admin dashboard has been broken since I replaced the 'mailer' folder

same thing here: settings->common = broken (same screen shot as above)
all other screens ok

it's not the plugin that keeps the conn alive, but the plugin breaks the conn after x msgs to prevent 'flooding'

The thread is about 'submissions per connection/session'
and the plugin helps to max that.
Hence, one needs to look at the plugin functions' implications
that's why you find here https://forum.mailwizz.com/posts/13253

swiftmailer has plugins to (limit the number of emails per connection, which incidentally do until that number of emails has been transferred) keep alive the connection

(keep in mind a mailer is there to make connections and transfer msgs
ie to keep alive connections til that number of msgs is transferred,
it can be one, but that plugin allows to specify how many, and
for that time til done, the connection stays alive)

if swiftmailer doesn't close it after sending

in the mentioned documentation file
apps\common\vendors\SwiftMailer-5x\doc\plugins.rst
it says that swiftmailer (also by way of that plugin which is in the mwz code) takes care of closing connections
"...disconnect after that number of emails has been sent. You could manage this manually within a loop, but the AntiFlood plugin provides the necessary wrapper code so that you don't need to worry about this logic."

I switched to Swift and could see individual connections per delivery

perhaps mwz <=1365 still loops (open/close connection) for each msg, but the new version might fix it

one email/connection which can be modified from the smtp server settings

after applying the mailer patch above, could not find that setting in smtp delivery server settings (existing or new smtp delivery servers)

the first one is the problematic setting most SMTPs putting low limit on

To clarify perhaps by way of example, last time checked, gmail said it will accept 100 messages per day max from an smtp client, whether that is 100 recipients in one or 100 individually submitted messages (or any other spread of 100 recipients). That is as stated above, because it needs to then send out 100 individual messages, no matter how submitted.
You'll find similar logic (though different limits) e.g. at smtp.com, etc.

 

[VVT]

Hey @twisted1919 ,

1. Hope you saw the issue re "common settings" page above.
2. I noticed another malfunction, but that's not related to the "mailer" directory. While using PHPMailer, return path is always set as From Email, but not the email address we specify with the associated bounce server. It should work just like Swift mailer, means, if no verified sending domains, return path must be set as the bounce server email address.

 

[pradeep sharma]

@VVT

i resolved above problem.
I had fix the problem uncommenting line 300 of file:
apps/common/components/mailer/MailerPHPMailer.php

please give it a try!

 

[twisted1919]

@VVT - i think the "common settings" issue is caused by the MailerDummyMailer mailer. Please unzip attached and put in the mailer folder to override existing MailerDummyMailer.php file.
As for the FROM Email, nothing has changed in this regard, but i will have a look over.

 

[frm.mwz]

fix the problem uncommenting line 300 of file:
apps/common/components/mailer/MailerPHPMailer.php

you mean this fixes the FROM problem in phpMailer?

@twisted1919 can u check this?

 

[frm.mwz]

uncommenting line 300 of file:
apps/common/components/mailer/MailerPHPMailer.php

can you please quote the line and a few around it, as my line 300 is...empty

 

[frm.mwz]

the "common settings" issue is caused by the MailerDummyMailer mailer. Please unzip attached and put in the mailer folder to override existing MailerDummyMailer.php file

the 'common settings' issue is visually gone...but considering the file is now also smaller, hopefully no functionality was cut out?

start with one email/connection which can be modified from the smtp server settings

the "email/connection" settings does not appear in delivery server settings, what must be done?

 

[twisted1919]

the "email/connection" settings does not appear in delivery server settings, what must be done?

This will appear in next release, it's too many files changed to simply put it here

 

[frm.mwz]

This will appear in next release, it's too many files changed to simply put it here

Good to know, as from the above it seemed one should be able to find this setting.
For the time being, is it better to use the original files of the 'mailer' folder, or better use all patches?
Any ETA?

 

[twisted1919]

For the time being, is it better to use the original files of the 'mailer' folder

Yeah you can do that.

Any ETA?

Hopefully soon