Find a smtp server to send out emails
Hi, This problem is not caused by mailman, but I still want to give it a shot here. I'm hosting a mailing list on top of mailman3. Emails are supposed to be sent out by AWS ses. However, ses requires that sender address must be verified, which leads to a problem that emails sent by subscribers to mailing list cannot be sent to other subcirbers, since their addresses are not verified. And it is impossible to verified every subscriber. Are there smtp service providers allowing unverified email address to send out emails, or do I have other solutions?
Thanks.
-- Best wishes, Leon
Here are some possible solutions:
Use a Generic Verified Address: Configure your list to use a verified email address for sending, while allowing subscribers to send emails under that address.
SMTP Relay Providers: Services like SMTPmart, Mailgun, SMTPget or Postmark may allow you to send emails from unverified addresses through their systems, with proper configuration.
Email Forwarding: Set up a forwarding system to act as a middleman for unverified senders.
I hope one of these solutions works for you! Let me know if you need more help.
Aside from the solutions Roni mentions, if alternative hosts are being considered, when I looked about 4 months ago Google Cloud was providing unrestricted outgoing mail to selected customers. No idea what the selection criteria are though.
Roni Tim via Mailman-users writes:
Here are some possible solutions:
Use a Generic Verified Address: Configure your list to use a verified email address for sending, while allowing subscribers to send emails under that address.
This might work. On Sendgrid's free tier, that's what I do. All my users are at a single university system, hosted by Outlook365, though, so I can't promise that other systems or user agents don't look at the SMTP envelope From. This doesn't affect the incoming envelope From, of course -- Mailman can still use that to identify the sender if you configure it that way. Also it's mostly for announce lists, so generic traffic is probably untested (or maybe the students don't care if they don't get the messages.
But I don't think it would work on AWS/SES, because Mailman already changes the return path to itself so it can handle bounce processing. So if SES is complaining about an unverified address, I guess that must mean the header From address. Have anybody actually tried this, and verified that SES checks header From? ISTR we tested this when we were trying to use SES, and it required the envelope sender to be verified, but not the header From. I don't recall if we tested for an issue with DMARC From alignment, though. (That wouldn't have been a problem because we DMARC-munge and then DKIM sign, so we may not have tested that.)
In my experience, SES is a poor platform for hosting Mailman. It can be done, but they maintain their excellent reputation for "clean" mail flows with some of the most severe restrictions in the industry:
- they replace Message-ID with one of their own, which clobbers both downstream users' local deduplication and HyperKitty threading (or any archiver that gets mail directly from a Mailman plugin rather than by subscribing to the list: mail-archive.com isn't affected)
- they allow only one DKIM-Signature header
- they restrict use of other headers (I forget offhand, the two above were most troublesome)
- I don't think they provide ARC processing. While Mailman 3 can do it, it's better done at the MTA level (especially if the MTA pays for all the crypto processing, not you!)
SMTP Relay Providers: Services like SMTPmart, Mailgun, SMTPget or Postmark may allow you to send emails from unverified addresses through their systems, with proper configuration.
The only one of the above we looked at was Mailgun. I don't remember why we preferred Sendgrid, though, so it wasn't a huge difference.
Email Forwarding: Set up a forwarding system to act as a middleman for unverified senders.
If this means translating the address in both directions, one of my clients does this for DMARC reasons, but it's a hairball. Among other things, it seems difficult to automate it in a way that doesn't provide a open relay. We hope it will not be exploitable (it hasn't been exploited yet), but we're not 100% sure it can never be.
Steve
participants (3)
-
Leon
-
Roni Tim
-
Stephen J. Turnbull