[mailop] DNSBL:RBL 521 errors with AT

Last Friday, all our mail servers started getting this error when sending to any addresses @att.net, @sbcglobal.net, etc.: 553 5.3.0 flpd576 DNSBL:RBL 521< 208.80.4.152 >_is_blocked.For assistance forward this error to abuse_...@abuse-att.net I've written to the abuse_...@abuse-att.net address

Re: [mailop] SpamHaus listings

On Mar 22, 2024, at 10:58 AM, Matus UHLAR - fantomas via mailop wrote: > the result code and the spamhaus search didn't provide any relevant info. Hmmm. Not relevant to you, perhaps, but it may be relevant to someone else who can help. I can't imagine how anyone could begin helping you

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

On Feb 15, 2024, at 6:13 PM, Dave Crocker via mailop wrote: > Not using COI, as well as hitting spamtraps are both solid, affirmative > indications of spam. Full stop. Interesting, thanks. I find I disagree with the "full stop" part, but it seems I'm in the minority. Don't get me wrong --

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

On Feb 15, 2024, at 1:10 AM, Riccardo Alfieri via mailop wrote: > That is exactly the root cause in this case. That .org address hit a bunch of > typotraps, with different typoed domains, not recycled ones. That shows lack > of COI from the library. From the robots POV the behaviour is not

[mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

I find myself having a difference of opinion with Spamhaus about a certain type of RBL listing, and I'm wondering what others think. The situation is that the Reply-To email address of a public library's "your book is due in five days" reminder system is listed in the Spamhaus HBL

[mailop] AOL/Yahoo: Confusing enhanced SMTP codes in response?

I see occasional bounces from AOL/Yahoo that look like this: 554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes However, the "554 5.7.9" doesn't make sense to me. The "554" part is "Transaction failed" (RFC 5321), which is fair enough (although

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

On Jan 12, 2024, at 3:52 PM, Jaroslaw Rafa via mailop wrote: > As I have shown above, for BIMI to be useful, it *has* to be the *only* > specification for having such logos appear, and no other options could be > possible. Yes, this is exactly right. If an MUA displays a "sender's logo" like

Re: [mailop] Email deliverability issues to Outlook

On Nov 30, 2023, at 7:47 PM, Angelo Giuffrida via mailop wrote: > > the only reference to the server is in the email header This is unclear, to me at least. Which header? Is it being used as the envelope sender MAIL FROM domain name? If you used real domain names and gave copy-and-paste

Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?

On Oct 28, 2023, at 9:27 AM, pgnd via mailop wrote: > > again, this is _assuming_ that that anomalous 'dkim=neutral (no key)' report > *is* what's causing the misclassification as SPAM in gmail ... which i can't > (dis)prove yet. When you view a message in the Gmail spam folder, it has a

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

On 7/13/23 11:12 AM, Jarland Donnell via mailop wrote: Perhaps it's going off topic and apologies if so, but this makes me wonder a second thing. Who is, and why are they, adding subdomains to the PSL when subdomains above that in hierarchy are in the same zone file? Some domains that offer

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

On 7/13/23 10:44 AM, Jaroslaw Rafa via mailop wrote: If .tld is on PSL, then example.tld will be the organizational domain. And it definitely should have its own zone file, so it should have SOA. I can't imagine a scenario in which it doesn't. An example is something like

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

On 7/12/23 9:42 PM, Felix Fontein via mailop wrote: right now there is only a SOA record for `us.` itself and for `ci.westfir.or.us.`, but for nothing inbetween. Ugh, you're right, the customer has removed the delegation of westfir.or.us (I was testing on internal servers that still showed

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

On 7/12/23 4:22 PM, Andy Smith via mailop wrote: We last had this thread back in may Yikes; not sure how I missed that. Thanks for the pointer. the conclusions at that time were: [...] > - It only affects domains on the Public Suffix List. i.e. the sender domain is in some public

[mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

Today I had a customer complain that mail they send to AOL or Yahoo addresses was being returned with: 451 Message temporarily deferred due to unresolvable RFC.5321 from domain; see https://postmaster.yahooinc.com/error-codes According to that page, "- These errors indicate that the domain

[mailop] Noticed Google now suggests changing envelope sender for forwarding

Maybe other people have noticed and discussed this and I'm just behind the times, but for more than a decade, Google specifically said: "Avoid changing the envelope sender when forwarding email to Gmail." (You can see this as recently as last November at

Re: [mailop] DKIM record IONOS

On 2/9/23 4:41 PM, H via mailop wrote: > Having successfully created a SPF record for my domain hosted by > Ionos, I now wanted to create a DKIM record but have received two > completely different answers from Ionos. > > The first instruction I received was to create a CNAME record The reason

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

On 7/22/22 8:49 AM, Laura Atkins via mailop wrote: That’s normal practice as far as I’m aware. If an address bounces the ESP prevents the sender from mailing to it in the future. There are some ESPs that don’t (and they know how I feel about their practices). I’ve also heard complaints from

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

On 7/18/22 4:45 PM, Brandon Long via mailop wrote: Are they using Windows Mail to send mail through your service via message submission? Adding a message-id header is a SHOULD in that case: https://datatracker.ietf.org/doc/html/rfc6409#page-14 If you're just forwarding, then yes, it's

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

On 7/13/22 12:31 AM, Philip Paeps via mailop wrote: In the past couple of days, I'm seeing an uptick in rejects from Gmail as follows: >Our system has detected that this message is not RFC 5322 compliant. Similar to this, some our customers complained that messages sent to Gmail have been

Re: [mailop] forwarding to gmail - problem

On 4/28/22 8:53 PM, Ángel via mailop wrote: Seeing it here as well. Something has recently changed in gmail again, just like last December. Yes, this problem has vastly increased. We're seeing complaints due to this several times a week now, whereas before it was maybe once a month. Brandon

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

On 4/27/22 6:30 AM, Michael Kliewe via mailop wrote: Exactly. The best and easiest solution is to contact the sender and tell them to fix the problem, by either using "relaxed/relaxed" or by reducing the line length to <=998 bytes. Just so it's clear, this is unrelated to simple or relaxed

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

On 4/26/22 11:40 AM, Luis E. Muñoz via mailop wrote: > As others indubitably will recommend, don't do that. You are not > the ESMTP police:-) I tend to agree, although it's interesting that this setting is the Postfix default. I suppose the argument in favor of it is that some other places

[mailop] SMTP line wrapping breaking DKIM signatures when forwarding

We've recently been getting more complaints about seemingly valid messages that are rejected when we forward them. Tracking down the problem, it happens when: 1. The message that we receive from a third party has line lengths that exceed 998 bytes in violation of RFC 5322 2.1.1; 2. The

Re: [mailop] [E] $GOOG

On 4/22/22 11:00 AM, Anne Mitchell via mailop wrote: Woodpecker, at least, is somewhat up front about the fact that what they are doing is enabling their senders to violate Google's policies: A lot of these outfits aren't even trying to hide it any more, which is unfortunate because it risks

Re: [mailop] SendGrid, what happens when you don't address the root problem (Indeed Phishing)

On 4/19/22 1:46 PM, Atro Tossavainen via mailop wrote: They're definitely the biggest ESP in our spamtraps, have been for more than a year solid. Yep. As most probably remember, someone from SendGrid came on the list for a while, made some noises about cleaning things up, and then

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

On 12/16/21 7:59 AM, Al Iverson via mailop wrote: Well, I'm sure this'll be a popular opinion, but I'm giving it anyway. Maybe let's try not to do something that'll screw up that college kid's life forever over their bit of stupidity. It's wrong, they shouldn't be doing it, but it's not for

Re: [mailop] How to detect fraud login in POP IMAP or SMTP?

On 9/23/21 9:42 AM, Jay Hennigan via mailop wrote: > While you do this, also tell them to ignore phishing emails that claim > to be from their provider warning that their email account is at risk. A lot of this now seems like just poor user interface. Email software authors (and many of us,

Re: [mailop] GMail 550 5.1.1?

On 12/19/20 9:27 AM, Sam Tuke via mailop wrote: > That's nice to know, but the fact is that messages accepted by Gmail > sometimes disappear without a trace. In my experience of investigating a few of these in detail, this is not actually the case. Instead, what happens is that the Gmail

Re: [mailop] opendkim bad signature data from mx.mailop.org

On 11/6/20 8:05 AM, Mary via mailop wrote: > Here is my opendkim configuration (/etc/opendkim.conf): > ... > On-BadSignature reject Aside from anything else, you shouldn't do this. It violates the rule at the bottom of RFC 6376, section 6.3: If the email cannot be verified, then it

[mailop] Lashback UBL (unsubscore.com) not working?

We use the Lashback UBL described at as a (small part of) scoring incoming mail. The actual list domain name is "unsubscore.com". About 10 days ago I noticed that the timestamps on their rsyncable files stopped updating. I contacted them about this but got no

Re: [mailop] BIMI pilot @ Google

On 7/25/20 1:52 AM, Christian de Larrinaga via mailop wrote: > My question is is it useful? Yes, absolutely. If it's a security-sensitive message, like one from my bank, it's useful for my mail client to show that it was really sent by (DKIM signed by) them to increase my trust in it. My bank

Re: [mailop] BIMI pilot @ Google

On 7/24/20 2:51 AM, Christian de Larrinaga via mailop wrote: > All emails on this list are showing with red DKIM signed boxes That's because this list alters the message From header and body without re-signing it. (If the list re-signed outgoing Mailman messages with a "mailop.org" DKIM

Re: [mailop] Sendgrid and phishing

On 6/17/20 10:22 AM, Carl Byington via mailop wrote: > In the last 24 hours: Yeah, I see phishing attempts that we rejected for DMARC failures like: Received: from microsoft.com (unknown) by ismtpd0004p1lon1.sendgrid.net (SG) with ESMTP id PP-Z30gTRGS8qMv1NXRDhA for ; Tue, 16 Jun 2020

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

On 6/4/20 9:10 AM, Laura Atkins via mailop wrote: > What is your mechanism for that trust? If the answer is “someone will > figure it out” then there’s no point in even suggesting such a header. Well, I would disagree with that, actually. Much of this is automated on the recipient end at large

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

On 6/4/20 2:50 AM, Laura Atkins via mailop wrote: > You do know that spammers run ESPs and consider themselves reputable, > yes? How useful will the header be when they start putting it in even > when the mail isn’t confirmed?  My point was that if a large ESP started doing this, *and* the ESP

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

On 6/3/20 10:46 AM, Jay Hennigan via mailop wrote: > One problem is that spammers lie. If someone comes to an ESP and claims > that their list is 100% COI, the ESP either has to trust them or the ESP > needs to reconfirm. Right; in such a case, I would expect the ESP to *not* mark it as confirmed

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

On 6/2/20 6:35 AM, Tim Bray via mailop wrote: > Is there way I could force my email address to be double opt in? > Like register with you, confirm my address, and then any of your > customers who try to add me, I get a `please confirm` email. If large ESPs who consider themselves reputable

Re: [mailop] Outlook autodiscover IMAP server settings

On 6/2/20 5:16 AM, Andrew via mailop wrote: > tl;dr - start with ensuring you've got RFC 6186 records setup Out of interest, do you know what clients now support RFC 6186? I tested a variety of them a couple of years back and couldn't find any major ones that supported it, so I didn't bother

[mailop] outlook.com duplicate emails with "MailboxResubmission" in headers?

One of our customers says that every message they've sent in the last few days to multiple independent people who use outlook.com suddenly got a second copy redelivered today. We were able to get a copy of the headers from one of those redeliveries, and those headers begin with this (rewrapped so

Re: [mailop] HaveIBeenPwned Was: Abusix Potentially Compromised Account Report

On 3/27/20 1:27 AM, Larry M. Smith via mailop wrote: > .. I see _no_ value in the millions of hashes (over 196M) that appear to > have only ever been exposed once. No one is going to load up and > attempt a dictionary attack of those used-only-once hashes. It sure as > heck doesn't mean a thing

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

On 2/26/20 5:22 AM, Luke via mailop wrote: > > They also have no process in place for verifying From addresses. With > their API, you can put whatever you want in the From field. Clearly not > ideal, but they arent unique in this regard. All in all, considering the > amount of email SendGrid