All of the spf issues spply to dmarc as well. . But I still assert that the answer is that these addresses are intended for inbound only and that the problem is unsolvable if they are used for outbound.
Verisign could certainly do something different, but it is not in their interest to do so. This is identical to alumni forwarding services. They work for inbound but cannot be authenticated for outbound On Thu, Jun 2, 2022, 7:08 AM Alessandro Vesely <ves...@tana.it> wrote: > On Wed 01/Jun/2022 20:01:58 +0200 John Levine wrote: > > It appears that Barry Leiba <barryle...@computer.org> said: > >>(Not about Phill's message in particular: his is just the most recent > >>one to reply to.) > >> > >>This was a fine topic to ask about, and the early discussion answered > >>the initial questions -- and pointed out, correctly, that this isn't a > >>DMARC issue. The continuing discussion is definitely out of scope for > >>the working group. ... > > > > In the unlikely event there is any blood left in this turnip, the spfbis > > list is still active and seems like the logical place to argue about > > changes to SPF. > > > The only droplet is the consideration that if Verisign hasn't got it, > there > must be a whole bunch of people who think that sending email is in the 90s. > > That implies we must say something more loudly and more clearly. > > > > Note replies directed there. > > > Sorry, but this is not an SPF issue. David's message arrived at IETF with > a > helo name of wforward1-smtp.messagingengine.com, which has a correct SPF > record, and a DKIM signature by d=messagingengine.com. Perfectly > authenticated, then, except for alignment. > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
