Re: [mailop] SMTP noise from *.bouncer.cloud

On 5 Sep 2022, at 18:07, Atro Tossavainen via mailop wrote: >> This is a bit less clear, but I'd say that is fine because you have >> every reason to believe that you are acting on behalf of the address >> owner, not some 3rd party who may not have acquired the address >> legitimately. > > This,

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

On 29 Jul 2022, at 14:32, Anne Mitchell via mailop wrote: I want to be sure that everyone here is aware of a piece of pending legislation in the U.S. that is in committee in both the House and the Senate right now. It's called the Political BIAS Emails Act of 2022 (BIAS is short for “Bias In

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 25 Jul 2022, at 11:00, Laura Atkins via mailop wrote: >> In the current state of affairs, ESPs presume they know more than the >> receivers, so they keep trying to send. Since the ESPs essentially disregard >> the 5xx codes using the line of reasoning that you described, > > The ESPs are not

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 23 Jul 2022, at 4:17, Laura Atkins via mailop wrote: > I agree, it would have been nice if the authors of 821 and 822 had considered > this use case and provided us with semantics. Unfortunately, the semantics > described in those RFCs (and their successors) only talk about what to do >

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote: > We’re trying to pull ‘what to do with a completely different message that > might be sent in the future, possibly by a completely different sender' out > of a signalling system that was never designed to convey that signal. And, > yes,

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 24 Jul 2022, at 22:09, Ángel via mailop wrote: > Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936 > If you can hash multiple emails until finding who that refers to, then > it's equivalent to the email. But if it is also the hash of other email > addresses

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 22 Jul 2022, at 13:10, Atro Tossavainen via mailop wrote: [✄ but thoroughly read] > Becoming a data controller entails needing a legitimate basis for > processing the personal data of the customer's customers, with whom > the ESP does not have any kind of a direct business relationship so >

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote: >> This would allow the ESP to quickly "fail" the API request to send to that >> email address. There are other metrics that could be tied into those >> addresses and used to provide a more expedite response to the caller, which >>

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote: > I’m agreeing there is a problem with ESPs and have said so to ESPs > individually and as a group over the last few weeks. Something that I don't see mentioned often enough and that would help, is to retain records of bounces—even of

[mailop] Paging Cloudmark

I would appreciate any pointers to a colleague at Cloudmark. I need assistance with a false positive and the regular contact / delisting process seems to not be working. Best regards -lem ___ mailop mailing list mailop@mailop.org

Re: [mailop] Contact at NameCheap?

On 15 Jun 2022, at 12:37, Anne Mitchell via mailop wrote: > Does anyone have a technical contact or an abuse contact at NameCheap? The contact information they publish in their WHOIS (for domains they sponsor) is accurate. It might not yield the result you wish for though. Best regards -lem

Re: [mailop] *LIKELY SPAM 27.9* Re: Any reason to NOT block the entire .cam domain?

On 27 May 2022, at 16:57, Hans-Martin Mosner via mailop wrote: > Whether blocking a whole ASN is more advisable than blocking a whole TLD is a > matter of opinion - I've often seen that past spammer hosting in an ASN's IP > space was a good predictor for future spamminess, but of course as with

Re: [mailop] *LIKELY SPAM 29.9* Any reason to NOT block the entire .cam domain?

On 27 May 2022, at 15:28, Michael Rathbun via mailop wrote: > The same gang has been trying out .mom and .lol, of late. According to my notes, they are one of the groups actively following TLD operators' promotions. I just saw .cam names selling for under 2.5$/reg Best regards -lem

[mailop] Paging 3cx.com/3cx.net

If someone has a technical contact with them, I would like to discuss a misconfiguration on their end. Thanks! -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with identifying invalid email domains

On 26 May 2022, at 6:18, Ken O'Driscoll via mailop wrote: > People should be validating email input fields as a matter of course. And then, do it correctly. One of my pet peeves is finding out forms that still think that there is no such thing as a .click email address. Tends to work better

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

On 19 May 2022, at 12:29, Dave Crocker via mailop wrote: > oh. gosh. we've been wrong about this. for 20 years. Would you care to enlighten me on how the DNC "technological requirements" differ from the hypothetical "DNE" list we have been discussing, and in particular, pertaining to the

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

On 19 May 2022, at 10:11, Dave Crocker via mailop wrote: > Telephone-level DNC is a different category of technological requirement. > Very different. In this case, not really. As implemented in practice, you have to run your list of phone numbers through a filter that will remove matching

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

On 19 May 2022, at 9:41, Dave Crocker via mailop wrote: > So, sure. We haven't been able to do individual-level blocking, so let's add > a requirement for an additional bit of complexity. That will probably make > this mechanism work a lot better... Heh, appreciate the humor. It certainly

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

On 19 May 2022, at 8:42, Dave Crocker via mailop wrote: > [⋯] Domain level is not sufficient. But is it though? A corporate providing email to its own users should certainly be able to express a policy that it does not want to allow any form of mailing list email to its users. Best regards

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

On 17 May 2022, at 21:59, Dave Crocker via mailop wrote: > I keep enjoying that it has the style of satire, but is so well done is it > /extremely/ useful for legitimate use. I wonder if this one ( ) Public reluctance to accept weird new forms of money should be complemented with a crypto

Re: [mailop] forwarding to gmail - problem

On 6 May 2022, at 3:48, Dan Mahoney via mailop wrote: > If you’re already doing DKIM and SPF anyway, arc is another milter in the > chain that gives you that benefit. (You want it after your DKIM and DMARC > validators). You can leverage your same DKIM keys to use arc (or a different > one),

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

On 26 Apr 2022, at 13:18, Robert L Mathews via mailop wrote: > 4\. Postfix wraps the message at 998 bytes when forwarding it due to > <[https://www.postfix.org/postconf.5.html#smtp\_line\_length\_limit](https://www.postfix.org/postconf.5.html#smtp_line_length_limit)\>; > > 5\. This breaks the

Re: [mailop] [E] $GOOG

On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote: Until Google manages to shut down outfits like MailShake and Woodpecker and Gmass, instead of turning a blind eye to it, Google will never get a handle on the abuse that goes through the Gmail API, in fact it feels as if they are

Re: [mailop] Odd delay at Gmail ?

On 20 Apr 2022, at 13:06, Bill Cole via mailop wrote: > When I looked at this phenomenon I didn't see any clumping of delay times, > but I only had a few dozen with delays 10m-10h so they were pretty sparsely > scattered. Matches me—few and apart—observations. -lem

Re: [mailop] Odd delay at Gmail ?

On 20 Apr 2022, at 12:35, Cyril - ImprovMX via mailop wrote: > That idea also crossed my mind, that it would only be displayed when the > actual time is > than the Date in the email. > Unfortunately, that's something I cannot tell, I don't know and since it is > occurring rarely, it's hard to ask

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

On 19 Apr 2022, at 11:02, Russell Clemings via mailop wrote: > Several users have reported this and I've seen it myself with a couple of > messages to my gmail from my website. Still troubleshooting, and it's not > happening consistently, but a missing DKIM in "show original" seems to be > the

Re: [mailop] [External] FYI - Google/Gmail hard enforcing SPF presence

On 19 Apr 2022, at 10:54, Kevin A. McGrail via mailop wrote: > Interesting note that we also saw this a few weeks ago too and had to add > DKIM to get mail to work to domains that only had SPF. Same here. Best regards -lem ___ mailop mailing list

Re: [mailop] [E] $GOOG

On 15 Apr 2022, at 12:50, Jaroslaw Rafa via mailop wrote: Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze: "EU.org, free domain names since 1996” You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any email service and never did. So how can they "police

Re: [mailop] [E] $GOOG - IPv6 aside

On 15 Apr 2022, at 12:02, Al Iverson via mailop wrote: > On Fri, Apr 15, 2022 at 10:36 AM Grant Taylor via mailop > wrote: >> >> On 4/15/22 8:24 AM, Al Iverson via mailop wrote: >>> Don't send to Gmail over IPv6. >> >> Drive by comment. >> >> It is possible to send to Google via IPv6. My

Re: [mailop] Best mailbox provider for personal domain?

On 8 Apr 2022, at 12:24, Michael Peddemors via mailop wrote: > FYI, I would NOT be recommending Digital Ocean for email servers.. given > their current reputation. However, you can find many good hosting companies > that offer a server for $5/month. The reputation of the neighborhood changes

Re: [mailop] Best mailbox provider for personal domain?

On 8 Apr 2022, at 9:40, Tara Natanson via mailop wrote: > Where would you recommend hosting your domain so that you can pop/imap, use > "+" addressing, isn't spammer friendly, and basically works similar to > gmail? I no longer have a website setup, so mail is the only thing I care > about. I'm

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

On 31 Mar 2022, at 10:57, Suresh Ramasubramanian wrote: > How would you correlate it to Russia? Time frames and a limited sampling of messages that mentioned topics related to the incident. -lem ___ mailop mailing list mailop@mailop.org

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

On 30 Mar 2022, at 11:03, Marcel Becker via mailop wrote: > On Wed, Mar 30, 2022 at 7:29 AM Luis E. Muñoz via mailop > wrote: > >> >> I am looking at some data showing substantial email traffic increase (2x >> baseline) along with a visible change in the spam filter

[mailop] Traffic patterns related to Russian-Ukranian conflict

Dear colleagues, I am looking at some data showing substantial email traffic increase (2x baseline) along with a visible change in the spam filtering statistics, centered at or near 2022-02-28. Are you guys aware of any publicly available source that would be discussing a similar observation?

Re: [mailop] sorbs DNS problems

On 11 Mar 2022, at 19:09, Noel Butler via mailop wrote: > Firslty yes, seen too many issues with SORBS, we removed them about 3 weeks > ago, the problems have been ongoing for months. Just wrapping up a trial with them for a traffic sample. We saw no issues in processing north of 300 million

[mailop] Paging SaskTel

Hi there, Could someone provide a pointer to SaskTel postmasters or network security folks? Thanks! -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Info on deluxe.com

On 28 Feb 2022, at 10:06, Laura Atkins via mailop wrote: >> That is a very good guess, but not in this case. > > It strikes me this is really a question you should be asking the bank. It’s > very likely that the bank did pass the address along, for whatever reason, > but they are the only group

Re: [mailop] [External] Info on deluxe.com

On 27 Feb 2022, at 21:43, Kevin A. McGrail via mailop wrote: >> I just received my first ever spam from |info.deluxe.com|, sent to a tagged >> address used exclusively for online banking. Does anyone have a contact at >> deluxe so that inquiries can be sent? > > Lem: Any chance you use that

Re: [mailop] Info on deluxe.com

On 25 Feb 2022, at 16:05, John Levine via mailop wrote: > That's not to say I would want them to send me spam, but it doesn't > seem very mysterious. Indeed. My first quick glance of their website missed that fact. However we are meticulous in ensuring that all preferences for data sharing are

[mailop] Info on deluxe.com

Hi there, I just received my first ever spam from `info.deluxe.com`, sent to a tagged address used exclusively for online banking. Does anyone have a contact at deluxe so that inquiries can be sent? Thanks! -lem ___ mailop mailing list

Re: [mailop] Can someone from Vade get in touch?

On 8 Dec 2021, at 4:03, Stephane Decamps via mailop wrote: > The review of our tools verdicts can be requested by the "owner" of the > concerned IPs via SenderTool: https://sendertool.vadesecure.com > > But I see that we received a request there from one of your colleagues > yesterday, who

[mailop] Can someone from Vade get in touch?

I would like to review some listings and revise some registrations that look bogus. Thanks! -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] Postfix / DNSblog Query Problems with various RBLs running in timeouts

The only part of your setup that looks strange (to me) is the use of systemd-resolve. On 3 Dec 2021, at 6:55, Glowfish Domainadministrator via mailop wrote: > netstat -tulpn |grep 53 > > tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 586/systemd-resolve > udp 0 0 127.0.0.53:53 0.0.0.0:*

Re: [mailop] New Tucows / OpenSRS Hosted Email outbound IP addresses

On 23 Nov 2021, at 19:17, Michael Peddemors via mailop wrote: Oh, and forgot to mention.. Might consider SWIP or 'rwhois' entries to show these networks are for Tucows email servers, and not part of the other networks that may have different use cases.. eg. NetRange: 64.98.0.0 -

[mailop] New Tucows / OpenSRS Hosted Email outbound IP addresses

Tucows / OpenSRS is executing an upgrade that will result in new SMTP outbound IP addresses being used within the next couple weeks. * All outbound email for regular and "filter-only" delivery: 64.98.42.0/24 64.99.140.1/24 216.40.44.0/24 * All outbound forward and autoresponder

[mailop] Does someone have a postmaster contact for smtp.wi.gov / wisconsin.gov

I'm trying to troubleshoot what appears like a packet filtering issue. Pointers appreciated. -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

[mailop] Someone from Suddenlink / Synchronoss / Altice

Hi there, Can someone provide a pointer to the folks in charge of Suddenlink email? I would like to troubleshoot a delivery issue with them and have ran out of ideas on how to contact. Someone mentioned earlier Synchronoss and Altice as potential operators of their mail infrastructure, but

Re: [mailop] Why TLS is better without STARTTLS

On 10 Aug 2021, at 11:21, Alessandro Vesely via mailop wrote: SASL methods allow secure authentication over unencrypted channels. (Well, I use CRAM-MD5 even over TLS. When heartbleed came around I thought it wasn't that silly after all.) FSVO secure, IIRC. Having to keep the unencrypted

[mailop] HIPAA compliant email (was Re: So uh... Zoom/Sendgrid... How's that webinar spam investigation coming?)

On 5 Aug 2021, at 10:26, yuv via mailop wrote: If anyone can suggest an email relay system that is compliant with US HIPAA , I would love to connect my internal email system to it and outsource email deliverability problems. Out of curiosity, and

[mailop] Anybody around from chegg.com / Adobe

Hi there, Would like to try and troubleshoot greylisting issue related to email sent on behalf of chegg.com. Please ping me offlist. Best regards -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS issues

On 14 May 2021, at 21:53, Eric Germann via mailop wrote: For the STARTTLS cert I’m using LetsEncrypt. DANE is also in place. The TLS certificate checker at https://esmtp.email/tools/tls/ returns a Sectigo certificate which otherwise matches mail.semperen.com and www.mail.semperen.com on

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

On 5 Feb 2021, at 7:25, Michael Orlitzky via mailop wrote: > Pay more and more people to do it, until the number of unhandled abuse > reports at the end of the day is zero. It scales linearly. Here's where I stopped reading. It does not scale linearly. -lem

Re: [mailop] Anyone using clustered DoveCot?

On 28 Jan 2021, at 2:40, Dr. Christopher Kunz via mailop wrote: Maybe someone has some additional pointers what to look at? You mention that the issues happen infrequently, so pinpointing the actual cause might be tricky. I am assuming an NTP synchronized server pool with multiple Dovecot

Re: [mailop] Anyone using clustered DoveCot?

On 24 Jan 2021, at 12:07, Michael Peddemors via mailop wrote: +1 Customers using NFS is perfectly fine, and scales well. But do yourself a favour.. not all storage appliances are the same. Go NetApp (amazing how reasonable cost you can get them now) if you can. Seen it too many times where

Re: [mailop] Current OSS anti-spam software best practice?

On 16 Dec 2020, at 3:03, André Peters via mailop wrote: Indeed, Rspamd changes everything. Just another +1 from me. Definitely enable DCC as well. Huge game changer for some of our flows. We're also using it for DKIM (signing and validating). -lem

Re: [mailop] Week+ delays within btinternet,com / synchronoss.net

On 20 Oct 2020, at 23:55, Andy Smith via mailop wrote: > Their mail server is at 85.119.83.252 (and 2001:ba8:1f1:f073::2, but > none of the eventual deliveries happen over IPv6). Are they getting any email over IPv6 at all? Best regards -lem ___

Re: [mailop] [EXTERNAL] What's Microsoft's S3150 block list and where do I go to request removal?

On 9 Sep 2020, at 11:29, Atro Tossavainen via mailop wrote: > (Some time ago I might have added "and isn't even based on x86" to the > bit about running windows apps. Maybe I'll go back to that and run Mutt > on ARM instead. Wonder how much it would cost to host an army of Pi at > a commercial

Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best Practices

On 4 Sep 2020, at 7:00, Laura Atkins via mailop wrote: You’re trying to send mail from an Amazon compute server sitting in the middle of a range of IPs that have the generic aws rDNS.You’re being blocked because you’re sending from a place many, many people don’t want mail from. You need

Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best Practices

On 3 Sep 2020, at 12:02, L. Mark Stone via mailop wrote: If anyone has a better process for warming up sending MTA IPs, I would be grateful. This has been in use for a few years with great success. Numbers will need adjustment to your specific case.

Re: [mailop] Google and Spam detection

On 24 Jul 2020, at 19:07, John Levine via mailop wrote: Gmail has repeatedly said that they do not accept unauthenticated mail on IPv6. And with very good reason. Consider that you can very easily have a dedicated IP address for every email message you will ever send :-) Best regards

Re: [mailop] Google and Spam detection

I would push DANE a bit up in the list. DNSSEC can be a drag to some, but it is really the way to go in terms of decentralization of encryption. It is also a good practice. On 24 Jul 2020, at 12:40, Phil Pennock via mailop wrote: * MTA-STS webserver with HTTPS from the same CA, and the

Re: [mailop] Google and Spam detection

On 24 Jul 2020, at 7:48, Jaroslaw Rafa via mailop wrote: Not true, I was (and am) always delivering mail via IPv4 and had mentioned problems (and also other people whose complaints I have read don't use IPv6 as well). I see no difference in IPv4 vs IPv6. You do need to have rDNS properly

Re: [mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup Failed (TT513)

On 18 Jul 2020, at 7:12, Stefan Bauer via mailop wrote: No. Recipient is valid. Unknown recipients should be a perament error. I am seeing what seems to be user lookup issues on their end from a few servers. Specifically Server Too Busy (TT101) Recipient Lookup Failed (TT513) I have a

Re: [mailop] Is there a contact for ono.com

On 15 Jul 2020, at 14:07, Atro Tossavainen via mailop wrote: > 2) Deliberate DROP-style firewalling of your ranges and mine too > > Since https://www.ono.com/ is equally unaccessible from my domestic > Internet connection (also in Finland), I'd say #1 sounds more likely > to me. Add my nodes

Re: [mailop] Rolling DKIM Key Disclosure

On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote: Replies inline. On 7/10/20 7:50 PM, Brian Toresdahl wrote: Your approach and goals don't seem to make sense to me. TL;DR: The customer is always right, and the customer sees DKIM being used regularly to authenticate leaked emails -

Re: [mailop] Intermittent slow email delivery

On 10 Jul 2020, at 14:36, Job Cacka via mailop wrote: There is PAT firewall that load balances multiple networks. Hopefully not a descendant of a PIX. I've never have had happy stories involving [NP]AT and SMTP servers. I tend to go with what others have said: The fw might be trying to

Re: [mailop] Intermittent slow email delivery

On 10 Jul 2020, at 9:47, Adam D. Barratt via mailop wrote: On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote: slowmailtest...@ccbox.com slowmailtest...@ccbox.com slowmailtest...@p-r-c.com slowmailtest...@p-r-c.com From a quick test, at least half of connections get immediately

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

On 8 Jul 2020, at 22:36, Stefan Bauer via mailop wrote: there is a feature in O365 that forwards mails (in/out/both..) to an archive-mailbox for long-term archiving. We grab this mails via pop. However our available mail-readers (Thunderbird, Kopano) show the original mail as attachment.

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

On 29 Jun 2020, at 14:11, Scott Mutter via mailop wrote: Microsoft has not provided any evidence that anything bad has ever come from this IP address. (Which the pros/cons of disclosing this have already been discussed) I don't think that in the current state of affairs, they *have* to

Re: [mailop] t-online.de outage?

On 9 Jun 2020, at 9:13, Michael Peddemors via mailop wrote: Hehehe.. testing from a Digital Ocean IP might NOT be the best .. You would be surprised. Maybe they using GEO IP blocking UNLESS on an internal whitelist? Usually only see that on IPv6 ports, but maybe that is what we are

Re: [mailop] t-online.de outage?

On 9 Jun 2020, at 8:40, Jon Morby (Fido) via mailop wrote: The forward and reverse on our mail servers matches one of my test boxes (on my home network) was new and didn’t have matching reverse, but that the other machines I’ve tried from all have matching forward/reverse and they’re

Re: [mailop] [EXTERNAL] Re: Force double opt in for marketing list companies per email address

On 2 Jun 2020, at 14:25, Michael Peddemors via mailop wrote: Yeah, and IMHO (don't hit me) that VERP should go the way of the Dodo.. This assertion doesn't follow the rest of your message. Even if useless for the use case being discussed – for which it was never meant as a solution – 

Re: [mailop] contact at google

On 17 Apr 2020, at 15:20, Al Iverson via mailop wrote: If you're going to copy what he does just block 0/0, it's faster. :\ And cheaper! :-) Not my intention at all. But the collection of network ranges would be useful to me in trying to understand how a large collection of distributed

Re: [mailop] contact at google

Wow, tried twice to email you directly w no luck - The following addresses had permanent fatal errors - (reason: 550 5.7.1 : Client host rejected: Get a real domain, spammy) Oh well, thank you anyway. -lem On 17 Apr 2020, at 12:31, Bill Cole via mailop wrote: On 17 Apr

Re: [mailop] Yahoo/AOL slower than normal delivery

Hi Michael, On 11 Apr 2020, at 6:36, Michael E. Weisel via mailop wrote: We’ve noticed over the last 36 hours or so slower than normal delivery to Yahoo and AOL. Our numbers for the last 48 hours look normal. Best regards -lem ___ mailop

Re: [mailop] Abusix Potentially Compromised Account Report

On 21 Mar 2020, at 21:11, Ted Cooper via mailop wrote: Has anyone run into "Abusix" /potentially/ compromised account notification emails before? I got three in the last 48 hours at different sites. All referenced real user accounts – no clue about the password. The warning seemed legit

Re: [mailop] AT Block - abuse_...@abuse-att.net still valid?

On 26 Feb 2020, at 14:18, Scott Mutter via mailop wrote: [⋯] Do any DNS resolvers actually cache data for the period stated in the TTL these days? Many do. If you're operating a recursive for any sizable user population, you want to minimize the response time. Having the response in your

Re: [mailop] AT Block - abuse_...@abuse-att.net still valid?

On 26 Feb 2020, at 13:53, Lyle Giese via mailop wrote: Don't know if ATT looks at this but I know they used to.  The TTL for the A record for server.divebums.com is 900 seconds.  If checking this parameter, it was recommended that this be at least 12 hrs or 43,200 seconds.  The theory was

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

On 25 Feb 2020, at 3:12, Simon Lyall via mailop wrote: Thank you for all the suggestions. I've put together a couple of pages: https://www.mailop.org/faq/ https://www.mailop.org/best-practices/ as a start. What do people think needs to be added or changed? This is a TLS Checker that is

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

On 17 Feb 2020, at 11:20, Hans-Martin Mosner via mailop wrote: My personal experience with SPF is that it is less helpful than harmful, at least when mail server operators use it for rejection instead of tagging. It can help reject some mails with fake sender information, but at the same

Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

On 10 Feb 2020, at 20:27, Michael Rathbun via mailop wrote: The data: FWIW, I'm seeing these IPs among the 40th percentile in terms of global SMTP activity / session attempts. 3.18.213.86 54.186.253.233 54.212.82.49 The rest is not registering. Best regards -lem

Re: [mailop] How long to retry?

On 4 Feb 2020, at 11:43, Brandon Long via mailop wrote: The problem is, user's get used to the performance they get. It's not a question of user education or worse users. If you typically deliver messages in seconds, eventually that's what they expect. Great summary! And, there are

Re: [mailop] How long to retry?

On 3 Feb 2020, at 14:20, Michael Orlitzky via mailop wrote: You have problems with 100% of messages 0.0001% of the time -- it's not a steady 99. success rate, even though that's what the numbers look like if your window is five-years long. Since recently – heh, let's call it 5-6 years

Re: [mailop] How long to retry?

On 3 Feb 2020, at 14:04, Brandon Long via mailop wrote: One of the main reasons I don't think we should use such long retries is that it violates user expectations. Users often treat email as nearly instantaneous, because it normally is... so taking hours or days of actually failing without

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

On 26 Jan 2020, at 16:23, Ángel via mailop wrote: I like them as 2FA solution, too. Simple, standard, offline, vendor neutral, not vulnerable to MITM... Ahem. If the attacker manages to position themself in between your session, they get a chance at your TOTP. Same attack scenario as with

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

On 24 Jan 2020, at 3:33, Laura Atkins via mailop wrote: Using +all is actually a giant, negative reputation hit according to various folks I’ve talked to about filters. Using +all says “every IP is valid” and this was (dunno about still is but definitely was) used by spammers so they could

Re: [mailop] BT Internet postmaster contact

On 3 Jan 2020, at 20:46, Philip Paeps via mailop wrote: I've found BT's postmaster team to be very responsive in the past. I invariably get replies from actual humans. I suppose YMMV. I've interacted twice with them in the last 24 months on behalf of clients. The interaction has been...

Re: [mailop] G-Suite removing LSA functionality

On 16 Dec 2019, at 13:30, Jaroslaw Rafa via mailop wrote: Do any Windows/Linux/MacOS email clients currently support OAuth "out of the box"? I can report that MailMate on MacOS works perfectly with OAuth. And it's also much better for email geeks. Not free, but well worth the license.

Re: [mailop] G-Suite removing LSA functionality

On 16 Dec 2019, at 11:20, Al Iverson via mailop wrote: Question for the group -- [⋯] Are there other folks out there that will have to make code changes to comply with these changes? I will have to make code changes to more or less the same classes of tools you mentioned. Best regards

Re: [mailop] Reasons to add plain text alternative to email?

On 9 Dec 2019, at 7:58, Al Iverson via mailop wrote: Whenever these threads come up, a dozen or so people say "I still read email on my stone tablet and so do all my friends." But count how many friends do you have, and then divide that by the 1.5 billion active Gmail users (as of October

Re: [mailop] Reasons to add plain text alternative to email?

On 9 Dec 2019, at 6:23, Ned Freed via mailop wrote: Generate the plain text alternative if you can. Absolutely. But please, try hard. But if you can't, or aren't sure you can, just send the HTML and don't generate the multipart/alternative structure. +1 Best regards -lem

Re: [mailop] Can someone write me a prescription for a sane MTA? I'm allergic to Postfix.

On 6 Dec 2019, at 9:17, John Levine via mailop wrote: > I'd be interested in why he's still using uucp. +1 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Suggestions for VPS providers in Europe?

On 2 Dec 2019, at 15:59, John Levine via mailop wrote: I warned a guy away from Hetzner and OVH if he wants to send mail so he reasonably asked what VPS provider in Europe is better for sending mail. Any suggestions? I'm AWS (IPv4 and IPv6) with good results. I would go with AWS for

Re: [mailop] Best strategy to prune address list

On 23 Nov 2019, at 11:05, Tom Ivar Helbekkmo via mailop wrote: > Today, I suspect that most MTAs > will refuse to service a VRFY request. > > Anyone know if that assumption is good? I would be very surprised if you were wrong. -lem ___ mailop

Re: [mailop] Mailop made Hacker News

Looking forward to the n-gate.com summary :-) And the comments on Brandon about him being helpful and respectful are well deserved. -lem On 25 Oct 2019, at 12:40, Simon Lyall via mailop wrote: Remember that "Gmail marking email from me as spam" thread a couple of weeks ago? Somebody

Re: [mailop] Do we need Spam folders?

On 14 Oct 2019, at 23:39, Thomas Walter via mailop wrote: On 15.10.19 00:34, Chris Wedgwood via mailop wrote: Doesn't "550 Requested action not taken: We don't like you." apply after DATA? it does most severs honor this but not all (i experience this sometimes, my domain somtimes gets a

Re: [mailop] Do we need Spam folders?

On 14 Oct 2019, at 15:18, Thomas Walter via mailop wrote: On 14.10.19 23:59, Luis E. Muñoz via mailop wrote: This is not a pure performance issue. It's more a matter of not having the data at hand to decide whether the message is ham or spam. To do so, filters need user feedback. You can

Re: [mailop] Do we need Spam folders?

On 14 Oct 2019, at 14:20, Thomas Walter via mailop wrote: Of course I don't have the experience in the last category, but I'd like to learn. Why can't you reject emails post-DATA? Is it a performance issue? Google or Bing find 935.000.000 search results in 0,60 seconds for the word "spam",

Re: [mailop] Do we need Spam folders?

On 14 Oct 2019, at 13:43, Thomas Walter via mailop wrote: Why not reject those instead and have the sender deal with it? Because filter error rates and the need for the feedback signal from the recipient. -lem ___ mailop mailing list

Re: [mailop] Do we need Spam folders?

On 14 Oct 2019, at 11:57, Michael Wise via mailop wrote: Having the mail bounce at the edge is a VERY useful signal for any spammers trying to enhance their deliverability. It's a great signal for anybody caring for the fate of a message. This is why we cannot have nice things :-) -lem

  1   2   >