errors recently?)
>
I've seen as yet unconfirmed speculation that this might be the error
response Yahoo is using for those that don't comply with the new (as of
today) requirements that mail be authenticated using SPF, DKIM, and DMARC.
See also - https://senders.yahooinc.com
On Mon, Jan 29, 2024 at 12:24 PM Scott Mutter via mailop
wrote:
> On Mon, Jan 29, 2024 at 10:01 AM Todd Herr via mailop
> wrote:
>
>> Users can only click "This is spam" on messages that end up in their
>> inbox. If all of your traffic went to the spam fo
not have an FBL service, so there's no way
> to get this level of information from Google.
>
They have a Feedback Loop, but it's not a traditional one. It's part of
their Postmaster Tools -
https://support.google.com/a/answer/6254652?sjid=15660904710347572920-NA
--
*Todd Herr *
d I think this is fine and that it's perfectly
> okay for the BIMI Group to do it this way too.
>
>
A self-asserted logo as you have and as the domain bimigroup.org has is
certainly valid from a specification perspective; however, not all mailbox
providers that participate in BIMI sup
ight be rather a challenge for an independent MUA to perform the
required DMARC validation of the message, but I am not a developer of MUAs
and so cannot do any more than suspect this to be true.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:*
ards
> 3. Catch every animal you see
> 4. Compare the animal to a lion
> 5. Stop if a match is detected
>
> Unfortunately Sabre didn't implement step 5.
>
>
You forgot step 0 - Insert a lion at the southernmost tip of Africa,
because otherwise you might never execute
On Fri, Jun 16, 2023 at 10:11 AM Jaroslaw Rafa via mailop
wrote:
> Dnia 16.06.2023 o godz. 09:31:58 Todd Herr via mailop pisze:
> > Yes, the DMARC protocol does describe the search for the organizational
> > domain for the RFC5322.From domain in an email message.
> >
>
; hostnames (that's DKIM), but it does
currently rely on the Public Suffix List to determine the organizational
domain in cases where there is no DMARC policy record published for the
RFC5322.From domain.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:*
nk you very much,
> this is really helpful!
>
> --
> -- Andreas
>
> :-)
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This e
On Tue, May 23, 2023 at 4:13 PM Benny Pedersen via mailop
wrote:
> Todd Herr via mailop skrev den 2023-05-23 20:54:
>
> >> Indeed, an email will only be rejected if it has DMARC setup as
> >> reject.
> >
> > There should be one exception to the rule of waitin
d:
"v=spf1 -all"
It seems wholly appropriate to reject at MAIL FROM if the RFC5321.From
domain publishes an SPF policy that says "This domain is not used to send
mail, ever."
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.22
only available to the mailbox holder for messages
not already in the spam folder.
How would you propose training a client to distinguish obvious ham from
obvious spam for messages that have been delivered to any folder other than
the spam folder?
--
*Todd Herr * | Technical Director, Standards
rom the email with my end email redacted:
> https://pastebin.com/knqbTa8K
>
> Thank you!
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
--
*Todd Herr * | Technical Director, Stand
nizations using
multiple services to send their email, and while there are known ways to
skin that cat, there isn't a universally adopted method for doing so.
Is the survey investigating problems faced by operators doing SPF
validation or operators publishing SPF records or both?
.
>
You don't say what domain you didn't rewrite, but is it possible that the
domain in question on the rejected message has an SPF record ending in
"-all"?
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
bs, among others, have some ideas on how to mitigate such things.
Perhaps you might find those ideas useful -
https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability/
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@vali
On Wed, Feb 16, 2022 at 10:58 AM Sinclair, John via mailop <
mailop@mailop.org> wrote:
> Valid email (supposedly) from petvetcarecenters.com to
> drew.q.tay...@gmail.com, and it got delivered to MY domain (mspca.org)…
>
>
>
My presumption would be that you were bcc'd
GoDaddy-hosted domains.
Thanks.
--
*todd herr*
*postmaster www.sparkpost.com <http://www.sparkpost.com>*
*twitter* @toddherr @sparkpost
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com
___
mailop mailing list
mailop@mailop.org
https://ch
er they want to
> move every domain they own to SPF soft fail instead, so I wanted to ask
> around and get a feel for how common this is before they change all of
> their many domains.
>
>
> Thanks,
>
> Autumn Tyr-Salvia
> atyrsalvia@agari
> tyrsalvia@gmail
> _
;
> Signal Spam works with law enforcement authorities and security companies
> and initiative (among others) to help punishing ... bad people.
>
>
>
> I'll notify the Signal Spam folks.
>
>
>
> Thanks again!
>
>
>
> --
> *Benjamin*
>
>
&
sical addresses,
different operating models, it appears. However, I would like to get an
official pronouncement from someone more knowledgeable than I that the two
organizations are completely unrelated.
Thanks in advance.
--
*todd herr*
*postmaster www.sparkpost.com <http://www.sparkpost.com
ot;leap of faith" that
> p=none's monitoring mode was supposed to alleviate.
>
> Thanks,
> Jesse
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
--
If so, please contact me off-list.
Thank you.
--
*todd herr*
*sr. delivery engineer www.sparkpost.com <http://www.sparkpost.com>*
*twitter* @toddherr @sparkpost
*tel* 415-578-5222 x477
*mobile* 703-220-4153
*email* todd.h...@sparkpo
rocess.
Thanks.
--
*todd herr*
*sr. delivery engineer www.sparkpost.com <http://www.sparkpost.com>*
*twitter* @toddherr @sparkpost
*tel* 415-578-5222 x477
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com
___
mailop mailing list
ma
can see. It appears to be only in what postmaster tools is displaying,
> rather than the actual reputation. Sorry for not being clearer on that
> point in my initial response.
>
> Thanks,
> Matt Gilbert
> - Deliverability Engineer, MailChimp
> - delivery.mailchimp.com
>
> On
When you say "impacting 100% of our IPs as well" are you really seeing an
impact on delivery, or are you just seeing likely erroneous data displayed
in Google's Postmaster Tools.
We're seeing the same data as everyone else, but we haven't yet seen that
there's been a real impact on delivery or eng
to suppress these
going forward, so I just want to understand what the bounce is really
telling us so we can make the right decision.
Thanks again.
--
*todd herr*
*sr. delivery engineer www.sparkpost.com <http://www.sparkpost.com>*
*twitter* @toddherr @sparkpost
*tel* 415-578-5222 x477
mail from a sender, and therefore should be suppressed,
or if it's another example of some sort of configuration issue, as cited on
the first linked page.
Thanks!
--
*todd herr*
*sr. delivery engineer www.sparkpost.com <http://www.sparkpost.com>*
*twitter* @toddherr @sparkpost
*
We're seeing lots of our cloud provider (AWS) space listed in the PBL
tonight.
This is new, and AWS claims they don't share space with Spamhaus, so I've
been tasked with trying to contact Spamhaus about this.
Please contact me directly by any means shown below.
--
*todd herr*
Trying to solve a delivery issue, so would like to engage their postmaster
and/or anti-abuse staff.
Thanks.
--
Todd
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
If there's anyone here associated with inbound email to gmx.de and
associated properties, please contact me off-list.
Thank you.
--
Todd
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
On Thu, May 5, 2016 at 10:10 PM, Dave Warren wrote:
> Given that RFC 821 is from August of 1982, I would wholeheartedly
> recommend unplugging them until they catch up to at least 1984, or if
> that's not possible, at least disable the SMTP-breaking "feature". Even
> Microsoft published a how-to
On Thu, May 5, 2016 at 9:00 PM, Steve Atkins wrote:
> I've seen them do that when they get out of sequence. Are you doing the
> transaction above by hand (and with a real HELO and so on), or is it from
> MTA logs?
By hand, real HELO and MAIL FROM, followed by RSET or QUIT, but AIUI, RSET
or QU
Forgive me if this is off topic, but I don't know where else to turn.
I've got a customer who's having trouble sending mail to two domains with
nothing obvious (to me) in common save for one thing; both domain's primary
MXen look to be sitting behind Cisco PIX devices with Mailguard turned on.
I k
34 matches
Mail list logo
