split outgoing email into batches to work around max number of recipients limit in some SMTP providers (infomaniak) #4319
Comments
sfindeisen
added
type:discuss
sfindeisen
changed the title
sfindeisen
changed the title
|
workarounds:
the limit is indeed a bit ridiculous. to prevent abuse, the system should use a cool-off timer over the total amount of deliveries an account generates, not each message. |
|
I just bounced an email to 2 other addresses of mine, and they're both visible in |
I think something that's missing in your description but is kind of implied by "throttling" is "in the background". NeoMutt is single-threaded, so running this batch-sending in the background would imply a major refactoring. What I'd look into, is to send emails via some local program instead of SMTP, and do the batching at that level. I'm not aware of an MTA that does that - a cursory glance at sendmail's man page didn't reveal anything - but perhaps there's something out there :) |
What would you like to be able to do?
Some Email providers, for example this one: https://www.infomaniak.com/en/support/faq/580/limits-on-the-number-of-e-mail-recipients (a major one in Switzerland, Europe) reject outgoing mail if the number of recipients (including
Bccaddresses) is too large (more than10in this case). I would like to be able to compose and send my email as usual, and let neomutt make multiple emails out of one on send (with some throttling perhaps?) so as to circumvent this absurd limit.What needs to change in NeoMutt?
Perhaps a new command like: "split this email into multiple ones and send them one by one, so that the number of recipients in each does not exceed
L", whereLcould either be an argument to the command or perhaps a configuration file parameter. If there are anyTo:orCc:addresses, those should be copied over to every copy, but, ideally, in the actual SMTPRCPT TO:commands they should appear only once.I hope no provider will reject Email based on missing
RCPT TO:, as compared toTo:orCc:field contents...Have you tried any alternative methods?
Not really, what would be the best way?
I agree this feature would be somewhat arcane and so it is worth asking if building it into the neomutt core makes sense and justifies the added complexity. Let's maybe wait and see if there are any other major SMTP providers with this limitation?...
If this can be solved with a macro, hook or a script then I think that should be the preferred way. I am posting this issue anyway with the hope to streamline the discussion.
The text was updated successfully, but these errors were encountered: