Re: [mailop] AOL/Yahoo: Confusing enhanced SMTP codes in response?

[Todd Herr via mailop]

On Thu, Feb 1, 2024 at 1:01 PM Robert L Mathews via mailop <
mailop@mailop.org> wrote:

> I see occasional bounces from AOL/Yahoo that look like this:
>
> 554 5.7.9 Message not accepted for policy reasons. See
> https://postmaster.yahooinc.com/error-codes
>
> However, the "554 5.7.9" doesn't make sense to me.
>
> The "554" part is "Transaction failed" (RFC 5321), which is fair enough
> (although unhelpfully vague, as is "policy reasons"), but "5.7.9",
> according to RFC 4954, is:
>
> >Authentication mechanism is too weak
> >This response to the AUTH command indicates that the selected
> >authentication mechanism is weaker than server policy permits for
> >that user. The client SHOULD retry with a new authentication
> >mechanism.
>
> This is in response to an SMTP end-of-DATA command, though, not an AUTH
> command. No other company appears to send "5.7.9" as part of an enhanced
> SMTP response.
>
> Am I misreading the RFCs? What is AOL/Yahoo actually trying to indicate
> here? (And have other people started seeing more of these 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/best-practices/

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Spamfolder mini rant (Was: Contact Google Postmaster)

[Todd Herr via mailop]

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 folder, perhaps because it
>> was unfortunately remarkably similar to previous traffic that was deemed
>> spam, you won't get any complaints through an FBL, because the "This is
>> spam" button isn't available when viewing the Spam folder.
>>
>> There have been topics on this list as to what actually qualifies an FBL
> trigger.  Is it when a user flags the message as spam?  Or is it when the
> receiving server's MTA delivers the message into the recipient's spambox?
> As far as I know, there's never been a consensus on that.  Some providers
> may do it one way, other providers may do it another.
>
>
I am not familiar with any FBLs that are not complaint-driven, but I'll
allow that such things might exist, and if anyone's got pointers to them,
please share. All the ones I'm aware of are ones that basically follow the
gameplan laid out in RFC 6449.

There are mailbox providers out there that provide insight into what
percentage of mail from a given source was classified as spam, such as
Microsoft's SNDS program and Google's Postmaster Tools, but I've never
understood those to be feedback loops, per se, as they didn't and don't
tell you which specific messages were judged to be spam by a recipient or
other entity.


-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Spamfolder mini rant (Was: Contact Google Postmaster)

[Todd Herr via mailop]

On Mon, Jan 29, 2024 at 10:51 AM Scott Mutter via mailop 
wrote:

> > It would also give feedback to spammers allowing them to fine-tune their
> > messages to avoid getting flagged.
>
> What about feedback loops?  Don't those also fall into the category of
> aiding the spammer?  But they are also a tool for legitimate mail server
> administrators to combat spam on their network.
>

FBLs only aid the spammer if a spammer is allowed to enroll in the FBL.


> I like feedback loops.  The information I get back from these are
> immensely helpful.  The only bone I have to pick is that too-big-to-fail
> email service providers still tend to block our servers after we have
> received ZERO messages back from the feedback loop.  Hard for us to know
> that their users are signaling that messages from our servers are spam if
> we don't get any feedback.
>

Users can only click "This is spam" on messages that end up in their inbox.
If all of your traffic went to the spam folder, perhaps because it was
unfortunately remarkably similar to previous traffic that was deemed spam,
you won't get any complaints through an FBL, because the "This is spam"
button isn't available when viewing the Spam folder.


> My approach to feedback loops is that if I receive a message from a
> provider's feedback loop, then that recipient email address is immediately
> blocked from receiving any mail from our server.  This may be harsh, but it
> is what it is.  Whether the recipient explicitly tagged the message as spam
> that triggered the FBL or if the recipient's mail server algorithm
> determined the message was spam and triggered the FBL - I really don't
> care.  If the recipient wants to dispute this, then they need to either
> explain why they tagged the message as spam or they need to get an
> explanation from their mail server's algorithm developer as to why the
> message was determined to be spam - it's pretty simple to me.
>

Your approach to FBL complaints is sound, in my opinion. Back when I was
doing anti-spam at RoadRunner, it's precisely what I told FBL enrollees to
do with complaints - Unsubscribe the complainer.


> I do agree that a lot of the messages I get back from the feedback loops -
> they're not obvious spam.  I don't know if the recipient signed up to
> receive mail from a user on our server and then decided they no longer
> wanted to receive the message so they flagged it as spam.  Or if the
> algorithm just decided that after 5 years of receiving similar message THIS
> particular message is spam.  Either way, I don't care, that recipient gets
> blocked from receiving any mail from our server.  I don't have the time or
> the fortitude to coddle every recipient and every sender with "are you sure
> you meant to tag this message as spam?" - they're never going to respond to
> such messages, I block them and if that pisses them off... well it pisses
> me off every time I have to deal with an overzealous too-big-to-fail email
> service provider blocking our servers for no apparent reason.
>
> As far as I know, Google does 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 * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Todd Herr via mailop]

On Fri, Jan 12, 2024 at 12:30 PM Randolf Richardson, Postmaster via mailop <
mailop@mailop.org> wrote:

> As an aside, I find it interesting that the BIMI Group doesn't
> have
> a Verified Mark (no PEM specified in the "a=" parameter):
>
> https://bimigroup.org/bimi-generator/
>
> Just type "bimigroup.org" in that form and see the results, which
> show their logo followed by this notice:
>
> "Note: While your BIMI record is compliant, it doesn't
> include a
> Verified Mark Certificate that may be required by some mailbox
> providers."
>
> With all the money that the two CAs the BIMI Group promotes could
> earn, I'm surprised that neither of them has donated a free
> certificate.
>
> I don't know that bimigroup.org is used as the From domain in any emails
sent on behalf of the working group, so this isn't a terribly big deal.

Of course, I feel compelled to point out that I'm doing the same
> thing right now as the BIMI Group is doing (no PEM defined in the
> "a=" parameter), and 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 support the display of logos that are
self-asserted.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Todd Herr via mailop]

On Fri, Jan 12, 2024 at 1:03 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> > By publishing the BIMI spec. No one's required to follow the spec, but if
> > they don't, then they're not doing BIMI, and that's not the fault of the
> > spec.
>
> Does the BIMI spec *require* that *only* BIMI-authenticated messages can
> have logos displayed alongside them in the MUA?
>

There is no such thing as "BIMI-authenticated". BIMI isn't authentication,
and doesn't claim to be. I quote from the Abstract of
https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification

BIMI permits Domain Owners to coordinate with Mail User Agents (MUAs) to
display brand-specific Indicators next to properly authenticated messages.
There are two aspects of BIMI coordination: a scalable mechanism for Domain
Owners to publish their desired Indicators, and a mechanism for Mail
Transfer Agents (MTAs) to verify the authenticity of the Indicator.


The "scalable mechanism" is the DNS, and the "mechanism for MTAs to verify
the authenticity" is the Evidence Document, a.k.a., the VMC.

The current BIMI spec requires that:

   - A message pass DMARC authentication
   - The RFC5322.From domain's DMARC policy be either p=quarantine or
   p=reject
   - The Organizational Domain (as defined by DMARC) for the RFC5322.From
   domain (if different) also have a DMARC policy of p=quarantine or p=reject,
   and further the Organizational Domain must not have sp=none in its DMARC
   record.
   - There is a BIMI record published in DNS that is associated with the
   RFC5322.From domain, usually at default._bimi.fromDomain or
   default._bimi.organizationalDomain, although alternative selector names are
   supported.

Mailbox providers who participate in BIMI can and likely will add other
criteria to their decision as to whether or not to actually have their
clients display a BIMI logo.


> In my understanding no. If it actually states so, then it's far too
> restrictive and unacceptable (and this *is* fault of the spec). That's what
> im talking about all the time.
>
>
BIMI is not the end-all and be-all of display of logos or avatars at some
place in an MUA; it is one specification for having such logos appear,
either in the folder list, next to the message after it's opened, or both.

So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus*
> something else. They are not contrary to the BIMI spec. They are just in
> addition doing something that is completely orthogonal to BIMI, but gives
> similar visual experience to the user.
>
> Which actually defeats the purpose of BIMI, as I understand it.
>

I do not know of any independent MUAs (i.e., those that are not client
applications of mailbox providers) that currently support BIMI. I suspect
that it might 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:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Lions in Africa (was Re: If one signature is good, 72 signatures must be better)

[Todd Herr via mailop]

On Thu, Nov 16, 2023 at 4:53 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

>
> This reminds of the joke how a computer programmer would hunt a lion in
> Africa:
> 1. Go to the northernmost place
> 2. Traverse the continent alternately east and west working southwards
> 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 step 5.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and subdomains

[Todd Herr via mailop]

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.
> >
> > It doesn't rely on the "_domainkey" 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.
>
> Well, in reality it doesn't use PSL.
>
> [snip]
>
> So at least one (and important one, given the size of this mail service)
> implementation of DMARC does not use the PSL.
>

Those are two different statements, though.

The current DMARC protocol (
https://datatracker.ietf.org/doc/html/rfc7489#section-3.2) specifies
acquiring a public suffix list as the first step in determining an
organizational domain.

Your example demonstrates an implementation of DMARC that may not be
following the published protocol, but that's different from saying DMARC
doesn't use the PSL.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and subdomains

[Todd Herr via mailop]

On Fri, Jun 16, 2023 at 9:21 AM Andy Smith via mailop 
wrote:

> Hi,
>
> Let's say I have domain example.com with SPF, DKIM and DMARC
> records. I've put an A record in there to point foo.bar.example.com
> at someone else's IP address.
>
> Probably some cron job or other automated task on that host has sent
> an email from usern...@foo.bar.example.com that has ended up at
> gmail. gmail have sent me an aggregated DMARC report that includes
> SPF and DMARC failures for that mail.
>
> I did not expect that such email from foo.bar.example.com would
> consult the DMARC record for the parent example.com. Is this
> expected?
>
> Does DMARC use the Public Prefix List or something to determine that
> foo.bar.example.com is under the same administrative control as
> example.com, and in the absence of _domainkey.foo.bar.example.com
> will look for _domainkey.example.com? Amnd perhaps even
> _domainkey.bar.example.com?
>
>
Yes, the DMARC protocol does describe the search for the organizational
domain for the RFC5322.From domain in an email message.

It doesn't rely on the "_domainkey" 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:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] verifier.port25.com

[Todd Herr via mailop]

As a postscript to this, I was formerly employed by SparkPost and so still
have some contacts with people associated with Port25.

When this thread kicked off yesterday, I noticed that the DNS for
verifier.port25.com was a bit wonky; specifically, the MX record for that
name resolved to "verifier."

I reached out to my contacts, and they corrected the DNS.

I don't know if that fixed the issue that led to the creation of this
thread, but verifier.port25.com might not be down after all.


On Tue, May 23, 2023 at 6:31 PM Andreas Schamanek via mailop <
mailop@mailop.org> wrote:

>
> On Tue, 23 May 2023, at 16:10, Jim Popovitch via mailop wrote:
>
> > Lots of good responses for alternatives to verifier.port25.com, but
> > do any of them support aliased feedback address whereby you could
> > send an email to check-auth-lhs=domain@verifier.port25.com and
> > the response would be returned to the aliased address not the sender?
>
> I feel like it took me much longer than it should to realize why I
> would want such a feature. Now that I got it, thank 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 email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Todd Herr via mailop]

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 waiting till after DATA
> > to check for a DMARC policy, and that's in the case of the following
> > SPF record:
> >
> >> "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."
>
> domains with this spf would possible know that spf is more weak then
> then rfc 7505 (nullMX) ?
>
>
I can't speak to the frequency with which MX records are not just checked
(so as to ascertain a domain's existence) but also parsed on inbound mail,
but the null MX and bare -all SPF record both have their place for parked
domains -
https://www.m3aawg.org/M3AAWG-Protecting-Parked-Domains-BCP-update-2022-06

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Todd Herr via mailop]

On Tue, May 23, 2023 at 2:24 PM Alex Liu via mailop 
wrote:

> Indeed, an email will only be rejected if it has DMARC setup as reject.
>

There should be one exception to the rule of waiting till after DATA to
check for a DMARC policy, and that's in the case of the following SPF
record:

"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.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Feedback Loops and Sub-Domains

[Todd Herr via mailop]

On Fri, Feb 10, 2023 at 12:02 AM Grant Taylor via mailop 
wrote:

> On 2/9/23 2:21 AM, Gellner, Oliver via mailop wrote:
> > In my experience the spam report button is not only used as a sort
> > of fast unsubscribe, but also as a replacement for the delete button.
>
> Knowing how unreliable training the end user is, I wonder if it's worth
> altering the equation wherein we (as the email industry) train email
> client programs to conditionally react differently when the
> make-this-message-go-away button is pressed.  Wherein if the message is
> obviously ham, delete the message or if the message is obviously spam,
> report the message, or optionally ask what to do if it's not obvious and
> default to delete the message.
>
>
This is rather a bit of a challenge, due to the fact that the "This Is
Spam" button is typically 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 and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Todd Herr via mailop]

This looks like a message that maybe might've been sent to a reflectiv.net
address (perhaps the one advertised on your website? contact at
reflectiv.net?) and then automatically forwarded by Mailgun (which hosts
inbound mail for reflectiv.net) to a Google account (since Mailgun probably
doesn't do mailbox hosting).

That's just purely a guess, based on


   1. X-Mailgun-Incoming: Yes


appearing in the headers, and the MX record for reflectiv.net, and the
message coming to Google with the following Return-Path:

   1. Return-Path: 


Does that sound plausible?

On Wed, Jan 11, 2023 at 4:07 PM Cyril - ImprovMX via mailop <
mailop@mailop.org> wrote:

> Hi everyone!
>
> Today, I received a spam ("I got full access to your computer and
> installed a trojan" kind of email). In general, I completely ignore these,
> but today was different:
>
> The sender and recipient were my own email! What's odd is that I did
> configure SPF (granted, with a "~") but also a DMARC reject policy.
>
> Looking at the email headers and also the output from GMail, both SPF and
> DKIM were successful ("pass"), which means the sender, somehow, was able to
> send an email using my account.
>
> I would love your input on the issue, but here are my thoughts so far:
>
> 1. My account was compromised, and the password was leaked, allowing that
> user to send an email with my account. This would make sense, but the
> sending account was only used to be configured within GMail. As soon as the
> password was generated, I pasted it on GMail and never saved it elsewhere.
> 2. Theoretically, if I were to create an account on Mailgun, I would be
> able to send an email from my account and have a valid SPF for any other
> services that use Mailgun too (since their SPF would include Mailgun's
> IPs), but it wouldn't explain the valid DKIM though. For this, Mailgun
> should only allow my account to be able to send using my domain.
> 3. Did Mailgun have any database leak that I wasn't aware of?
>
> Of course, as soon as I saw this email, I generated a new password for my
> account, but I still wonder how this could have happened. I would
> appreciate if you had any insights I've missed that would make sense.
>
> Here are the headers from 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, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Todd Herr via mailop]

On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop <
mailop@mailop.org> wrote:

> Greetings,
>
> The Sender Policy Framework (SPF) is an easy way to check whether the
> sender is authorized to send emails – however, it may cause some security
> holes if it causes too many DNS lookups.
>
> Together with researchers from Virginia Tech and Max-Planck-Institut für
> Informatik, we would like to understand which challenges operators face
> when configuring the proper limit of DNS queries for SPF lookups and when
> deploying other email security protocols.
>
>
>
I'm not quite sure I understand the premise behind the survey, and since I
don't manage email for any domain, I can't realistically take part in the
survey to learn the premise, so I'll try here.

The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and
*should* be baked into any code library used by an operator that is doing
SPF validation on inbound mail, so I don't see them facing challenges here.

On the other hand, staying under the limit of ten for domains publishing
SPF records can be quite a challenge for complex organizations 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?

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for forwarding email to Gmail (revisited)

[Todd Herr via mailop]

On Fri, Jun 24, 2022 at 11:18 AM Petar Bogdanovic via mailop <
mailop@mailop.org> wrote:

> Hello,
>
> After a discussion on mailop back in 2015, I made the following note in
> some to-gmail-forwarder configuration:
>
> When forwarding to non-local addresses, don't automatically rewrite
> the envelope sender.  This used to be best practice but some domains
> explicitly recommend against it:
> https://support.google.com/mail/answer/175365?hl=en
>
>
Their recommendation seems to be so that the rewritten domain doesn't
inherit a bad reputation due to automatically forwarding spam.

If the forwarder first filters out the spam, then rewriting should be
fairly safe to do.

I've always wondered, how SPF will break this one day but it *did* work
> for almost 7 years so I moved on.
>
> Today I'm back to rewriting the envelope sender since Google now seems
> to handle SPF differently:
>
> 550-5.7.26 This message fails to pass SPF checks for an SPF record
> with a hard
> 550-5.7.26 fail policy (-all). To best protect our users from spam and
> 550-5.7.26 phishing, the message has been blocked. Please visit
> 550-5.7.26
> https://support.google.com/mail/answer/81126#authentication for more
> 550 5.7.26 information.
> fo10-20020ad45f0a00b004705f52a106si4521443qvb.420 - gsmtp
>
> If this is here to stay, maybe the article above should be updated..
>

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

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Our experience on Gmail blacklisting our IPs range

[Todd Herr via mailop]

On Tue, Apr 5, 2022 at 6:35 AM Cyril - ImprovMX via mailop <
mailop@mailop.org> wrote:

>
> After a discussion with OVH about this potential issue, I discovered that
> the problem was worst than that. By comparing all the emails from
> Spamcop.net reports, I discovered that they were from a few emails, but
> then, they had new headers added on top. This included a new "To",
> "Subject" and "Date" header. An email sent 4 days ago was sent again, with
> an updated date. The initial "Subject" was basic things like "hello" and
> the new Subject added at the top was more spammy (the typical horny stuff).
>
> Clearly, someone used the reputation of ImprovMX.com to deliver emails by
> forging them before delivery.
>
>
What you're describing sounds exactly like a DKIM replay attack.

Socketlabs, 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...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How did this get routed to me?

[Todd Herr via mailop]

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 on the message.
-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] GoDaddy Here?

[Todd Herr via mailop]

Hi.

Archives seem to indicate that GoDaddy's not represented here, but figured
I'd ask again in case that had changed.

If they are here, or if anyone has a contact there, please reach out to me;
I'm looking for clues on how best to deal with throttling issues on mail
inbound to 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF soft fail vs. hard fail

[Todd Herr via mailop]

"How common is it to have receiver systems set so that SPF hard fail will
reject messages even if they otherwise pass DKIM and DMARC, but to accept
them on the DKIM pass if the domain uses SPF soft fail?"

SPF checking is/can be done at the MAIL FROM part of the conversation; it's
keyed to the RFC5321.From domain. DMARC checking can't happen till after
DATA, since it's keyed to the RFC5322.From domain.

This means that SPF checking and a failure result can happen before DMARC
ever enters the picture.

I don't know how common it is for mailbox providers to honor SPF -all, but
any that do would be doing so correctly in this scenario.

On Thu, Dec 6, 2018 at 8:57 PM Autumn Tyr-Salvia 
wrote:

> Hello Mail Operators,
>
> My job is to help large organizations figure out their email
> infrastructure and authenticate everything legitimate with the goal of
> going to DMARC p=reject. A customer recently reported an issue to me about
> receiver behavior that I hadn't heard before, so I wanted to reach out to
> get a feel for whether this is more widespread than I realized or if this
> particular receiver is behaving strangely.
>
> It's a bit of a long story why things are set up in the way they are for
> this particular situation, and in the interests of not writing a novel
> here, I'm going to cut to the chase:
>
> Customer is sending messages that pass DKIM with first party signing, so
> they pass DMARC. Unfortunately, SPF fails, and the SPF record uses a -all,
> so it's a hard fail. There is an SPF entry at the sending subdomain, and
> the SMTP MAIL FROM domain is aligned, but the SPF record does not include
> the sending IPs. There are complicated reasons why they can't just do that
> easily.
>
> DMARC requires only one aligned method of authentication to pass, either
> SPF or DKIM. Since these messages pass with aligned DKIM, they pass DMARC.
> In theory, all should be good, right?
>
> We have received reports that a particular organization they are sending
> to is seeing the SPF hard fail and choosing not to further evaluate DKIM,
> and is rejecting these messages on SPF hard fail alone. I don't have the
> bounce message handy, but it said something like "SPF hard fail: your
> organization's security policy does not permit this message." The
> organization they're sending to is a small nonprofit, but the MX record
> shows that they are using GoDaddy's hosted email.
>
> When one of the email admins involved had the recipient ask their email
> vendor about it, they were explicitly told that if senders use an SPF -all,
> if messages fail SPF, they will not accept them even if they pass DKIM and
> DMARC. As a consequence, I had them try setting the domain to use a soft
> fail ~all and test, and initial reports say that delivery was successful.
>
> I have a lot of experience with SPF, though admittedly, I don't have as
> much experience with SPF failures (I see a lot of cases of no SPF, or
> passing but not aligned SPF, but comparatively few actual failures), but I
> haven't heard this distinction between hard and soft fail modes before.
>
> How common is it to have receiver systems set so that SPF hard fail will
> reject messages even if they otherwise pass DKIM and DMARC, but to accept
> them on the DKIM pass if the domain uses SPF soft fail?
>
> Given this situation, the customer is now considering whether 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
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 

*todd herr*

*postmaster 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
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques

[Todd Herr via mailop]

Thanks, Gentlemen.

To be clear here, I've seen nothing from Signal Amarques to indicate that
they're claiming a relationship with Signal Spam; it's only been my client
that's conflated the two.

I have enough information here to go forward, and I appreciate your quick
responses.

On Tue, Nov 27, 2018 at 4:12 AM Benjamin BILLON  wrote:

> Hi again,
>
>
>
> So they're definitely unrelated, but Signal Arnarques appears to have a
> community of people behind it. They do name, notify hosting
> providers, etc.
>
>
>
> Unfortunately sounds-alike, but not purposely malicious.
>
>
>
> Thomas Fontvielle, from Signal Spam, could contact your client to clarify
> this if you think it's relevant.
>
>
>
> Cheers,
>
> --
> *Benjamin*
>
>
>
> *From:* mailop  *On Behalf Of *Mathieu Bourdin
> *Sent:* mardi 27 novembre 2018 09:47
> *To:* mailop 
> *Subject:* Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques
>
>
>
> Hi Todd,
>
>
>
> Benjamin beat me to it (must still be on a different timezone) but I can
> also confirm that the two organization have no relation, I’ve been on the
> signal spam board for some time now and that’s actually the first time I’ve
> heard about this signal-arnaque thing. The issue you describe is
> unfortunately one we sometime get with other similar websites like WoT who
> do not actually check for the real source in case of spoofing or, in case
> of legitimate complaints, let people categorize bad behavior in their own
> biased way.
>
>
>
> Mathieu Bourdin.
>
> NP6.
>
>
>
>
>
> *De :* mailop  *De la part de* Benjamin BILLON
> *Envoyé :* mardi 27 novembre 2018 07:32
> *À :* mailop 
> *Objet :* Re: [mailop] Sanity Check - Signal Spam and Signal Arnaques
>
>
>
> Hi Todd,
>
>
>
> Thanks for the notice. That's definitely not Signal Spam, although it
> doesn't look totally malicious.
>
>
>
> 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*
>
>
>
> *From:* mailop  *On Behalf Of *Todd Herr via
> mailop
> *Sent:* mardi 27 novembre 2018 03:31
> *To:* mailop@mailop.org
> *Subject:* [mailop] Sanity Check - Signal Spam and Signal Arnaques
>
>
>
> Hi.
>
>
>
> I believe from past posts that there are Signal Spam reps on this list,
> and I just want to sanity check something with them.
>
>
>
> We have a customer seeing their good name sullied on the website
> signal-arnaques.com, where they're being implicated as sending fraudulent
> messages. They're not actually sending fraudulent messages, and they have a
> DMARC p=reject policy in place that should cause these messages to never
> see a mailbox, but there's at least one ISP out there that doesn't honor
> DMARC, and so mailbox holders at that ISP are getting messages "From" my
> customer and posting them to signal-arnaques.com as "Scam Website
> Announcement".
>
>
>
> My customer is frantic, and keeps referring to signal-arnaques.com as
> "Signal Spam", but I don't get the sense that the two are related in any
> sense of the word; different domains, different physical 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>*
> *twitter* @toddherr @sparkpost
>
> *tel* 415-578-5222 x477
> *mobile* 703-220-4153
> *email* todd.h...@sparkpost.com 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 

*todd herr*

*postmaster 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
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Sanity Check - Signal Spam and Signal Arnaques

[Todd Herr via mailop]

Hi.

I believe from past posts that there are Signal Spam reps on this list, and
I just want to sanity check something with them.

We have a customer seeing their good name sullied on the website
signal-arnaques.com, where they're being implicated as sending fraudulent
messages. They're not actually sending fraudulent messages, and they have a
DMARC p=reject policy in place that should cause these messages to never
see a mailbox, but there's at least one ISP out there that doesn't honor
DMARC, and so mailbox holders at that ISP are getting messages "From" my
customer and posting them to signal-arnaques.com as "Scam Website
Announcement".

My customer is frantic, and keeps referring to signal-arnaques.com as
"Signal Spam", but I don't get the sense that the two are related in any
sense of the word; different domains, different physical 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>*
*twitter* @toddherr @sparkpost

*tel* 415-578-5222 x477
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DMARC p=quarantine pct=0

[Todd Herr via mailop]

We saw no negative side effects when we did it here for our domains, and we
did it for precisely the reason you're planning to do it, to trigger Google
Groups.

On Thu, Apr 5, 2018 at 7:00 PM, Jesse Thompson <jesse.thomp...@wisc.edu>
wrote:

> Does anyone know of any negative side effects of setting a DMARC policy:
> p=quarantine pct=0 ?
>
> Is it equivalent to: p=none ?
>
> I'm curious because I want to trigger Google Groups (and maybe others list
> forwarders?) to rewrite the From in a DMARC compliant fashion *prior* to
> changing the domain's DMARC policy... to avoid the "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
>



-- 

*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 <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Anyone Here From Vertical Response?

[Todd Herr via 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...@sparkpost.com <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Contact at Mxtoolbox?

[Todd Herr via mailop]

Hello.

Anyone have a contact at Mxtoolbox? We had a buggy script that sent way too
many API calls their way, and now it looks like they're blocking our source
IP.

We've fixed the script and started engaging through regular channels, but
I'm hoping to short-circuit the mitigation process.

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 <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reg. Gmail Postmaster IP issue

[Todd Herr]

No apology necessary, Matt; I was more interested in sanity checking what
we were seeing.

Thanks for the reply.

On Mon, Sep 11, 2017 at 12:40 PM, Matt Gilbert <
matthew.gilb...@mailchimp.com> wrote:

> That’s correct Todd, this hasn’t impacted our actual delivery at all that
> we 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 September 11, 2017 at 12:28:03 PM, Todd Herr (toddmh...@gmail.com)
> wrote:
>
> 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 engagement.
>
> On Mon, Sep 11, 2017 at 12:16 PM, Matt Gilbert <
> matthew.gilb...@mailchimp.com> wrote:
>
>> This issue looks to be impacting 100% of our IPs as well. We’re seeing
>> 100% bad reputation since 9/9 on all of our DKIM domains. Any updates about
>> this will be appreciated.
>>
>> Thanks,
>> Matt Gilbert
>> - Deliverability Engineer, MailChimp
>> - delivery.mailchimp.com
>>
>> On September 11, 2017 at 5:00:07 AM, ewald kessler | webpower (
>> ewald.kess...@webpower.nl) wrote:
>>
>> Clearly this is an issue on the Google side. Where all IP's have a bad
>> reputation for September 9, there is no domain reputation data for that
>> date at all.
>>
>> --
>> Deliverability & Abuse Management, www.webpower-group.com
>> ewald.kess...@webpower.nl
>> t: +31 342 423 262 <+31%20342%20423%20262>
>>
>>
>> On 11 September 2017 at 10:24, Stefano Bagnara <mai...@bago.org> wrote:
>>
>>> Hi Vaibhav,
>>>
>>> I see the same for 2 DKIM domains (each one with a dozen IP.. all red).
>>> A third domain doesn't have data for 9 sept yet.
>>>
>>> All of them have always been green before.
>>>
>>> I guess it is a Google issue (or they drastically changed their
>>> "ideas" about what is green or red).
>>>
>>> Stefano
>>>
>>> --
>>> Stefano Bagnara
>>> Apache James/jDKIM/jSPF
>>> VOXmail/Mosaico.io/VoidLabs
>>>
>>>
>>> On 11 September 2017 at 09:39, Vaibhav <v.kulawade...@gmail.com> wrote:
>>> > Hey,
>>> >
>>> > I have observed that Gmail Postmaster showing all IP in BAD state for
>>> 9th
>>> > Sept report. Does anyone observed the same ?
>>> >
>>> > Seems like issue from Gmail Postmaster end.
>>> >
>>> > --Vaibhav
>>>
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
>
> --
> Todd
> 703.220.4153 <(703)%20220-4153>
>
>


-- 
Todd
703.220.4153
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reg. Gmail Postmaster IP issue

[Todd Herr]

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 engagement.

On Mon, Sep 11, 2017 at 12:16 PM, Matt Gilbert <
matthew.gilb...@mailchimp.com> wrote:

> This issue looks to be impacting 100% of our IPs as well. We’re seeing
> 100% bad reputation since 9/9 on all of our DKIM domains. Any updates about
> this will be appreciated.
>
> Thanks,
> Matt Gilbert
> - Deliverability Engineer, MailChimp
> - delivery.mailchimp.com
>
> On September 11, 2017 at 5:00:07 AM, ewald kessler | webpower (
> ewald.kess...@webpower.nl) wrote:
>
> Clearly this is an issue on the Google side. Where all IP's have a bad
> reputation for September 9, there is no domain reputation data for that
> date at all.
>
> --
> Deliverability & Abuse Management, www.webpower-group.com
> ewald.kess...@webpower.nl
> t: +31 342 423 262 <+31%20342%20423%20262>
>
>
> On 11 September 2017 at 10:24, Stefano Bagnara  wrote:
>
>> Hi Vaibhav,
>>
>> I see the same for 2 DKIM domains (each one with a dozen IP.. all red).
>> A third domain doesn't have data for 9 sept yet.
>>
>> All of them have always been green before.
>>
>> I guess it is a Google issue (or they drastically changed their
>> "ideas" about what is green or red).
>>
>> Stefano
>>
>> --
>> Stefano Bagnara
>> Apache James/jDKIM/jSPF
>> VOXmail/Mosaico.io/VoidLabs
>>
>>
>> On 11 September 2017 at 09:39, Vaibhav  wrote:
>> > Hey,
>> >
>> > I have observed that Gmail Postmaster showing all IP in BAD state for
>> 9th
>> > Sept report. Does anyone observed the same ?
>> >
>> > Seems like issue from Gmail Postmaster end.
>> >
>> > --Vaibhav
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>


-- 
Todd
703.220.4153
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Seeking Clarity on Office 365 Error Message

[Todd Herr]

On Tue, Jun 13, 2017 at 5:48 PM, Michael Wise <michael.w...@microsoft.com>
wrote:

> Need a bit more detail. Was there an AS(###) after it?
>

​Hi Michael, and thanks for replying.

No, there's no AS(###) after it, at least nothing in our logs like that.

Just "550 5.4.1 [xxx@yyy.z]: Recipient address rejected: Access
denied [BY2NAM05FT028.eop-nam05.prod.protection.outlook.com]​"

It appears to be user-level filtering, since like I said we don't see
wholesale rejections for domains where our customers are sending to more
than a handful of recipients. We've had a request here 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
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Seeking Clarity on Office 365 Error Message

[Todd Herr]

Hello.

I'm wondering if there's anyone here who can point me to a definitive
answer on the meaning of the following error message, seen when sending to
an Office 365 hosted domain:

550 5.4.1 ...@... Recipient address rejected: Access denied
[DM3NAM06FT012.Eop-nam06.prod.protection.outlook.com]



​I've found this:

https://support.office.com/en-US/article/Fix-email-delivery-issues-for-error-code-5-4-1-in-Office-365-7dcf7a8b-e00e-49f8-bf8d-74aba79c5a6a

and this:

https://support.office.com/en-us/article/Email-non-delivery-reports-in-Office-365-51daa6b9-2e35-49c4-a0c9-df85bf8533c3?ui=en-US=en-US=US

But they don't seem to quite cover it, as for most of my customers, they'll
get the above error message on some, but not all, messages to a given
domain.​

My goal here is to figure out if this is a signal that a given user does
not wish to receive 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

*tel* 415-578-5222 x477
*mobile* 703-220-4153
*email* todd.h...@sparkpost.com <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Spamhaus Contact? PBL Broken?

[Todd Herr]

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*

*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 <firstname.lastn...@messagesystems.com>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Anyone Have A Contact At interhost.com?

[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

Re: [mailop] Cisco PIX Mailguard Oddity

[Todd Herr]

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 QUIT can be issued at any time, yes?


-- 
Todd
703.220.4153
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Cisco PIX Mailguard Oddity

[Todd Herr]

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 know this because of the greeting I get from both:

220 ***

Now, everything I can find about these devices says that they only allow
seven SMTP commands:​

​HELO, ​
MAIL
​, ​
RCPT
​, ​
DATA
​, ​
RSET
​, ​
NOOP
​, ​
QUIT
​


And they're supposed to respond with OK to everything else. These two
domains, again not obviously related, mail servers in different /8s, don't
even do that, though; both of them are responding in
​ unsuspected ways even to commands from the above list, to wit:

RSET
500 Syntax error, command unrecognized
QUIT
500 Syntax error, command unrecognized
​

​I've never wrangled one of these beasts (haven't even *seen* evidence of
one in many years) so I'd like to ask you fine folks if you've ever seen
anything like this​ from one of these, and what it means for their
configuration? I mean, is this a common bug/misconfiguration, or have I
just hit the lottery?

Thanks.

-- 
Todd
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop