Re: [mailop] Sendgrid strikes again; zendesk, actually

Am 25.02.20 um 19:12 schrieb Alessandro Vesely via mailop: > On Tue 25/Feb/2020 16:30:29 +0100 Luke via mailop wrote: >> Some more detail on this would be helpful. > On Mon, 24 Feb 2020 11:35:08 +0100 I received the first abusive message, with > subject: "I have videos of you masturbating" > sent

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

Am 26.02.2020 22:35, schrieb Michael Peddemors via mailop: ... * Unsubscribe pages/urls * Domain Pages I'm somewhat unsure about this one. Although nowadays the WWW *is* the internet for many people, running a mail server and running a web presence are two different things, and it should be

Re: [mailop] Any idea who wrote 'Spam Lawsuits: What's the Worst that Can Happen?' ?

Am 26.02.2020 22:59, schrieb Tom Kulzer via mailop: http://static.mailchimp.com/www/guides/spam-lawsuits/package/spam-lawsuits.pdf Well, it looks like their server is overwhelmed by the millions of mailop readers trying to fetch that document all at once: An error occurred while processing

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

Am 16.02.2020 22:15, schrieb Jaroslaw Rafa via mailop: Dnia 16.02.2020 o godz. 15:21:34 Hans-Martin Mosner via mailop pisze: 1. Don't hide behind anonymity. Mail server domain whois should have an identifiable registrant organization, there [...] 8. (opinionated) Don' use SPF, it's broken

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

Am 17.02.20 um 19:21 schrieb Alessandro Vesely via mailop: > On Sun 16/Feb/2020 15:21:34 +0100 Hans-Martin Mosner via mailop wrote: >> (opinionated) Don' use SPF, it's broken by design. > > I don't think that a FAQ starting with such opinionated entries is going > anywhere. &

[mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

Some ideas from running small to medium mail servers for a long time. Many of you will probably have more extensive experience and advice, but this is just a minimal list off the top of my head to get something for a start: 1. Don't hide behind anonymity. Mail server domain whois should have

Re: [mailop] Opinions? Email Abuse over TOR Network? (spamtraps)

Am 20.02.2020 11:02, schrieb Benoit Panizzon via mailop: But I guess, just silently blacklisting Tor exist nodes and not sending a ARF report to the ISP could be an option to solve that issue. This is probably a reasonable way of dealing with the problem. TOR exit nodes are somewhat like

[mailop] Spam from no-re...@sharepointonline.com via outbound.protection.outlook.com

Hello, for a number of days, "no-re...@sharepointonline.com" is sending mails to non-existent addresses (many of which are quite certainly imported from some circulating address list, as we have seen them being targeted for years). Mar 15 11:58:49 mail postfix/smtpd[19571]: NOQUEUE: hold: RCPT

Re: [mailop] Spam from no-re...@sharepointonline.com via outbound.protection.outlook.com

Am 22.03.20 um 08:37 schrieb Suresh Ramasubramanian via mailop: > > This is abuse of free trial accounts of office 365, and the document sharing > that sharepoint allows.   Create a > document with porn spam text and share it, with a porn spam spiel, with a big > list of spam recipients. > >   >

[mailop] Orange.es - anybody home?

Hello, I've tried to report some spam to orange.es, this report is stuck in our outgoing queue: (host inc.wanadoo.es[62.36.20.20] refused to talk to me: 451 Temporary local problem - please try later) ab...@orange.es Manual telnet session from my home

[mailop] Spam using bit.ly link shorteners, this time via Outlook

Hi, most have probably seen the spams containing just a bit.ly short link and names of recipient and purported sender (likely from hacked address books). They mostly came via hacked mail accounts, but now the spammer seems to have a bot creating accounts at outlook.com for this purpose. Does

Re: [mailop] [External] Spam using bit.ly link shorteners, this time via Outlook

is targeted to german users... Cheers, Hans-Martin Am 16. September 2020 10:25:00 schrieb "Kevin A. McGrail" : I have seen then and have rules for SpamAssassin that combat them. Are you using SpamAssassin? Regards, KAM On September 16, 2020 2:00:09 AM EDT, Hans-Martin Mosner via mailop

[mailop] cloudapp.azure.com?

Hello, do others see spam waves from cloudapp.azure.com, too? In the logs, it looks like this (anonymized) Oct  9 11:43:54 mail postfix/smtpd[19958]: NOQUEUE: reject: RCPT from ijhytgfgg-germanywestcentral12.germanywestcentral.cloudapp.azure.com[51.116.228.69]: 554 5.7.1 <>: Sender address

Re: [mailop] Just how does SendGrid fail this badly?

It's in the envelope sender, which your mail system probably doesn't preserve when it stores mail. Traditional mbox format has it in the 'From ' line. Cheers, Hans-Martin Am 18. August 2020 20:03:46 schrieb Carl Byington via mailop : -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

Am 28.08.20 um 10:10 schrieb Bjoern Franke via mailop: > > and this also no guarantee for no spam. Recently I got some spam for > "dates18.com" sent via Casual Networks B.V (on > the CSA whitelist) in which even the "Imprint"-URLs lead to "Congratulations, > you confirmed your mailaddress".

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

Am 26.08.20 um 19:36 schrieb flo via mailop: > Hi there > > Have any of you had any bad experiences with Deutsche Telekom lately? > They put one of my servers on their blacklist after an IP change with > the reason that I have to provide an imprint on that machine. > Have I missed something? Is

Re: [mailop] Just how does SendGrid fail this badly?

Am 20.08.20 um 09:10 schrieb Benoit Panizzon via mailop: > > Return-Path: > > Does the c581 part also belong to the account id? No, it's a short hash to verify that bounces were indeed caused by mails actually sent from sendgrid. For example, and are doodle notifications sent to two different

Re: [mailop] Mailman confirmation email denial of service

After having thwarted additional attacks (thanks for the hint about SUBSCRIBE_FORM_SECRET!) I looked at our mailman logs to see if everything is quiet now, and to find patterns. Apparently the initial check was from a serbian IP address: Aug 18 10:01:55 2020 (8184) : pending mmc49...@eoopy.com 

Re: [mailop] Mailman confirmation email denial of service

Am 19.08.20 um 11:51 schrieb Andy Smith via mailop: > Hi, > > Not sure if this is the best place to mention this, but… > > Since yesterday I've been seeing a large number of attempted > subscriptions to all the public lists on one of my Mailman servers. > There's so far been 160 attempted

Re: [mailop] Maximum message size

Am 24.10.20 um 19:19 schrieb John Levine via mailop: > > FTP was swell forty years ago but it's obsolete now. Nothing, > including the user names or passwords, is encrypted, and it needs to > set up a second TCP connection for each data transfer which confuses > NATs and firewalls. > > There are

Re: [mailop] OVH Bulk Mailer? Anyone know this one?

Am 07.08.20 um 19:14 schrieb Alain Gaudreau via mailop: > > I disagree Hans-Martin. > I sympathize with you. Constantly fighting mail blocks is certainly as tiring as constantly fighting mail abuse. > >   > > We have been using ovh for years and years and enforce strict abuse policies > on our

Re: [mailop] OVH Bulk Mailer? Anyone know this one?

Am 07.08.20 um 22:54 schrieb Alain Gaudreau via mailop: > @Chris > > My vision of it is larger and includes a blacklist with the ability to > exclude and grey list certain hosts within the large blocks controlled by ovh > and the lot. I'm working on a system which may in the long run include

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

Am 11.08.20 um 18:22 schrieb Len Shneyder via mailop: > Hello Benoit and Hokan, > > Thanks for pointing this out and I'm sorry you're still seeing what sounds > like a high volume of phish. I've asked our > fraud ops team to investigate this. In the future if you could send > suspicious emails

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

Am 13.08.20 um 19:28 schrieb Al Iverson via mailop: > On Thu, Aug 13, 2020 at 11:34 AM Hans-Martin Mosner via mailop > wrote: >> Mails to abuse@ should be handled quickly without being CC'd to a VP. It's >> the abuse desks job to stop abuse ASAP. If they are understaffed

Re: [mailop] OVH Bulk Mailer? Anyone know this one?

Unless you or your users happen to be customers of those few mostly french companies who use OVH for customer communication, blocking them is a pretty sensible thing to do. They still host spammers, they still ignore abuse reports, so nothing has changed in the last year. Cheers, Hans-Martin

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

Am 11.08.20 um 16:53 schrieb Benoit Panizzon via mailop: > Hi List > > o1678912x138.outbound-mail.sendgrid.net [167.89.12.138] and IP under > control of sendgrid was repeatedly involved in phishing and other spam > since June. > > It ended up being blacklisted @ SWINOG. > > Now a sendgrid

Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...

Am 17.06.20 um 21:15 schrieb vom513 via mailop: > I know the ultimate answer is “do what makes sense for me” - but I’d love > some feedback from folks here on what they consider best practice etc. Also > please help me with my understanding of SPF / DMARC interactions (especially > with regard

Re: [mailop] Microsoft Block list (S3150)

Am 29.06.2020 13:16, schrieb Laura Atkins via mailop: On the advice of their lawyers Microsoft doesn’t share that information with senders. laura Sounds a bit like Kafka's "Der Prozess". Don't tell the defendant what he's being accused of... Cheers, Hans-Martin

Re: [mailop] Microsoft Block list (S3150)

Am 29.06.20 um 16:42 schrieb Michael Rathbun via mailop: > On Mon, 29 Jun 2020 15:46:05 +0200, Hans-Martin Mosner via mailop > wrote: > >> Am 29.06.2020 13:16, schrieb Laura Atkins via mailop: >>> On the advice of their lawyers Microsoft doesn’t share that >

Re: [mailop] [EXTERNAL] Re: Microsoft Block list (S3150)

Am 29.06.20 um 21:30 schrieb Michael Wise via mailop: > >   > > A **VERY** strong economic argument. > >   > I know. I'm mainly venting my frustration, knowing too well that my activity won't flip a single bit in Redmond. Hoping that some organization would do the right thing because it's the

Re: [mailop] Ongoing Spam-OP from 'Alphainfo INC' / Garuda Mailer / GBS Industries

Am 22.06.20 um 17:01 schrieb Benoît Panizzon via mailop: > > Anyone else seeding those emails since about 2 Months or having any > contact to Alphainfo INC / Alphainfo Lab / gbsind.com / GBS Group ? > Alpha Infolab (AS133320) has been in my "block-unconditionally" list for ages. They host

Re: [mailop] [EXTERNAL] Blocked from hotmail/live/outlook but ticket response says not blocked

Am 07.01.21 um 01:49 schrieb Seth Mattinen via mailop: > > Well, now I just got an email that says "Not qualified for mitigation Coming from Microsoft, this is particularly hypocritical as two of their own services (Sharepoint and Azure) are massive sources of spam, in addition to all the

Re: [mailop] Contacts from Arcor on the list? Abuse of a platform on Azure occurring..

Am 25.11.20 um 19:28 schrieb Michael Peddemors via mailop: > Seems like Arcor.de is using a 3rd party for something, and it's email > functions are being abused.. > > Judging by the SPF record, it looks like they are intentionally using this > 3rd party service.. > >  host -t TXT arcor.de >

[mailop] Effeciveness (or not) of SPF

Hi folks, due to its negative effects on mail forwarding I've resisted touching SPF for a long time (I know mail users should not simply forward their mail, and the effects can be mitigated with SRS, but some users simply can't be bothered to configure multiple accounts and access them properly

Re: [mailop] [FEEDBACK] Azure Spammer Activity

Yesterday and the day before we received such a massive wave from them that I had to temporarily block several Microsoft IPv4 ranges... Today we got a response to our abuse reports requesting that we report these to j...@office365.microsoft.com - I would've thought that within one corporation,

Re: [mailop] Effeciveness (or not) of SPF

Am 07.12.20 um 23:51 schrieb Thomas Walter via mailop: > > I fully agree, but gmail is a bad example, because they actually support > importing remote mailboxes with pop3 which does not require forwarding. > We never tried that, but it is an option: Well if giving The Goog all kinds of

Re: [mailop] Gosh, I love sendgrid

Am 22.12.20 um 02:56 schrieb Eric Tykwinski via mailop: > Seriously, this is probably political…  Not saying I agree, but unless it’s > spam, i.e. unwanted by your recipients, > then you just have a bunch of wack jobs as clients and keep it at that. As John has stated in his original mail, it

Re: [mailop] open RBL and RHSBL lists these days?

Am 14.12.20 um 23:28 schrieb Mary via mailop: > So what is trix.bounces.google after all? google offers a spam service these > days? > They probably wouldn't call it that, but it essentially is. It's the Google Forms feedback request mechanism, where users can send requests to fill out forms to

Re: [mailop] cloudapp.azure.com?

Am 09.10.20 um 12:27 schrieb Hans-Martin Mosner via mailop: > Hello, > > do others see spam waves from cloudapp.azure.com, too? So, after 9 weeks, despite several abuse reports to the appropriate places, this still continues (and not a single response indicating they understand that th

Re: [mailop] SSL Cert and Reputation Question

Am 13.11.2020 15:31, schrieb Tonya Gordon via mailop: Good morning! Does anyone have any insight into the following question we received from a customer? “If we're using a wildcard SSL cert across multiple sending/bounce/tracking domain configurations, will ISPs then associate those configs

Re: [mailop] Google bounce after accept

Am 30.10.20 um 08:57 schrieb Atro Tossavainen via mailop: > Why does Google bounce after accepting a message? At Google's scale, > the potential to become the world's biggest spammer simply through > backscatter is enormous. > Sadly, doing the correct thing isn't always technically possible. The

Re: [mailop] problems sending mails to gmx/web.de

Am 28.12.20 um 11:19 schrieb Ruben Herold via mailop: > > hi, > > I have a system that runs since christmas day's in the: > > https://postmaster.gmx.net/en/error-messages?ip=185.48.106.12=irlim > https://postmaster.web.de/error-messages?ip=185.48.106.12=irlims Both links indicate rate limits. How

Re: [mailop] [E] Re: IP based reporting for Yahoo feedback loop gone?

Am 31.12.20 um 22:07 schrieb Hal Murray via mailop: > Scott Mutter said: >> If spam is sent from one of our servers - the IP address of one of our >> servers - it's me you ultimately want to contact, not the owner of the IP >> address. If you contact the owner of the IP address - they don't have

Re: [mailop] [FEEDBACK] Azure Spammer Activity

Am 09.12.20 um 08:43 schrieb Hans-Martin Mosner via mailop: > Today we got a response to our abuse reports requesting that we report these > to j...@office365.microsoft.com - I > would've thought that within one corporation, forwarding of abuse tickets > should work somehow. Well i

Re: [mailop] Sendgrid again...

Am 22.01.21 um 15:22 schrieb Andrew C Aitchison via mailop: > > Are you sure that it was Sendgrid that blocked the message ? > Looks to me as if ab...@sendgrid.com is hosted at gmail and > it was *gmail* that objected to the content ... > > Or am I misunderstanding something ? No, of course

[mailop] Sendgrid again...

Well I'm not complaining about the spam from them - it's a steady flow, nothing new. But it looks like they have filters on their abuse box now to reduce the amount of abuse reports: The original message was received at Fri, 22 Jan 2021 05:45:50 -0800 from m0099904.ppops.net [127.0.0.1]

Re: [mailop] [E] Re: Sendgrid again...

Am 22.01.21 um 17:16 schrieb Marcel Becker via mailop: > > > Bulk mail, email marketing, consumer email, enterprise email. Those are all > different businesses. Just because a > company does one thing doesn't mean it should be doing (or be good at) the > other.  True, but... If a company is

Re: [mailop] Is it something to worry about?

Am 20.01.21 um 10:40 schrieb Jaroslaw Rafa via mailop: > Hello, > just got an information from MxToolbox that my IP (actually not my IP in > particular, but the ASN it belongs to) has been blacklisted at UCEPROTECT > level 3. Checking of my IP (217.182.79.147) at >

Re: [mailop] [FEEDBACK] Azure Spammer Activity

Am 14.01.21 um 19:06 schrieb Jaroslaw Rafa via mailop: > Who will draw the line between what is and what isn't allowed to > publish/send/say on the Net? Who will guarantee taht when you send some > political content with which your ISP doesn't agree, you won't be labeled as > "spammer" and "bad

Re: [mailop] [FEEDBACK] Azure Spammer Activity

Am 14.01.21 um 23:50 schrieb Andreas Schamanek via mailop: > > On Thu, 14 Jan 2021, at 20:22, Michael Wise via mailop wrote: > >> On Tue, 8 Dec 2020, at 23:43, Hans-Martin Mosner wrote: >>> Today we got a response to our abuse reports requesting that we report >>> these to

Re: [mailop] Does anyone have any contact for cloudmark.com?

Am 05.01.21 um 23:28 schrieb Brian Reichert via mailop: > I had mail recently bounce, with this seemingly informative message: > > Remote host said: 550 5.7.1 H:CSI [66.228.38.138] Connection > originating from an IP address with a poor reputation. Please see >

Re: [mailop] Microsoft and Verizon not acceping mail

Apparently it's not a general problem for everyone, so it's likely the problem is somehow at your installation. If you want actual help in diagnosing the problem you should provide a bit more information, such as the error messages seen, and possibly traceroute output if you can't connect to

Re: [mailop] *** SPAM *** Re: Massive increase in fake medication spam from AS53667 (PONEYNET)

Am 08.06.21 um 20:43 schrieb Scott Techlist via mailop: >> I'm using the "registrar-servers.com" nameserver as a pretty good predictor >> of spamminess. There are few exceptions of >> legitimate senders who think they need such registration info protection but >> they can be handled by

Re: [mailop] Outlook sending with no PTR

Am 12.06.21 um 07:32 schrieb Noel Butler via mailop: >   > these are confirmed legitimate emails being affected by MS not have rdns on > those servers, we will not whitelist, > there are many Australian ISP/ASP's being affected, its been discussed over > several days. >   >   Ah, I had been

Re: [mailop] Any mailbox providers that check geolocation of mail sending IP?

Am 10.06.21 um 17:00 schrieb Vytis Marciulionis via mailop: > > Hello mailbox providers, > >   > > Recently we have introduced anew /24 IP range to our mail sending > infrastructure: > > 45.86.119.0/24 > >   > > This is not a new process and we did not encounter any issues before.  > However,

Re: [mailop] Outlook sending with no PTR

Am 11.06.21 um 06:14 schrieb Noel Butler via mailop: > > MS sending out mail with no rdns? > >   > Jun 10 09:20:20 cust-mta01 postfix/smtpd[8137]: NOQUEUE: reject: RCPT from > unknown[40.92.62.80]: 554 5.7.1 Client host > rejected: cannot find your reverse hostname, [40.92.62.80]; > from= to=

Re: [mailop] [ext] Re: *** SPAM *** Re: Massive increase in fake medication spam from AS53667 (PONEYNET)

Am 09.06.21 um 09:34 schrieb Ralf Hildebrandt via mailop: > > Bonus: In Postfix you can block those using check_sender_ns_access (or > at least put them on HOLD) Nice, I may have seen that at some time but wasn't aware of it now. That's certainly the easiest solution for postfix users. Btw, if

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

Am 12.05.21 um 09:39 schrieb Michael Rathbun via mailop: > On Wed, 12 May 2021 08:37:30 +0200, Hans-Martin Mosner via mailop > wrote: > >> Yet at the same time Microsoft expects "the world" to accept mail from their >> customers. > It would be difficult to ver

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

Am 12.05.21 um 08:13 schrieb Michael Rathbun via mailop: > > You may wish to take into account economic realities. > > YOU are not a Microsoft customer. > The RECIPIENTS are not Microsoft customers. > > None of the above parties pays Microsoft a cent. Yet at the same time Microsoft expects "the

[mailop] 1&1 (IONOS) invitation spam - are there any plans to stop this?

Hi, for some weeks, the 1&1 invitation/calendar service is being used to transmit spam. As there are some legitimate users, we can't simply block the e-mails identified as coming from this service, so 1&1: Please ix this! It's just not reasonable to let freshly registered users without a

Re: [mailop] 1&1 (IONOS) invitation spam - are there any plans to stop this?

Am 17.05.21 um 13:12 schrieb Marc Ballarin via mailop: > Hello, > > None of the complaints you sent references a mail sent via IONOS' systems. > Please note that GMX, mail.com > and WEB.DE are distinct companies, > products, mail systems as well as abuse teams.

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

Am 07.05.21 um 16:31 schrieb Steven Champeon via mailop: > > As for Haraka, I haven't followed it closely but know Matt to be a solid > coder; the impression I got when he was writing it was that it was on a > lark to see if he could write an RFC-compliant SMTP server in > Javascript. I think the

Re: [mailop] Recommendations for mail campaign services

Am 05.05.21 um 21:43 schrieb micah via mailop: > On 2021-05-05 14:43:35, Brian Weir via mailop wrote: >> I would definitely stay away from SendGrid unless you get a dedicated IP. > Can you say more about why that is? I'm curious to know more about > how blocked/unblocked SendGrid is They're

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Am 28.05.21 um 15:22 schrieb Hans-Martin Mosner via mailop: > Am 28.05.21 um 13:47 schrieb Hans-Martin Mosner via mailop: >> Anyone from Microsoft/Outlook available to look into the matter? > Seems everything is ok now - either someone looked into the matter (thanks!) > or some

[mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Hello, for a couple of hours Office365 recipients are unreachable from our server (not heeg.de, another one) due to SMTP rejections of this kind: (host viakom-de.mail.protection.outlook.com[104.47.5.36] said: 451 4.7.500 Server busy. Please try again later from [...]. (S77719)

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Am 28.05.21 um 13:47 schrieb Hans-Martin Mosner via mailop: > Anyone from Microsoft/Outlook available to look into the matter? Seems everything is ok now - either someone looked into the matter (thanks!) or some timeout ran out :-) Cheers, Hans-Mar

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Am 01.06.21 um 12:39 schrieb Daniel K. via mailop: > ... > I don't know anything about the specific error code you showed upthread, > but I finally managed to get in touch with Hotmail sender support > regarding my own problem - by using another email address than the one > used in the form. > >

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Am 01.06.21 um 20:48 schrieb John Levine via mailop: > > You should definitely demand a full refund of all the money you've paid > Microsoft to deliver your mail. > > Oh, wait, ... Well I'd be happy if they just paid a little bit for the time that I had to spend to protect our users from their

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

Am 01.06.21 um 21:39 schrieb John Levine via mailop: > > No, it's to deliver the mail that the users want. One point that bulk > mailers often miss is that, while the recipients at large providers do > not object to getting the bulk mail, they also do not really want it. We're not talking about

Re: [mailop] Abuse reporting to Microsoft?

Am 24.06.21 um 00:49 schrieb Simon Arlott via mailop: > Is it actually possible to report email abuse to Microsoft? > > Yes it is possible. It just doesn't have any effect. Sadly, blocking them affects too many legitimate senders, otherwise I'd have done it long ago. The current spam

Re: [mailop] Old subject, awareness, given recent Microsoft disclosure.. blocking port 25 from dynamic/DUL networks

Am 09.07.21 um 00:20 schrieb Steven Champeon via mailop: > on Thu, Jul 08, 2021 at 02:28:13PM -0700, Michael Peddemors via mailop wrote: >> Ex. 1.186.104.104x1 1.186.104.104.dvois.com > Even better still dvois.com uses the same naming for dynamics and > statics. At least they only have

Re: [mailop] So how do you actually manage to send mails to outlook/hotmail?

Am 11.07.21 um 19:39 schrieb Marcus Hoffmann via mailop: > Which leads me to the question: What on earth would I need to do to be able > to send emails to MS controlled > mailservers which people will actually read? One does not simply send mails to outlook/hotmail Sorry, could not resist.

Re: [mailop] So how do you actually manage to send mails to outlook/hotmail?

Am 11.07.21 um 19:39 schrieb Marcus Hoffmann via mailop: ... > > Original sending IP: 176.9.145.28 > New sender: 5.45.96.14 As others have already noted, Hetzner has a somewhat bad reputation. From my experience, this may somewhat be explained by their intransparent and subjectively ineffective

Re: [mailop] Contact for Zoom webinar spam sent via Sendgrid (ugh)

Am 08.07.21 um 18:14 schrieb Luke via mailop: > Just so the group is aware, our team is looking into the Zoom traffic. We > aren't sure what they are doing with that > mail stream, but it doesn't look good. > > Both of the accounts reported by Michael have been suspended. > > Thanks, everyone. >

Re: [mailop] Huh?

Have you tried asking *them* about their thought process? They are probably better prepared to explain them than some random people on the internet... But I would not rule out the possibility that they can't explain what's been going on in their heads. Cheers, Hans-Martin Am 30. April 2021

Re: [mailop] [INFORMATION] What's happening in the world of spam/email abuse update

Am 27.04.21 um 17:00 schrieb Michael Peddemors via mailop: > Well, in better news, I get my vaccine shot tomorrow ;) Great! > > Havent' posted one of these in a while, but last couple of weeks has spam > auditors very busy.. > > * Huge amounts of reports from Azure IP(s), Hit and Run > > (If you

Re: [mailop] Some Days I think that Gmail isn't even trying to stop outbound spam..

Am 04.02.21 um 17:43 schrieb Luke via mailop: > Preventing outbound spam on a large system is a far greater challenge than > stopping inbound spam. The technical > challenges are similar, but the logistical challenges of preventing outbound > spam without pissing off customers is > /far/ greater

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

Am 27.03.21 um 14:07 schrieb Renaud Allard via mailop: > > > On 09/03/2021 18:38, Arne Allisat via mailop wrote: >> Just a short info to whom it might interest: >> >> Very soon, we will go live with DMARC check on incoming mails for all >> mailboxes operated by WEB.DE, GMX & mail.com >>

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

Am 27.03.21 um 15:29 schrieb Hans-Martin Mosner via mailop: > > One problem with SPF/DKIM/DMARC is that due to non-malicious manipulation of > messages (for example forwarding etc.) > messages may look invalid at the receiving site. I just noticed that the mails in this

Re: [mailop] [E] Re: Info - DMARC at WEB.DE, GMX, mail.com coming soon

Am 01.04.21 um 16:36 schrieb Marcel Becker via mailop: > On Thu, Apr 1, 2021 at 12:43 AM Hans-Martin Mosner via mailop > mailto:mailop@mailop.org>> wrote: > > > One option that you should consider to mitigate the effects for > recipients is to allow per-recipien

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

rack. > Are you saying that GMX should not use DMARC, or that they should not > treat reject as quarantine ? > > On Thu, 1 Apr 2021, Hans-Martin Mosner via mailop wrote: > >> At risk of repeating myself, you should be aware that this decision >> will

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

At risk of repeating myself, you should be aware that this decision will not respect the will of the senders or recipients, but the probably well-intentioned but not necessarily well-informed will of the sending mail system operator. You *will* cause unintended mail rejections, and the parties

Re: [mailop] Delivery issues with gmx recipients

Am 12.03.21 um 14:16 schrieb Michael Peddemors via mailop: > On 2021-03-12 4:58 a.m., Hans-Martin Mosner via mailop wrote: >> Am 12.03.21 um 11:53 schrieb Arne Allisat via mailop: > >> >>   * Ensure that the following email headers included in your message are >>  

[mailop] Technical details on MS Exchange vulnerabilities?

Hello, does anyone have a pointer to technical details about the recently surfaced Exchange vulnerabilities? I would specifically be interested whether the exploit(s) depends on the server being exposed to the internet directly and would thus not be too critical if there's a Postfix internet

Re: [mailop] Delivery issues with gmx recipients

valid (it can appear in a double-quote enclosed string, or must be encoded). Tricky... Big thumbs up to GMX support for pointing out that header line. Now I'll need to find out what broken MUA my colleague is using. Cheers, Hans-Martin 12. März 2021 13:58, "Hans-Martin Mosner via mailop&

Re: [mailop] Reliability of DMARC reports?

Thanks all for the encouraging answers, folks! I've weakened our policy for now to "none" to squash the problems that still exist especially in the area of forwarding and mailman3 lists. But I'm confident now that we will be able to both generate DMARC-validatable mails and make use of DMARC

[mailop] Reliability of DMARC reports?

Hello, due to the recent GMX mail rejection incident (for which I still don't have a satisfactory explanation from GMX) I've enabled DMARC on our mail server in the hopes of getting better deliverability. But some of our outgoing mails were rejected, and the aggregate DMARC reports we were

Re: [mailop] Delivery issues with gmx recipients

Am 12.03.21 um 10:24 schrieb Arne Allisat via mailop: > Hello, > > Please report your ip’s and an example error message to our postmaster team > https://postmaster.gmx.net/en/contact We're having problems as well (554-Reject due to policy restrictions).

Re: [mailop] Delivery issues with gmx recipients

Am 12.03.21 um 11:53 schrieb Arne Allisat via mailop: > Sorry. Me again. > > Two things: Some people experience temp rejects with an c=irlims message.I > thought that is your case as well, but it > isn’t. > > In your case it is an c=hi and you are pointed to the „Sending mail to GMX“ > page >

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

Am 25.02.21 um 18:53 schrieb Scott Mutter via mailop: > > In hosting, datacenter renting, situations where we're discussing OVH and > Vultr and other providers, the OWNER of the > IP address doesn't necessarily have the same interest as the USER of the IP > address in terms of mail

Re: [mailop] Greylisting never passing on retry

Am 20.04.21 um 11:06 schrieb Neil Youngman via mailop: > I have observed that messages from our system are temporarily rejected > as greylisted by one destination but they are never accepted on retry. > The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted > for 5 minutes". We

Re: [mailop] Gmail inboxing help

Am 18.02.21 um 15:22 schrieb Lauren Donovan via mailop: > Hi Everyone, > > I am wondering if someone here might have some insight into an issue I am > experiencing with Gmail customers. Here are > the details: > > 1.) When the customers click to opt-in on our form page, they are sent a >

Re: [mailop] Some Days I think that Gmail isn't even trying to stop outbound spam..

Please folks, don't take my comments as aggressive, even though they may sometimes come across as cynical. My top priority is to somehow help curb the flood of spam, not to accuse people of not doing enough or not doing the right thing. Am 05.02.21 um 04:23 schrieb Brandon Long via mailop: > If

Re: [mailop] When RBLs go bad

Am 14.02.21 um 11:45 schrieb Gary Gapinski via mailop: > On 2/14/21 1:42 AM, André Peters via mailop wrote: >> Have you guys already read this?  >> https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html > > I had not read it, but just did. > >> I have seen the discussion and found it

Re: [mailop] Good Hosting Suggestions?

Am 21.02.21 um 02:47 schrieb Allen Kitchen (zoominternet) via mailop: > Eh - not for presently-understood threats. > > But it still seems like a possible vector for as-yet-unknown exploits; ASCII > text a little less so. But ymmv. > > ..Allen Of course you should not open binary attachments such

Re: [mailop] Spam Rejection Issues with 'forwarding services' @ namecheaphosting.com

Am 19.02.21 um 10:36 schrieb Benoît Panizzon via mailop: > Hi List > > One of our customers way desperately trying to reach company hosting > it's email services namecheaphosting.com > > eforward1.registrar-servers.com[162.255.118.51] was constantly > rejecting our customers emails as spam. We

Re: [mailop] Good Hosting Suggestions? (old subject @ namecheaphosting.com)

Am 19.02.21 um 17:45 schrieb Michael Peddemors via mailop: > Any other hosting companies that you would "recommend" for email hosting? The sad (no, actually good) truth is that there are so many good hosters that recommending one or a few would always be highly subjective and wouldn't do

Re: [mailop] gmail SPAM reporting works fine

There definitely is a performance/reliability issue. It doesn't only affect the we fron end but also SMTP based submission where 45x type errors don't really matter. Cheers, Hans-Martin Am 18. September 2021 17:40:48 schrieb Andy Smith via mailop : Hello, On Sat, Sep 18, 2021 at

[mailop] cloudapp.azure.com spamming again

Hi, after some hiatus, the cloudapp.azure.com spammers are at it again. Hostnames are patterned like akhm-i69.northcentralus.cloudapp.azure.com (different numbers between "i" and "", different region domain parts). I'm somewhat hoping that MS gets this under control quickly.

Re: [mailop] Xfinity / Comcast / rsys5.com

15. September 2021 08:55, "Daniele Nicolodi via mailop" schrieb: > Hello, > > I understand that industry back practice recommends to have > "unsubscribe" links in promotional bulk messages. Shouldn't these links > direct to some form that effectively allows to remove the recipient > address

  1   2   3   >