1. 9
  1.  

  2. 3

    I sent a test message. It was accepted.

    1. 4

      Great! Now repeat until it gets rejected :)

      1. 4

        I managed to botch my remote concurrency limit, so this batch will have to arrive in 20-connection chunks.

        Once I fixed that problem, I finally did get some deferrals. I also notice that some/many connections are established, but take a long time to complete. Maybe they’ll timeout. This is as much a test of my system as theirs; I’ve never run an outgoing mail queue this large.

        1. 3

          Whatever your limits are you are still helping even if you are adding just a single connection :) Thanks for chipping in!

    2. 3

      OpenSMTPD now reports they are standing down, though we’re promised another chance tomorrow.

      That was certainly fun, and I did get to stress test my own system. It seems a bit ad-hoc though: you certainly can determine how many simultaneous deliveries can be made, but how do you know the total number of attempts? Without cooperation from your relay, you don’t know how many messages failed.

      1. 1

        I’m confused why they don’t use their own servers to generate traffic. If you know exactly how much traffic is being sent, vs. how much your OpenSMTPD server is handing it is more useful than asking strangers on the internet to try and DoS you with email. There are dozens of SMTP server stress test applications in the wild, postal seems like a decent GPL one. You could even write your own mail sending script.

        1. 1

          Stress test applications are not real life and funky clients. There are people with weird/specific setups that could expose real life bugs. The point of a stress test is to test real life scenarios.