It would be very unusual if it did. And wrong, given that Groups.io's servers are not in any way under the control of the member's email service.
That is correct regarding SPFs and that is why a server doing SPF checking is going to consider an email "from" domain X is invalid because it came from groups.io servers. My example has nothing to do with DMARC but shows how "spoofing" that an email is directly from someone is, in fact, a red flag to proper email handling.? Other mail lists do not do this type of spoofing and are therefore not blocked.
The only services that should be having that kind of issue are those that have elected to use a "reject" policy in their DMARC records. Those services are incompatible with traditional mailing lists, but Groups.io (and Y!Groups and some others) have adapted to that. Most other lists I'm on simply don't support users of those services as members.
There are servers that do not use DMARC records but still block email for internal domains that appear to originate from outside.? DMARC is a relatively recent addition to email processing and most private/enterprise servers do not rely on DMARC for protection.? Your statement "Most other lists I'm on simply don't support users of those services as members" is myopic at best. I found a number of examples in this forum of major services not allowing that type of spoofing and I am a member of a number of other list providers (beyond Y!Groups but including Y!Groups) who alter the "from" address so SPAM filtering algorithms that are based on sender domains do not block list messages.? By altering the "from" address to show the message was originated via the group (which it is) ensures proper delivery under all cases by allowing users to unblock groups.io at a level available to users (as most users cannot alter corporate or ISV rules regarding rogue email generation from outside).
No, only in the case of a reject policy in their DMARC record, I think, and that's handled.
Again, this statement is, at best, myopic and stating "if your email provider does this type of blocking and is not using DMARC, we won't support you." tells the millions of users out there that are using those type of services "Too, bad; we are going to remove a level of protection by spoofing your email address to appear to be generated from our servers instead of yours."? Worse, this is not explained anywhere in groups.io information on what would cause bouncing that was not occurring in groups that get transferred and we are stuck with the transfer and a large number of users who no longer can use the service.
If their rule were that simple their users couldn't participate in mailing lists at all - at least not lists that have fellow users. That is, if both Alice and Bob use 's service, they'd not be able to see each other's posts.
The only services that should be having that kind of issue are those that have elected to use a "reject" policy in their DMARC records. Those services are incompatible with traditional mailing lists, but Groups.io (and Y!Groups and some others) have adapted to that. Most other lists I'm on simply don't support users of those services as members.
As Dave indicated, there are many organizations? that have this rule and have had no problem with mail lists -because- the email is properly denoted as having originated via the list, not from that organization.? This type of policy predates DMARC usage and most lists that predate DMARC alter the from address to indicate the message is from the list, not directly from the individual.? This simple indicator resolves SPF failures and internal domain blocking algorithms that have nothing to do with or predate DMARC.
You indicated getting this option in "beta".? How do I do that and how do I get my groups set up to be part of that beta?
Pete
