[mailop] Anyone from ATT around?

2024-03-26 Thread Michael Ellis via mailop
Block on 66.211.100.86 but no answers though the other ISPs have

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Anyone have issues with Higher Logic?

2024-02-28 Thread Michael Ellis via mailop
My client is getting his whole range blocked by Abuse RBL and the customer
that used Higher Logic blocked by Microsoft and others as well with no
relief in site even though they fixed the issue

 

Even his personal  server is affected even though he sends mostly nothing on
it and nothing other than personal stuff

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Certificate Question

2022-10-14 Thread Michael Ellis via mailop
Ak ok I see, thanks!

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of ml+mailop--- via 
mailop
Sent: October 14, 2022 12:42 PM
To: mailop@mailop.org
Cc: ml+mai...@esmtp.org
Subject: Re: [mailop] Certificate Question

"What's the problem you are trying to solve?"

Almost no MTA cares about the certificate content unless explicitly
configured to do so. Some check the names (CertSubject or AltNames),
and some are "misconfigured" to require a cert signed by some
specific CAs.

Testing with just one or two other systems won't tell you much.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Certificate Question

2022-10-14 Thread Michael Ellis via mailop
Ok this ESP guy is an excellent programmer but a bit lacking in all else.

Can anyone diagnose his issue? Its not my wheelhouse either?

Do you know about certificates for mail servers? I’m trying out the SmarterMail 
server and had some confusion about how to configure secure access. I assumed 
SmarterMail would allow a certificate per domain but they don’t. Instead they 
have certificates based on the protocol. I stuck a goolara.com certificate in 
and then Outlook desktop asked if I wanted to use the certificate when I tried 
to connect via IMAP SSL (993). I allowed it, but this isn’t something I 
experienced when using on-line mail servers, so I wonder how they handle secure 
connections without giving that certificate warning. Do you know?

Also, the sending side is confusing me some. Google is reporting that the 
connection was secure and doesn’t give that annoying warning about not being 
encrypted, but I’m sending for a domain that is different than my certificate 
so I’m not sure why that is allowed. I have configured my Symphonie software to 
use STARTTLS and encrypt the connection but I only do it if I’ve received a SSL 
cert from the customer for that domain. But is that not necessary? Can the 
connection be secure with any domain’s certificate and still be accepted by the 
ISPs?

Any help gratefully accepted

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Email Cloud Providers

2022-09-20 Thread Michael Ellis via mailop
My thanks to everyone who replied! I have offered the suggestions

 

How I mentioned I love the collegiate atmosphere here?

 

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Brandon Long via 
mailop
Sent: September 20, 2022 5:00 PM
To: Jay Hennigan
Cc: mailop
Subject: Re: [mailop] Email Cloud Providers

 

 

 

On Tue, Sep 20, 2022 at 1:42 PM Jay Hennigan via mailop  
wrote:

On 9/20/22 13:19, Brandon Long via mailop wrote:

> otoh, if that's not what they mean by "reading email", then I guess the 
> rest of the smarts that read email are still there, as this article 
> points out:
> 
> https://variety.com/2017/digital/news/google-gmail-ads-emails-1202477321/ 
> 
> 
> Is gmail really still alone in that now?  Automatically populating your 
> calendar with airline reservations and the like?

Is there an option to disable that behavior?

 

https://support.google.com/mail/answer/10079371

 

Yes, and apparently they are off by default in Europe now?  Though, from 
reading that, I'm not sure if it would have changed to off and need to be

re-enabled, or whether that's just new accounts.  Looks like it will prompt to 
enable in Europe/Japan, but automatically enabled elsewhere.

 

https://support.google.com/a/answer/10095404 so yes, it can be controlled by 
the admin as well.

 

The user's gmail settings screen, there are more specific settings to control 
various specific smart features.

 

The terms of service and privacy policies are also different between consumer 
and Workspace, which also affects how the smart stuff works.

 

Brandon 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Email Cloud Providers

2022-09-20 Thread Michael Ellis via mailop
Anyone have a suggestion for a good cloud email provider with good
deliverability and control over their customers?

 

My client asked and said:

The big three seem to be Google, Microsoft, or Amazon. I expect that Google
would be good but they are the most expensive and I have concerns about them
reading every email that goes through. I use a lot of Microsoft software but
I have mixed feelings about the company. They can make some good products,
but they also screw up regularly and are difficult to work with. Amazon is
an amazing company and I'm doing more and more business with them, even
though I worry about them becoming too dominate. Their SES email has
terrible deliverability, from what I've seen, but I don't know much about
their regular mailbox service. Do you know how their deliverability is?

 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] FW: Did Google become stricter about RFC 5322?

2022-07-15 Thread Michael Ellis via mailop
The body text lines are likely more than 998 characters. They have a feature to 
break long lines but they didn't enable it. The headers lines will all be well 
below 998 characters.

Each header is separated by \r\n

Here is an example of the date: Fri, 15 Jul 2022 12:51:19 -0500   I think this 
is correct.

-Original Message-
From: John Levine [mailto:jo...@taugh.com] 
Sent: July 15, 2022 1:16 PM
To: mailop@mailop.org
Cc: m...@bacchusbrew.com
Subject: Re: [mailop] FW: Did Google become stricter about RFC 5322?

It appears that Michael Ellis via mailop  said:
>Am I missing something as well? Google just rejected a client due to PTR on 
>mailop-boun...@mailop.org but it seems fine to me ...

> Gmail, 550-5.7.1 this message has been blocked. Please review 550 
>5.7.1
> RFC 5322 specifications for more information.

PTRs aren't RFC 5322

>As far as I can tell, the message is compliant.  It doesn't have any of 
>the obvious problems, at least.  From, To, Message-ID and Date are 
>supplied.  No duplicate headers.

How long are the text lines?

Is there \r\n at the end of each line in the header and body?

Is the Date: in the correct form?

R's,
John

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] FW: Did Google become stricter about RFC 5322?

2022-07-15 Thread Michael Ellis via mailop
Oops sorry apparently my cut and paste skills are lacking

C:\Users\philipt>nslookup -q=ptr 173.160.100.85
>
>
>
> Non-authoritative answer:
>
> 85.100.160.173.in-addr.arpa name = csc-emarketing.trimaxdirect.com
>
>
>
>
>
> C:\Users\philipt>nslookup -q=mx csc-emarketing.trimaxdirect.com
>
>
>
> Non-authoritative answer:
>
> csc-emarketing.trimaxdirect.com MX preference = 10, mail exchanger = 
> cscmail.trimaxdirect.com
>
>
>
> cscmail.trimaxdirect.cominternet address = 173.160.100.85
>
>
>
>
>
> 7/13/2022 11:12:34 AM TRIMAXSQL: Attempting to connect to address:
> gmail-smtp-in.l.google.com (173.194.197.27:25)
>
> 7/13/2022 11:12:34 AM TRIMAXSQL: Connected to address:
> gmail-smtp-in.l.google.com (173.194.197.27:25)
>
> 7/13/2022 11:12:34 AM TRIMAXSQL Mail server: 220 mx.google.com ESMTP
> y19-20020a056602165300b0067badd50ba4si5526620iow.33 - gsmtp
>
> 7/13/2022 11:12:34 AM TRIMAXSQL sent:EHLO 
> csc-emarketing.trimaxdirect.com
>
> 7/13/2022 11:12:34 AM Mail server: 250-mx.google.com at your service, 
> [173.160.100.85]
>
> 250-SIZE 157286400
>
> 250-8BITMIME
>
> 250-STARTTLS
>
> 250-ENHANCEDSTATUSCODES
>
> 250-PIPELINING
>
> 250-CHUNKING
>
> 250 SMTPUTF8
>
> 7/13/2022 11:12:34 AM TRIMAXSQL sent:MAIL 
> FROM: <mailto:bounce-0-5848365798574070...@csc-emarketing.trimaxdirect.com>
> > BODY=8BITMIME
>
> 7/13/2022 11:12:34 AM Mail server: 250 2.1.0 OK
> y19-20020a056602165300b0067badd50ba4si5526620iow.33 - gsmtp
>
> 7/13/2022 11:12:34 AM TRIMAXSQL sent:RCPT TO: <mailto:silversta...@gmail.com> >
>
> 7/13/2022 11:12:34 AM Mail server: 250 2.1.5 OK
> y19-20020a056602165300b0067badd50ba4si5526620iow.33 - gsmtp
>
> 7/13/2022 11:12:34 AM TRIMAXSQL sent:DATA
>
> 7/13/2022 11:12:34 AM Mail server: 354 Go ahead
> y19-20020a056602165300b0067badd50ba4si5526620iow.33 - gsmtp
>
> 7/13/2022 11:12:34 AM TRIMAXSQL: sending actual data
>
> 7/13/2022 11:12:35 AM Mail server: 550-5.7.25 [173.160.100.85] The IP 
> address sending this message does not have a
>
> 550-5.7.25 PTR record setup, or the corresponding forward DNS entry 
> does not
>
> 550-5.7.25 point to the sending IP. As a policy, Gmail does not accept 
> messages
>
> 550-5.7.25 from IPs with missing PTR records. Please visit
>
> 550-5.7.25 https://support.google.com/mail/answer/81126#authentication
> for more
>
> 550 5.7.25 information.
> y19-20020a056602165300b0067badd50ba4si5526620iow.33 – gsmtp

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of ml+mailop--- via 
mailop
Sent: July 15, 2022 12:07 PM
To: mailop@mailop.org
Cc: ml+mai...@esmtp.org
Subject: Re: [mailop] FW: Did Google become stricter about RFC 5322?

On Fri, Jul 15, 2022, Michael Ellis via mailop wrote:
> Am I missing something as well? Google just rejected a client due to
> PTR on mailop-boun...@mailop.org but it seems fine to me

What is "PTR on mailop-boun...@mailop.org"?

Can you post the rejection and the relevant logs?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] FW: Did Google become stricter about RFC 5322?

2022-07-15 Thread Michael Ellis via mailop
Am I missing something as well? Google just rejected a client due to PTR on 
mailop-boun...@mailop.org but it seems fine to me

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Philip Paeps via 
mailop
Sent: July 13, 2022 3:31 AM
To: mailop
Subject: [mailop] Did Google become stricter about RFC 5322?

In the past couple of days, I'm seeing an uptick in rejects from Gmail 
as follows:

<[elided]@gmail.com>: host
 gmail-smtp-in.l.google.com[2607:f8b0:4004:c17::1a] said: 550-5.7.1
 [2610:1c1:1:606c::19:2] Our system has detected that this message 
is
 550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent 
to
 Gmail, 550-5.7.1 this message has been blocked. Please review 550 
5.7.1
 RFC 5322 specifications for more information.
 bp41-20020a05620a45a900b006a64dbdb75asi7765031qkb.308 - gsmtp (in 
reply to
 end of DATA command)

As far as I can tell, the message is compliant.  It doesn't have any of 
the obvious problems, at least.  From, To, Message-ID and Date are 
supplied.  No duplicate headers.

These are text/plain messages: commit mail from an svn repository.

I like to think I have a reasonably robust understanding of RFC 5322.  
I'm sure I must be missing something very subtle.

Has anyone else seen (more of) these?

Thanks.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Anyone from Cox around?

2020-06-09 Thread Michael Ellis via mailop
Nobody from Cox around?

 

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Ellis
via mailop
Sent: Friday, May 29, 2020 12:23 PM
To: mailop@mailop.org
Subject: [mailop] Anyone from Cox around?

 

 

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


[mailop] Anyone from Cox around?

2020-06-01 Thread Michael Ellis via mailop
 

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


[mailop] Any Postmaster Path for Spectrum?

2020-04-01 Thread Michael Ellis via mailop
Looking to find solutions for a customers newsletter


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


Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Michael Ellis via mailop
>> Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
>>> At some point I give up and hit the spam button.
>>
>> And thus you are training Google's AI to treat completely legit (only
>> misdirected) messages as spam.
>> Maybe one day these senders will find out that when they send another
>> message (this time to the correct address), it will end up in the
>> recipient's spam folder, without them knowing why.
>> Don't do it to them. Just delete those messages, don't put them to spam.
>
>
> I disagree. If the sender wants eyeballs to see their emails, they need
> some incentive to put in place the systems that'll validate the correct
> recipients. Like double-opt-in. Especially before persistent and repeat
> use of an address where you don't actually know the recipient wants your
> mail.
>
>

And when someone hits this is spam on a Double Optin/COI email?

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


[mailop] Anyone know a path for Roadrunner

2019-09-05 Thread Michael Ellis via mailop
I have a client with issues and since its Spectrum there seems no clear
way to postmaster or anyone

Any ideas?

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


Re: [mailop] [ext] RE: Return Path / Sender Score

2019-08-22 Thread Michael Ellis via mailop
> On Thu, Aug 22, 2019 at 6:50 AM Ralf Hildebrandt via mailop
>  wrote:
>>
>> * Mathieu Bourdin :
>> > Hi again,
>> >
>> >
>>
>> > First, a precision: my reply is missing 2 lines wich, for short,
>> > were saying: "but usually you don't get listed on the first sending to
>> > a trap,
>>
>> Yes, because that would instantaneously blacklist all servers sending
>> double-opt-in
>> mails
>
> If you are a smart spamtrap operator, you would have code that
> recognizes a confirmation message and flags someone to look at the
> trap is volume gets unreasonable.
>
>> > it's more an accumulation of emails to different traps that
>> > get you in trouble form what I understand of how traps work".
>>
>> Hopefully.
>
> IME, if you send even a single phishing/malware email, you'll get
> blocked right quick.
>
>> > Second: yeah if the domain/address you are sending to was giving you
>> > "proof of life" (answers and so on) until very recently and is now
>> > being used as a trap that would be kinda rude (and not very useful to
>> > detect actual spammers), most trap owners I have spoken with usually
>> > say that they will bounce (hard) mails for at least 6 months straight
>> > on re-used addresses (and most say they do it for at least a year).
>
> A year is IMHO best practice.
>
> --kelly
>

Definitely best practice. I have several companies that email me once a
year for a particular event, like the WW2 re-enactment even in PA every
June.  Six months would not have fixed it and they would get ensnared in
the trap

Michael

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


Re: [mailop] Gmail Postmaster IP reputation shift on July 2nd

2019-07-05 Thread Michael Ellis via mailop
One of my clients is also seeing this for some of his custoers (ESP)


>  Seeing the same symptom, but as of 7/3.  Quick spot check so far isn't
> showing performance problems... hopefully an isolated reporting issue.
> Allen K
>
>
> On Friday, July 5, 2019, 07:58:53 AM CDT, Tracey Crawford via mailop
>  wrote:
>
>  I am also seeing a drop from green to red for some of my customers on
> July 2nd.
> Tracey CrawfordLead Deliverability Analyst, SparkPost
>
> On Fri, Jul 5, 2019 at 7:02 AM  wrote:
>
> Send mailop mailing list submissions to
>         mailop@mailop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> or, via email, send a message with subject or body 'help' to
>         mailop-requ...@mailop.org
>
> You can reach the person managing the list at
>         mailop-ow...@mailop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mailop digest..."
>
>
> Today's Topics:
>
>    1. Re: Can't sign up for MSFT SNDS? (Hetzner Blacklist)
>    2. Gmail Postmaster IP reputation shift on July 2nd (Mathieu Bourdin)
>    3. Re: Gmail Postmaster IP reputation shift on July 2nd
>       (Richelo Killian)
>
>
> --
>
> Message: 1
> Date: Thu, 4 Jul 2019 14:25:03 +0200
> From: Hetzner Blacklist 
> To: mailop@mailop.org
> Subject: Re: [mailop] Can't sign up for MSFT SNDS?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> Hi Al,
>
> I just tried adding a /16 that we bought a while ago but aren't using
> yet. There were no issues adding it to the SNDS.
>
> Having said that, I've often had issues in the past adding ranges. Most
> of the time simply waiting and trying again a few hours or days later
> worked.
>
> Make sure the WHOIS data is correct, since Microsoft relies heavily on
> that.
>
> Also, if you're able to, maybe you can signup using the AS number, I've
> never had issues with that.
>
> Kind regards
>
> Bastiaan van den Berg
>
>
> Am 04.07.2019 um 13:00 schrieb Al Iverson :
>> Anybody else having trouble signing new ranges up for Microsoft SNDS?
>> When submitting the access request, I get a generic "We're sorry! An
>> error has occurred.
>
>
>
> --
>
> Message: 2
> Date: Fri, 5 Jul 2019 08:12:17 +
> From: Mathieu Bourdin 
> To: "mailop@mailop.org" 
> Subject: [mailop] Gmail Postmaster IP reputation shift on July 2nd
> Message-ID:
>        
> 
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> We just saw that Gmail Postmaster's Tools shows a very unusual amount of
> our IP's as < bad > in the graphs.
> Domain reputation seems unaffected, but basically we see around 50% of our
> IPs for July 2nd and 75% for July 3 going from green to red.
> I saw no changes in sending habits from the various customers I checked
> (as they all have dedicated IPs it's fairly straightforward).
>
> Some other French ESP representatives I chatted with see similar cases,
> I  wanted to check with others if they saw the same things and, if luck
> will have it a Gmail Postmaster team member happens to be online and they
> have some time to look it up, that would be much appreciated.
>
> Thanks,
>
> Mathieu Bourdin
> Dolist Deliverability team.
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 
>
> --
>
> Message: 3
> Date: Fri, 5 Jul 2019 01:53:25 -0700
> From: Richelo Killian 
> To: "mailop@mailop.org" 
> Subject: Re: [mailop] Gmail Postmaster IP reputation shift on July 2nd
> Message-ID:
>        
> 
> Content-Type: text/plain; charset="utf-8"
>
> I actually had several go from medium to high. No down movement at all for
> the IP’s I monitor.
>
> Kind Regards,
>
> Richelo Killian
>
> From: Mathieu Bourdin via mailop  
> Reply: Mathieu Bourdin  
> Date: July 5, 2019 at 10:15:42
> To: mailop@mailop.org  
> Subject:  [mailop] Gmail Postmaster IP reputation shift on July 2nd
>
> Hello,
>
> We just saw that Gmail Postmaster’s Tools shows a very unusual amount of
> our IP’s as « bad » in the graphs.
> Domain reputation seems unaffected, but basically we see around 50% of our
> IPs for July 2nd and 75% for July 3 going from green to red.
> I saw no changes in sending habits from the various customers I checked
> (as
> they all have dedicated IPs it’s fairly straightforward).
>
> Some other French ESP representatives I chatted with see similar cases, I
> wanted to check with others if they saw the same things and, if luck will
> have it a Gmail Postmaster team member happens to be online and they have
> some time to look it up, that would be much appreciated.
>
> Thanks,
>
> Mathieu Bourdin
> Dolist Deliverability team.
>
> ___