Re: [mailop] Mailop cert - was Re: Admin: Gmail users of mailop suspended due to bounces.

[Phil Pennock via mailop]

On 2019-04-29 at 19:51 +0100, Andrew C Aitchison via mailop wrote:
> I'm trying to alert the exim developers to the suggestions that people
> have made in this thread; but it would be easier to ask them to subscribe to
> mailop if the archive didn't have an expired certificate.

I'm on mailop, I just started a new job recently and fell behind on
public mailing-lists.

Every mail sent out by the mailing-list contains this added footer:
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

At this point, complaining about over-signing is just so much hot air
and underinformed smug superiority (at a level which almost just drove
me to unsubscribe from mailop because this much crap just ... isn't
worth it).

Seriously, the body has been modified, the signature will fail, no
matter what.  Game over.

Exim switched to over-signing a few releases back.  We're now tracking
if we should change the default list of signed headers as a result of
this.  But nothing in Exim's defaults would have changed a single thing
in what happened here.

Independent of DMARC/ADSP/whatever, if you're sending out email in 2019,
you need to be claiming responsibility for it.  DKIM sign.  Perhaps SPF,
perhaps not.

Google's stance on IPv6 and email might be frustrating to encounter, but
really it's the least bad approach they could have taken given that the
IPv4 constraints around reputation tracking disappear.

I've posted over in:
  
with the configuration we have on the @exim.org hub, to have Mailman and
Exim playing together to implement ARC signing and such like.  Whether
or not one specific recipient domain (or hoster) chooses to trust a
given sender for ARC is independent of whether or not it helps others,
and if you're running an MLM in 2019, it's time to try setting up ARC.

-Phil, perhaps a little on the cranky side, but seriously, this thread
   is so much bullshit.

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

[mailop] Web.com / Network Solutions Abuse Teams

[Kiersti Esparza via mailop]

Hello,
I work for Marketo and am seeing some unusual IP blocking, we are digging
in to understand what triggered the listings and wanted to see if there was
someone on this list who worked for the abuse teams at Web.com/Network
Solutions who could narrow our focus.

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

Re: [mailop] Problem sending to @vtext.com

[Brandon Applegate via mailop]

> On May 1, 2019, at 9:51 AM, Chris Adams via mailop  wrote:
> 
> I have customers that (unwisely) depend on sending email to SMS via the
> @vtext.com gateway.  Lately, the messages have been periodically backing
> up in our queues because the Cloudmark SMTP servers reject the messages.
> I get different error responses:
> 
> 452 4.1.1  requested action aborted: try again later (in 
> reply to RCPT TO command))
> 
> 421 vzw-ibgw-5001a.stratus.cloudmark.com cmsmtp Connection refused - 
> LhYMh85jEL68J - POL109G - too many sessions from 76.164.172.160
> 
> Sometimes, the servers will accept messages for a short while, then
> reject them for a while, then accept a few, etc.  I looked to see if the
> POL109G had a specific meaning, but just found references to others
> getting that error.
> 
> As far as I can tell, we don't have spam/garbage/etc. going out to the
> @vtext.com numbers that would cause this (when I look at the messages in
> the queue they all look legit).  Is there anything I can do to improve
> the delivery of these messages?

I believe I had a similar experience with vtext.com.  I’m running postfix, and 
I tweaked my config as such:
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 1ssmtp_extra_recipient_limit = 10

I think I got this from:

https://wiki.deimos.fr/Postfix:_limit_outgoing_mail_throttling 


Looks like you could do this per dest. domain as well by creating custom 
policies.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."



signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Problem sending to @vtext.com

[Steve Atkins via mailop]

> On May 1, 2019, at 2:51 PM, Chris Adams via mailop  wrote:
> 
> I have customers that (unwisely) depend on sending email to SMS via the
> @vtext.com gateway.  Lately, the messages have been periodically backing
> up in our queues because the Cloudmark SMTP servers reject the messages.
> I get different error responses:
> 
> 452 4.1.1  requested action aborted: try again later (in 
> reply to RCPT TO command))
> 
> 421 vzw-ibgw-5001a.stratus.cloudmark.com cmsmtp Connection refused - 
> LhYMh85jEL68J - POL109G - too many sessions from 76.164.172.160
> 
> Sometimes, the servers will accept messages for a short while, then
> reject them for a while, then accept a few, etc.  I looked to see if the
> POL109G had a specific meaning, but just found references to others
> getting that error.
> 
> As far as I can tell, we don't have spam/garbage/etc. going out to the
> @vtext.com numbers that would cause this (when I look at the messages in
> the queue they all look legit).  Is there anything I can do to improve
> the delivery of these messages?

AIUI, no. They're not intended for bulk SMS delivery; your customer
should cough up a little money and go with an SMS gateway.

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

[mailop] Problem sending to @vtext.com

[Chris Adams via mailop]

I have customers that (unwisely) depend on sending email to SMS via the
@vtext.com gateway.  Lately, the messages have been periodically backing
up in our queues because the Cloudmark SMTP servers reject the messages.
I get different error responses:

452 4.1.1  requested action aborted: try again later (in 
reply to RCPT TO command))

421 vzw-ibgw-5001a.stratus.cloudmark.com cmsmtp Connection refused - 
LhYMh85jEL68J - POL109G - too many sessions from 76.164.172.160

Sometimes, the servers will accept messages for a short while, then
reject them for a while, then accept a few, etc.  I looked to see if the
POL109G had a specific meaning, but just found references to others
getting that error.

As far as I can tell, we don't have spam/garbage/etc. going out to the
@vtext.com numbers that would cause this (when I look at the messages in
the queue they all look legit).  Is there anything I can do to improve
the delivery of these messages?
-- 
Chris Adams 

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