Re: [mailop] Hotmail complains about their own mail

[Richard via mailop]

> 
> It's a catchall forwarded domain "@olddomain -> @newdomain", so
> Postfix accepted it before checking the final recipient.
> 
> Now that you said it, I'm going to suggest to the user to just
> alias individual addresses instead of the catchall.
> 
> I still think Microsoft should not complain about NDRs, especially
> if the original was from them.

Your approach is generating backscatter spam (to hotmail, where the
mail may not even have originated - the "From:" address is likely
forged so your assumption that it originated from hotmail could well
be wrong), which (being polite) is not considered a good thing. You
need to reject the mail on the originating connection, rather than
bouncing after acceptance. [you could consider tossing
non-deliverable messages rather than bouncing them, but you could end
up junking "legit" non-deliverables.] 

Backscatter spam *will* get you on blocklists.


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

Re: [mailop] Debian lists contact?

[Richard via mailop]

> Date: Tuesday, September 05, 2023 18:00:17 -0500
> From: Ken Johnson via mailop 
>
> Writing from $dayjob:
> 
> Is there a contact for the debian.org mailing lists listening?
> 
> 

You'll find list maintainer contact information in the "list
maintenance" section of:

   


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

Re: [mailop] verizon email-to-text gateway mail deferred evening and night

[Osborne, Richard via mailop]

We have been seeing this also for about the last week.  Our Verizon reps are 
telling us we need to pay for their EMAG (Enterprise Messaging) service to not 
get blocked.


Richard Osborne
Information Systems
West Tennessee Healthcare

NOTICE:  (1) The foregoing is not intended to be a legally binding or legally 
effective electronic signature. (2) This message may contain legally privileged 
or confidential information.  If you are not the intended recipient of this 
message, please so notify me, disregard the foregoing message, and delete the 
message immediately.  I apologize for any inconvenience this may have caused.


From: mailop  On Behalf Of Dima Gomonyk via mailop
Sent: Friday, January 6, 2023 6:28 AM
To: z...@stat.colostate.edu; mailop@mailop.org
Subject: Re: [mailop] verizon email-to-text gateway mail deferred evening and 
night

Attention: This email originated from outside of West Tennessee Healthcare. 
Always validate the sender's email address before clicking on links or 
attachments as they may not be safe. Never provide your username or password to 
a site you do not trust. Please forward suspicious e-mails to 
phish...@wth.org.

I've been looking into this exact thing yesterday: Verizon's mail-to-sms 
gateways. Might have been going on a long time and I’m just noticing.

No emails are accepted between 0:00 to 11:59 UTC time every day (the deferrals 
during that time frame are a somewhat misleading AUP#CNCT from Cloudflare)
Emails are accepted only between 12:00 to 23:59 UTC time every day.

12 UTC is 7 EST

So in my opinion this looks like an enforced “do not disturb” by Verizon to 
ensure SMS delivery only between 7am to 7pm EST time - during the "social 
hours" or whatnot. At least one other ESP I have contact with has confirmed 
they're seeing exactly the same time frames.

I'm not a fan of the somewhat unclear bounce/deferral string they're returning 
but I don't think Coudflare is doing it on their own, it's too clean of a 
cutoff time - probably a Verizon rule.
On 01/06/2023 02:22, Zube via mailop wrote:

This is new as the past few days and rather odd.



Mail sent through the Verizon email-to-text gateway is fine during

the day when the relay is:



relay=vrz-mms.mx.a.cloudfilter.net. [52.37.233.84]



or



relay=vrz-mms.mx.a.cloudfilter.net. [35.169.108.175]



but starting somewhere around 5pm MST, mail sent to vtext.com,

vzwpix.com or mypixmessages.com is deferred:



relay=smtpin02-mms.vzw.a.cloudfilter.net. [52.33.196.155],

dsn=4.0.0, reply=421 vrz-ibgw-6003a.ext.cloudfilter.net



Mail sent from gmail makes it through.



Sometime around 5am the following day, a resend of the mail makes

it through again, but then it's hitting one of the two other servers

listed above.



I'm not the only one seeing this:



https://community.verizon.com/t5/Verizon-Messages/Vtext-messages-Severe-Delay/td-p/1240767/page/7



Going the other way, text-to-email seems to work fine and it arrives from

(in one test) twbgohaavzwvcmta-c-nk-x-00-sms-02.vtext.com [63.55.64.200]

after first going through m04.vzwpix.com (unknown [63.59.66.15])



If anyone from Verizon or cloudfilter.net is listening, please

advise.



Cheers,

Zube

___

mailop mailing list

mailop@mailop.org

https://list.mailop.org/listinfo/mailop
--
--
Dima Gomonyk
Email Deliverability&Abuse Specialist, SMTP

Campaigner | iContact | SMTP

p:

877.705.9362

a:

2 Gurdwara Rd, Suite 300, Ottawa, Canada

w:

smtp.com
 e: dmitry.gomo...@smtp.com






This email, its contents and attachments contain information from Ziff Davis, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution or use of the contents of this message is prohibited. If you have 
received this email i

Re: [mailop] RackSpace Security Issue

[Richard via mailop]

> Date: Monday, December 05, 2022 10:50:48 -0800
> From: William Kern 
>
> I was contacted by a website customer over the weekend, who is
> affected by the RackSpace Exchange "security issue".
> 
> At this point, they are transitioning to O365 so they should be
> fine going forward, but aside from email interruption they are not
> sure how they are affected.
> 
> Their main concern is email disclosure.
> 
> I'm trying to 'google' around but most of what I am finding are
> 'Rackspace is down' and complaints they aren't saying much.
> 
> Does anyway have additional info?
> 
> Since I also have customers who run their own Exchange servers, I'm
> curious if there is some new exploit out there, that they should be
> worried about.
> 
> Sincerely
> 

See their status page:



for hints, such as they are. They have been updating that page every
12 to 24 hours.


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

Re: [mailop] mailop list server unreachable

[Richard via mailop]

> Date: Tuesday, August 18, 2020 14:27:09 -0700
> From: Ken Simpson 
>
> Is anyone else seeing this when they try to connect to the listserv?
> 
> $ curl https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> *curl: (7) Failed to connect to chilli.nosignal.org
>  port 443: Connection refused*

I believe that the server moved recently, but the list information in
the headers hasn't been updated yet. It appears that the list's
mailman pages can be gotten to at:

   



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