Re: [mailop] Good registrar?
On Wed, 2024-10-02 at 13:37 +0300, Otto J. Makela via mailop wrote: > It seems Gandi has been hiking their prices rather significantly. > > Do you have recommendations for a good domain registrar which still > keeps prices at a reasonable level, and also isn't a problematic > spammer/scammer haven? https://www.simpleurl.com/ works with noscript enabled, what more could you ask for? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI
On 2024-08-09 15:11:45, Brotman, Alex via mailop wrote: > Yes, it should be updated. > > It might also be worth trying to get a bug filed against opendkim to update > docs or comments in the sample configuration file that is provided in the > package to illustrate suggested practices. > > (FWIW, lists.debian.org still doesn't sign anything they send) The OpenDKIM project is dead, but the sample configuration file does already mention this. The "full" sample config file says, > This has security implications; see opendkim.conf(5) for details. and then that man page says, > This feature of the protocol exists to improve the likelihood that a > signature will survive transit through a mailing list server, as > they commonly append footers to messages. Note, however, that this > creates a potential security issue since someone could add arbitrary > text to the signed message and the signature would still validate. > See the DKIM specification for details. (the other, simpler sample config files don't mention the body length option at all). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailserver software
On Tue, 2024-07-16 at 07:40 +0800, Jeff Pang via mailop wrote:
> Any experience on opensmtpd on debian?
Just use postfix. You lose the OpenBSD security dust when running on
Debian, and the last time OpenSMTPD had a remote (root) code execution
vulnerability we all learned that it delivers mail with
execle("/bin/sh", ...).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailserver software
On Mon, 2024-07-15 at 22:39 +0800, Jeff Pang via mailop wrote: > Hello > > When I deploy a new mailserver, I consider postfix, exim and qmail. > > From practical experience, what are the advantages, disadvantages, and > adaptation scenarios of postfix, exim, and qmail? > Forget qmail (and sendmail). Both postfix and exim are secure, have great documentation, and have great support. Both are portable and available everywhere, and they have equally-idiosyncratic build systems. The main difference is that exim has more batteries included, whereas postfix stays closer to the UNIX principle and delegates things like DKIM to an external daemon. Try both (in a real configuration) and see which one you prefer. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
On Wed, 2024-03-13 at 15:54 +0100, Marco Moock via mailop wrote: > Although, older SSL/TLS versions have some weaknesses and when they are > not offered, they can't be used, not even for downgrading attacks. Many > clients support an option to enforce TLS/STARTTLS. That will fail in > such a situation. Are there any scenarios where you can downgrade the protocol but not steal the entire message due to the server's identity being unverified? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
On Wed, 2024-03-13 at 11:28 +, L. Mark Stone via mailop wrote: > FWIW, our view is that poor encryption can be worse than no encryption, as it > can give the participants a false sense of security. This seems like a good > move to us. > > We have configured Postfix in our Zimbra MTA servers to do only TLS 1.2/1.3, > and fall back to unencrypted if a TLS connection can't be negotiated (per RFC > 2487). > Whose sense of security is improved by sending those messages in plaintext? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Verizon text to email on vtext.com - connection refused error
On Tue, 2024-01-02 at 17:32 +, Justin Krejci via mailop wrote: > When a Verizon mobile user sends a text to an email recipient, I understand > it goes through some mail gateway system that converts the message to a > standard email and I think uses the @vtext.com as the sending domain with > some composition of obfuscated user data before the domain. We are receiving > many reports of people getting "connection refused" errors when a Verizon > user is sending with this method; see below for error message. > > Is there anyone on the Verizon mail admin team we discuss/troubleshoot with > please? > > Our receiving SMTP server is definitely not refusing connections so either > tcp traffic is getting blocked before arriving to us or the wording of the > error message is not accurate. But without knowing what all the sending IP > addresses are for sure, it is difficult to even troubleshoot. We are > attempting to run a packet capture on the IP addresses listed in the SPF > record for vtext.com but that uses assumptions which may be incorrect. > Wild guess: a few weeks ago we were getting reports of missing SMS-to- email messages because the Verizon servers involved were blacklisted. If you have something like fail2ban running, maybe you're dropping them at the firewall for some kind of abuse? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail now deferring email which meets their published reqs
On Sat, 2023-12-30 at 12:48 -0800, Randolf Richardson, Postmaster via mailop wrote: > If that's what the problem is, then that can easily be set with the > following Postfix setting without the need for customization scripts: > > default_destination_recipient_limit = 1 > > It may also be helpful to adjust the delivery rate, which can also > be set in Postfix's "default_destination_rate_delay" setting This will work, but you probably don't want to make your entire MTA inefficient just to appease Google. Those two parameters have per- transport counterparts, * _destination_concurrency_limit * _destination_rate_delay where is the name of your transport. So, for example, you could create a transport called "slow", and then set * slow_destination_concurrency_limit = 1 * slow_destination_rate_delay = 2s after which all you have to do is configure postfix to send to gmail via the "slow" transport instead of the default one. Now gmail is slow, but nobody else suffers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail deferrals resolved by transit encryption
On Fri, 2023-11-17 at 23:33 +0100, Jaroslaw Rafa via mailop wrote: > Dnia 17.11.2023 o godz. 14:34:19 Lukas Tribus via mailop pisze: > > > > Google probably wants you to enable STARTTLS, so reducing sending > > limits for non STARTTLS senders can make sense from Google's POV. > > That thread makes me wonder, how come anybody is sending mail without > STARTTLS now? When all major MTAs do it just by default? If you're sending junk from a custom MTA, it avoids a lot of programming and saves a little CPU. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
On Fri, 2023-08-25 at 17:07 +, Slavko via mailop wrote: > Dňa 25. augusta 2023 16:01:42 UTC používateľ Michael Orlitzky via mailop > napísal: > > > In short: cheap implies bad but bad doesn't imply cheap. > > Yes, Windows is cheap. But Linux is even free, thus it must > be really, really bad... > Taking my comment out of context is both cheap and bad :) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
On Fri, 2023-08-25 at 09:34 +0200, Alessandro Vesely via mailop wrote: > > > > Well, yeah, sometimes you get what you pay for. > > > Hm... finding an expensive ISP is not a good business criterion. In short: cheap implies bad but bad doesn't imply cheap. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
On Thu, 2023-08-24 at 12:10 +0200, Jaroslaw Rafa via mailop wrote: > > Individual IP reputation - yes. > > Netblock reputation - no. Only if you know that the entire netblock belongs > to a spammer, it is justified to block the entire netblock. > > If it is just a random netblock of some ISP that just happens to contain > some spamming IPs (even a lot of them) inside - no, never block the netblock > as a whole. I know you're on OVH but it's hard to feel bad about this. Morally, the ISP (the owner of the netblock) is responsible for the spam. They have a responsibility to stop it. If they outright refuse to respond to abuse complaints, it's good and correct to punish them for that choice. Practically, whack-a-mole is infeasible. It takes me five to ten minutes to add a blacklist entry: I have to do the WHOIS lookup, PTR lookup, scan the neighborhood, see if that block is part of a larger block, document the spam, add the blacklist entry, write a commit message, push to the repo, and then push the configuration change live. It takes OVH less time than that to send me spam from a new IP address. There's an obvious solution to that problem and it isn't me doing their job for free, twenty four hours a day, for the rest of my life. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any old-school sendmail types here good with the m4?
On Wed, 2023-08-23 at 15:04 +0200, Johann Klasek via mailop wrote: > > Wild claim, but funny. For most things or standard configuration stuff > (even the ednsbl feature) m4's syntax is not to overcomplicated. It's > more or less in the range of other configuration syntaxes ... (just from > my perspective). It's also POSIX, and at least tangentially familiar to anyone who works with autoconf (when sendmail was written, all unix admins were C programmers). There are worse choices for sure. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, 2023-07-11 at 15:00 -0500, Jarland Donnell via mailop wrote: > > Does anyone actually receive mail by their A record in 2023? I'd just > assume break the RFC and save the resources for retrying and eventually > bouncing every email that ends up attempting delivery to an A record. > The MX record for a domain name is usually a necessary level of indirection, because the domain name itself usually points to a web server and not a mail server. But if I set up a mailing-list server on lists.orlitzky.com, then the hostname already points to the right address. Why also create an MX record and copy/paste? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, 2023-07-11 at 13:36 -0500, Grant Taylor via mailop wrote: > > However, I don't see any mention of a-record fallback in RFC 5321. -- > I didn't chase any updates. -- I do see four occurances of "fall" in > the document, three of which are fall( )back and all three have to do > with something other than MX records vs a-records. > > As such, I'd question the veracity of current SMTP needing to support > a-record fallback. 5.1. Locating the Target Host Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name... The lookup first attempts to locate an MX record associated with the name... If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, 2023-07-11 at 17:13 +, ml+mailop--- via mailop wrote: > > Which MTA is that? > Microsoft Exchange Server 2003? Seriously though, it's not a "fallback" in any pejorative sense. SMTP predates much of DNS, including MX records. It's a fundamental part of the specification. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SendGrid is deleting your mail (again)
Early yesterday morning, our upstream circuit was down from about 2:30am until 5:00am EDT. During that time, our MX was not answering; so, no 4xx or 5xx response involved. It's been over 24h, and I'm (personally) still missing five GitHub notifications from that time: 4:03am EDT, https://github.com/php/php-src/pull/11654?notification_referrer_id=NT_kwDOABXaR7I3MDEwODM5NzU0OjE0MzIxMzU#pullrequestreview-1521502822 4:24am EDT, https://github.com/php/php-src/pull/11631?notification_referrer_id=NT_kwDOABXaR7I2OTk5ODQxMjEyOjE0MzIxMzU#pullrequestreview-1521540314 4:25am EDT, https://github.com/php/php-src/commit/092e090cf00477e51802eae39651493b718c1415 4:42am EDT, https://github.com/php/php-src/pull/11654?notification_referrer_id=NT_kwDOABXaR7I3MDEwODM5NzU0OjE0MzIxMzU#pullrequestreview-1521565401 4:43am EDT, https://github.com/php/php-src/commit/893ca537b0a3dfb05d918d53e61fbf8cf9ca4f90 The complete lack of regard for your legitimate customers is maddening. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Microsoft: mismatched HELO/DNS
Saw this today, Jul 6 09:04:14 mx1 policyd-spf[19732]: : prepend Received-SPF: Pass (sender SPF authorized) identity=helo; client-ip=40.107.243.78; helo=nam12-dm6-obe.outbound.protection.outlook.com; envelope-from=mela...@example.com; receiver=example.net But, $ dig +short nam12-dm6-obe.outbound.protection.outlook.com 157.56.209.183 and, $ dig +short -x 40.107.243.78 mail-dm6nam12on2078.outbound.protection.outlook.com. When the sending domain does not have its own SPF record, that mismatch triggers spamassassin's FORGED_SPF_HELO rule. It's only adding one point, but since you send a bajillion messages, it'd be nice to avoid. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Sun, 2023-06-25 at 14:28 +0100, Dmytro Homoniuk via mailop wrote: > > 450 4.3.2 Please retry immediately. If your message was rejected by a > blacklist, see for more information. > > Now this just adds needless ambiguity: was it rejected because of the > blacklist or not? Am I on a blacklist? Which one? Should I actually retry? > And if I retry and see the same thing - does THAT mean I'm blacklisted? > Your message wasn't rejected at all, it was deferred. You're trying to out-think the RFC. > The ESP decided not to retry which was not in user's > best interests, the receiving MTA decided not to accept on first try > - which was also not in user's best interests. I don't see either a > winner here, nor anyone being right really - except the user who is > being royally screwed by everyone Except the part where I decided not to accept the message. I'm actually not sitting in front of the mail server with a button that 4xx defers messages I don't like. Temporary issues happen from time to time. And if you were paying attention at all, you would know that I've been going out of my way for YEARS to make sure that messages like these are received. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Sat, 2023-06-24 at 10:18 +, Louis Laureys via mailop wrote: > Michael, I was with you until it was revealed you mention a blacklist in your > response. Sendgrid assumes that the words in the response actually have > something to do with the reason it's being temporarily rejected, which is a > fair > assumption to make even if it doesn't follow spec. Then using different retry > logic based on that reason does make sense at that scale. I mean effort wise, > not "we're big so we can do whatever we want" wise. I'm personally no fan of > them, but I don't think this behaviour specifically is odd at all. Why take the time just to victim blame? A decade ago, I added some text to our 5xx rejections to try to be helpful. The RFC explicitly guarantees that doing so will have no negative effects. Fuck me I guess? The response does *not* say that they're blacklisted. The only reason they won't do the right thing and simply retry is because it saves them money when sending spam. The arguments about scale are smoke and mirrors. Your opinions are yours, but you're defending billionaire spammers who knowingly breaking the rules because the rest of us pay for it. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Sat, 2023-06-24 at 08:42 +, Andy Smith via mailop wrote: > > In the specific case at hand it seems that the OP is greylisting > SendGrid for being on some sort of blocklist, and the specific > mention of "blacklist" in the 4xx response is hitting a SendGrid > heuristic that says "don't bother to retry these", so messages are > actually being lost. I think it has implications beyond greylisting. > We're not greylisting them for being on a blacklist, they'd just get rejected in that case. The blacklist text is there for the people who get a 5xx reject. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Fri, 2023-06-23 at 13:29 -0700, Luke via mailop wrote: > Default behavior is always to retry 4xx if there isn't a rule in place that > overrides it. In this case, it was, and still is (i'm working on it) > hitting another rule that was put in place to *not* retry a very specific > 4xx that would never result in a successful delivery. > > The full response in question is this: 450 4.3.2 Please retry immediately. > If your message was rejected by a blacklist, see > http://michael.orlitzky.com/articles/so_youre_blacklisted.xhtml for more > information. > > The bit of text in the string causing the trouble is the word blacklist. I guess it's reassuring? that your system is fucking us specifically :) It sounds like you've got yourself a spaghetti regex nightmare whose behavior no one can truly predict. Maybe those ivory tower academics who wrote RFC5321 were on to something when they wrote "An SMTP client MUST determine its actions only by the reply code, not by the text." > Unfortunately, we see a number of 4xx responses that contain the word > blacklist and retries never succeed. For example, "450 4.3.2 your message > was rejected because you're on a blacklist" is *not *retried because it's > useless and *not* retrying is the appropriate thing to do for our > customers. I don't necessarily disagree with this, but here's another perspective. Blacklists are hard to test in production because they rely on a third party. When testing a new config, it's common (at least in postfix land) to switch your reject code from 5xx to 4xx while you see how things play out. Basically, you're giving yourself time to look at the logs and decide if you're losing mail that you don't want to lose. When you're satisfied, you switch the reject code back to 5xx. There are several config parameters designed for this. If someone is testing a new blacklist configuration and has switched their reply code to 4xx to ensure that they don't lose any mail, you're really doing a disservice by deleting their mail. > What really confuses me about this discussion is the almost religious > fervor around the idea that under no circumstances should a 4xx not be > retried and under no circumstances should a 5xx ever be retried. We just want things to work. The RFCs codify what's necessary for everyone to get along. I've certainly had enough of my own time wasted by this, and who knows how many important messages our customers have lost as a result. All of it could have been avoided if you followed the RFCs. I get that it would cost your company a little bit more money, but saving yourself some money at everyone else's expense is selfish and, in Bill's words, parasitic. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Thu, 2023-06-22 at 16:14 -0700, Luke wrote: > It's specifically targeting the response code and string you provided: 450 > 4.3.2 Please retry immediately Ok, I've spent the morning patching out a few more of our MTA's 4xx responses with that exact text. Some of them contained important diagnostic information, so I'm sabotaging my coworkers (and everyone else who sends us mail) to make this work. Supposing it does, it will have fixed the problem for one person, with one MTA, with one set of custom patches. You're still deleting everyone else's mail. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On Thu, 2023-06-22 at 10:52 -0700, Luke via mailop wrote: > I got a rule in place that should cover this. I'll monitor and make sure > the desired behavior is occurring. > Thanks, but which "this"? Should all 4xx replies now get a retry, or just the ones containing a certain phrase? (And which phrase, in that case?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On 2023-06-22 04:21:59, Sebastian Nielsen via mailop wrote: > >> We update kernels, reload AV signatures, have databases go down, > >> accidentally crash postfix during OS upgrades, typo config files, etc. > > Couldn't you make so if the inner servers are in trouble or go down > or similar, then the perimeter server will buffer the email for you > without a temporary reject? We don't want to accept mail and then later bounce (backscatter) it, so at a minimum, the outer servers need to be able to do recipient validation and spam scanning, and those services can have hiccups. No matter how far you push the problem down the road, there's a fundamental limit you hit eventually. > When it comes to spam and virus filtering, you could skip spam > filtering for "buffered" email, ergo email that was received during > outage. And just apply virus filtering. For virus filtering, you > ARE allowed to silently delete email according to RFC, and what I > know, also for those countries that prohibit silently deleting > emails for "spam": I was referring to a European law that doesn't apply to us, so I don't want to focus on it too much. Instead I'll just say that us silently deleting emails is not a very satisfying solution to the problem of someone else silently deleting emails. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On 2023-06-21 18:39:59, Luke wrote: > Ahh. Thats funny. Apologies. You'll have to refresh my memory. > > Happy to help if I can. Give me the full response, code and string, and > tell me how you'd like us to handle it and if it makes sense, I can make > the necessary changes. > In this case, before patching, the original response was, 450 4.3.2 Service currently unavailable After patching, it's 450 4.3.2 Please retry immediately I'd rather not patch our MTA for the rest of eternity, so a rule for the first response would be preferable. But if that's not possible I can live with the second. After all, that was my hope/plan after the last discussion. In either case, one quick retry (a minute?) followed by a few slower attempts (1h, 12h, 24h, etc.) for 4-5 days would be perfect. The quicker retries help with the planned hiccups, while the longer ones accomodate the unplanned ones. However, a custom rule would address only that one source of 4xx error. Others are popular. For example, 450 4.3.0 Queue file write error when we kill a filter process while the MTA is waiting on it. And that's just for our MTA. I think I've already disproven the null hypothesis, that SendGrid retries normally in the absense of statistical evidence discouraging it. If that's not the case, it should be: the default should be to do the right thing and retry. Otherwise, everyone is going to have to hack their MTAs to return some magic phrase. Still, I'll take what I can get. Thanks for responding again. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On 2023-06-21 18:19:41, Luke via mailop wrote: > > I work at sendgrid and manage response handling. If someone were to reach > out with an obvious problem, I'd be willing and able to adjust our response > handling appropriately. > You're the guy I mentioned the problem to last time. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On 2023-06-22 02:05:40, Sebastian Nielsen via mailop wrote: > >> They were going to get a 4xx anyway. I changed the message to *help* > >> SendGrid. > > Yes but if you can change the message for SendGrid only, you can > accept the mail and let it through... Apparently you were able to > send custom text to just SendGrid. Then you have some rule to be > able to differentiate SendGrid mail from other mail. Thus you just > accept it. I was unclear then. I patched the mail server to change the 4xx text that we send to everyone, but I changed it only to help SendGrid. I have no way to know ahead of time who is using SendGrid. Some senders, like GitHub, have dedicated servers and send us enough mail that, over time, I have been able to whitelist all(?) of them. This helps but is not enough: * I can't whitelist a server until we've lost a message from it. The way I find out that there's a server to whitelist is that a customer calls to let us know that he's missing an important piece of mail from it (e.g. the Hershey Park tickets). * Continuing the example, GitHub is constantly adding/changing servers. When they do, we're at risk of losing mail until we can whitelist the new addresses. * The non-dedicated SendGrid servers cannot be whitelisted, because almost all mail from non-dedicated SendGrid servers is spam. * I think you're assuming that most of our 4xx errors are from the spam filter or from overzealous action on my part to make a point; they're not. We update kernels, reload AV signatures, have databases go down, accidentally crash postfix during OS upgrades, typo config files, etc. All of those result in 4xx errors and whitelisting does nothing to help. The bottom line is that avoiding 4xx *entirely* is impossible, even if I could reduce them somewhat at great expense. If nothing else, then in those unavoidable scenarios, you have to agree that SendGrid has a responsibility not to delete important mail. But they do. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
On 2023-06-22 00:32:37, Sebastian Nielsen via mailop wrote: > Why even send retry requests to SendGrid? > Just accept the email, whats the problem? > > If your antivirus or mail scanning solution requires some time, > buffer the email at your server instead. I do understand it creates > the problem of, when deciding to keep or trash the email, SendGrid > client is long gone, And sending back an error would create > backscatter. But then, just silently trash the email if it is > deemed virus or similar. If your spam filter is perfect this can work. Otherwise, silently deleting mail is not nice for our customers, is not nice for the senders, and is illegal in some places. > You could try using stream scanning and then when arriving at final > decision, let client wait for some seconds before getting an scan > result. We already do this, and I don't see how it's relevant. The transaction can still time out, and there are lots of other reasons why we might send a 4xx. > >>These are a pair of tickets for Hershey Park that a family has been waiting > >>on for two days: > > Your fault. You rejected the email with "Please retry immediately" just to > mock with SendGrid. They were going to get a 4xx anyway. I changed the message to *help* SendGrid. > If you have the possibility to set an IP to have custom reject text, > you have the possibility to whitelist that IP (and/or domain) so > mail pass unaffected. Where do I find out what the IP/domain is? Is it in my mail logs, *after* they've deleted the message? Durr ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SendGrid is deleting your mail
The last time SendGrid's failure to retry 4xx came up here, their response was that, when determining whether or not to retry, they analyze not only the 4xx code but also the associated text. If (based on those data) a retry is statistically unlikely, they won't do it. The RFC forbids doing that, and I argued against it -- not just on principle, but because when 99% of your mail is spam and 1% is not, grouping them together introduces a base-rate fallacy into your decision-making process. Regardless, it looks like I was wasting my time: their explanation is incomplete at best. Since then I've patched our mail server to reply with unique 4xx text. Retries to us will almost always succeed, so our unique (code,text) pairs, being unaffected by anyone else, should be associated with a high probability of success. Still, they choose not to retry. These are a pair of tickets for Hershey Park that a family has been waiting on for two days: # grep 'hersheypa\.com' /var/log/mail/mail.log* mail.log-20230620:Jun 20 09:25:53 mx1 postfix/postscreen[23626]: NOQUEUE: reject: RCPT from [159.183.156.68]:36108: 450 4.3.2 Please retry immediately; from=, to=, proto=ESMTP, helo= SendGrid silently deleted them. We want your mail; please stop using SendGrid. Thanks for listening. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On Tue, 2023-03-28 at 17:04 +0200, Tobias Fiebig via mailop wrote: > > Are there any other thoughts on this? > Microsoft has been breaking email for profit for thirty years. If you haven't figured out their business model by now, the bad things that happen to you are your own fault. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] sender domain reputation
On 2023-03-22 20:12:31, Slavko via mailop wrote: > > But seriously, what is difference between .com and .pw (or any > other domain name) other than that .com is here +- from start > of DNS? When dot-pw went public, it was heavily abused by spammers: https://www.domainregistration.com.au/news/2013/1305-pw-domain-spam.php It may be time to forgive them, but you'll still have to convince people that the signal to noise ratio makes it worth their time. For example, in the decade since we blocked it, I'm aware of exactly one false positive... and that was from someone who worked at the registrar. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Tue, 2023-02-28 at 12:31 +0100, Jaroslaw Rafa via mailop wrote: > > I do greylisting, and that's how I found out about the immediate > retries. I run postgrey with default setting which is 5 minutes, and > I often see in logs multiple retries within those 5 minutes, with > first ones being really almost immediate (15-30 seconds). I have no > other MXes, so I can't observe retries to other MXes, but I often see > retries FROM different IP address than the original attempt, which > count as new entries for greylisting, as greylisting works on triplet > (client IP address, sender, recipient). > ONE immediate retry can be helpful. Since you mention postfix, the "accidental greylisting" caused by its deep protocol tests can be mitigated by sharing the postscreen cache across MX, even if one of them is simply an alias: https://www.postfix.org/POSTSCREEN_README.html#after_220 In those situations, the immediate retry will go through. (And FWIW I would suggest lowering the timeout on postgrey; spambots don't come back after a few seconds.) That doesn't help when the retries all come from different IPs though. That is indeed stupid. It's not surprising however given that most of those providers will loan you a consistent IP for a small fee. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Mon, 2023-02-27 at 21:38 -0700, Luke wrote: > > First, we send a lot of email; 9 billion messages on black friday > alone. Each message generates an average of 8 events (deferrals, > opens, clicks, spam reports, unsubscribes etc). Storage cost is a > small part of the reason for minimizing MTA chatter. It's not a big > enough factor for us to make irresponsible decisions in this area to > save money, but it's a factor. I don't know if they're separate systems, but nobody is complaining about the missing marketing emails. It's the password resets, two- factor auths, email verifications, etc. disappearing that get noticed. > Second factor (and the main factor) is our customers. We send 32 > deferral events over the course of 72 hours to our customers' data > warehouses for each message...So do we read the RFC to our customers > and tell them to pound sand? Or do we take some time and see if we > can help make their experience a little better *and* save us some > money at the same time? It sounds like what they're unhappy with is the mountain of unwanted data, not the retries themselves. And these sound like marketing complaints that are being used to make decisions for transactional customers. I know your transactional customers don't want this, because they call me and ask why they're not getting the emails from their website. The answer is that a lot of people aren't getting mail from your website, and you're losing users because they can't complete the registration process because SendGrid deletes the confirmation emails. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Mon, 2023-02-27 at 18:53 -0700, Luke via mailop wrote: > For better or worse, *not *retrying *some *4xx is even easier to > justify. > Here are a few massive examples. > > 421 4.7.1 Message permanently deferred: > > 452 Sender Rejected: Keeping in mind that the RFC says not to use the text in your decision, these two sound the most reasonable. Skipping for brevity. > 450 4.1.1 Recipient Address Rejected: this one is tough because with > some MXs retries result in delivery, in others, it's a dead end. > Dynamic rule handling per receiving MX would be awesome, but it would > require machine learning to accomplish at scale. This could postfix's unverified_recipient_reject_code. When (for example) postfix sits in front of an Exchange server and when a full list of valid recipients is not available, postfix can launch a background probe to see if the recipient is valid in Exchange before it will accept a message destined for it (otherwise, you get backscatter). If postfix is up but Exchange is down, it'll give you this rejection. > 451 Relay Not Permitted: this one can mean a lot of things and comes > in a few flavors, but when the data shows retrying never results in a > delivery, we permfail it. This happens when somebody's domain expires and the MX record gets pointed somewhere it shouldn't. This is the right response because when they finally find the guy who knows the guy who knows the guy who receives the email that resets the password at the registrar three days later, it's nice to have all their mail start flowing as if nothing ever happened. > Unlike the rare 5xx we decide to retry, these 4xx that shouldn't be > retried are far more numerous and come from large-ish reputable > receivers. Believe me, simply retrying 4xx and failing 5xx would make > our jobs a lot easier. Unfortunately the real world isn't so simple Not pounding on servers that have told you to go away with a 5xx has obvious benefits for both sides though. What's the downside to leaving the 4xx in the queue for a while? No one is going to fault you for retrying a message they told you to retry, and even 1% of legitimate mail is a lot to toss out without a good reason. Finally, while it might be 1% of *your* mail it's not 1% of *our* mail. Michael Scott said Wayne Gretzky said that you lose 100% of the messages you don't retry to recipients who would have accepted them. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Mon, 2023-02-27 at 15:45 -0700, Luke via mailop wrote: > > With that said, given the responses in this thread, we will be taking > a close look at the few rules we have in place where we retry 5xx and > see if A.) the rules are still being hit at all, and B.) are these > retries still resulting in reliable and consistent delivery after a > small number of attempts. > That's a good idea anyway (thank you), but the original issue wasn't about an extra retry or two for a 5xx, but the lack of any retry at all for a 4xx. That happens all day every day and is what makes mail go missing. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Mon, 2023-02-27 at 04:55 +, Denny Watson via mailop wrote: > > All I have said (which you had conveniently redacted) is that RFC5321 > leaves the door open to process bounces differently should the > sending MTA be able to determine the reason for non-delivery.[1] > > ... > > [1] See my original email on this subject about section 4.5.4.1 of > RFC5321 and why rejected mail can have a different queuing strategy > based on the sender's interpretation of the 4xx response the it had > received. I didn't redact it to make my argument seem stronger, I redacted it because it's irrelevant. That's not what SendGrid is doing. And you quoted the RFC out of context anyway. Here's the full text of the first two paragraphs of that section for anyone too lazy to look it up: 4.5.4.1. Sending Strategy The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. It clearly states that messages must be retried. The "variable strategies" you latched onto is in the context of how often the sender should retry. I don't care if SendGrid takes your money and pipes your mail to /dev/null but we can stop pretending that they're playing 4d chess with RFC5321 now. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Sun, 2023-02-26 at 19:43 +, Denny Watson via mailop wrote: > This appears to be a specially built MTA, and with the (probable) > consent of its users, has policy in place to not resend after 4xx under > specific conditions. I.e. the sending MTA is interpreting specific 4xx > responses (and more likely the text) to mean a permanent failure. > > I do not see a problem with elevating a 4xx to mean 5xx where the users > of the system understand the policy as it does not appear to impact the > receiving system. This is not whatever subtle and nuanced situation you are imagining though. The users don't know, and the response code/text makes no difference. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On 2023-02-25 19:15:14, Luke via mailop wrote: > I can assure you sendgrid retries 4xx. We also don't retry 4xx. We also > retry 5xx. We also don't retry 5xx. How is it 2023 and people still think > 4xx means retry and 5xx means don't retry? > It's literally unexplainable if you've never read the part of the RFC with the word "retry" in the title: mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On Fri, 2023-02-24 at 15:57 -0500, Christine Borgia via mailop wrote: > It is transient, but they are blocks and are not retried. Weird, right? > SendGrid doesn't retry on 4xx and haven't for many years. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outgoing filtering Re: Cyren
On Fri, 2023-02-03 at 09:28 -0800, Ken Simpson via mailop wrote: > > > It’s a tough problem to solve at Google or Microsoft’s scale. No, it's not, it scales linearly. They would just rather the rest of us pay for it. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Postfix.org borked?
On Mon, 2022-11-21 at 11:12 -0800, Dan Mahoney (Gushi) via mailop wrote: > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;postfix.org. IN A > > You want www.postfix.org. The bare domain name has never(?) worked. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] two openssl (in OpenDKIM) questions for the masses
On Thu, 2022-09-15 at 14:44 -0700, Dan Mahoney (Gushi) via mailop wrote: > > * Does anyone know of an OS packager that's choosing to build with gnutls > instead of openssl. (It would simplify autoconf a lot to remove the > gnutls support, as there are AC macros for openssl, but not for gtls). > We used to let the user choose in Gentoo, but had to remove the GnuTLS option when it stopped working: https://bugs.gentoo.org/682906 If you made it work again, I would add back the option... but if I were you, I would take this opportunity to quickly and discreetly slit its throat, saving us both the trouble. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hostkarma Black listing
On Thu, 2022-04-21 at 09:52 -0400, Chase Vance via mailop wrote: > Hello all, > > Is there anyone with Hostkarma on this list that could assist me in > removing an IP. I have put in several delisting requests and tried > sending some help tickets but I have gotten nothing back. > > Thank you all! > The owner and main(?) operator of junkemailfilter.com passed away a few years ago. Someone else may have taken over the operation, but if you don't get any other answer, that's why. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] spamhaus blocking Linode IPv6 (2a01: 7e01)
On 2021-11-26 11:25:06, Mary via mailop wrote: > > Thinking out loud... > > Would it be possible for the two sides (blocklists and a > cloud/hosting providers) to come together and have some kind of > automated notification? The blocklists already provide a convenient API to the providers: if you want to know if you're listed, do a DNS lookup. You can easily script this for as many blacklists as you want and run it in a cron job. Or if you want to get more complicated, you can use dedicated plugins for e.g. nagios to check the lists and alert you if any of your hosts are listed. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid spam of the day
On 2021-10-20 18:12:32, Luke via mailop wrote: > For clarification, it has been 12 years. But point taken. Thanks. > The causal relationship may be me editorializing, but prior to the Twilio acquisition, I held no strong opinions about SendGrid and that's probably the best that can be said of any large ESP. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid spam of the day
On Wed, 2021-10-20 at 10:46 -0700, Luke wrote: > Thanks, John. The account in question is being looked at as we speak. > It should be terminated shortly. > > Michael, do you have an example of a 4xx we aren't properly handling? > Would love to take a look and adjust handling. > Are you finally going to stop allowing the same criminals to sign up and send the same textbook scams from the same obviously-forged domains after two years? If not, then I prefer the status quo. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid spam of the day
On 2021-10-19 16:41:40, John R Levine via mailop wrote: > Fake USPS spam, sent to my father who I am pretty sure has not ordered > anything > lately since he is dead. Tragically, we lose most of these because they still haven't figured out how to retry a 4xx. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] U.S. DoJ will elevate rasonware attacks to the same priority as terrorism
On Fri, 2021-06-04 at 16:26 -0400, Kevin A. McGrail via mailop wrote: > I thought this news was very welcome today: > > https://twitter.com/RichardEscobedo/status/1400529641065140225 > > “The U.S. Department of Justice is elevating investigations of > ransomware attacks to a similar priority as terrorism in the wake of the > Colonial Pipeline hack and mounting damage caused by cyber criminals, a > senior department official told Reuters.” > If you're brown and innocent, try not to get blown up. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..
On Fri, 2021-02-05 at 08:32 -0800, Marcel Becker via mailop wrote: > > > I don't see ignoring spam to decrease expenses > > > > I see you actually didn’t read Brandon’s mail. > On the contrary. Each starts from the position of having gotten rich giving guns to children, and proceeds to discuss the technical difficulties involved with keeping everyone from shooting each other in the face. If you're not willing to not be an asshole, it is indeed a difficult problem. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..
On Fri, 2021-02-05 at 07:26 -0800, Marcel Becker via mailop wrote: > > So you would gladly pay thousands of people to deal with abuse > reports > which are, well, not actually abuse reports. And a lot of them. I > wouldn't. > For the sake of the sanity of those people alone. > Abuse reports for non-abuse also scale linearly. I don't see ignoring spam to decrease expenses are morally superior to sending spam to increase revenue, but feel free to think that the negative signs make you a better person. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Some Days I think that Gmail isn't even trying to stop outbound spam..
On Thu, 2021-02-04 at 19:23 -0800, Brandon Long via mailop wrote: > If you received say... a million ab...@gmail.com emails a day, how > would you handle that? > 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. If that turns out to be overly expensive, I'd probably think we're letting people send too much spam, or that our business model is fundamentally parasitic. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] Anyone from BlueHost on this list?
On 12/22/20 2:54 AM, Sidsel Jensen via mailop wrote: Is this still a valid limit? I’d like to hear your thoughts about it. The limit was chosen for performance reasons, and for that it's still valid. SPF validates envelope information, so those lookups happen even if the message will ultimately be rejected for its content. And forgeries create load on the VICTIM'S servers. It's better for everyone if the domain administrator spends five minutes up-front to consolidate and denormalize things, rather than having every recipient of every message do it every time. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 8:22 PM, John R Levine via mailop wrote: Unfortunately, many sending clients (newsletters, announcements, etc.) do not retry if the initial delivery fails. That's impressively broken. Do you have specific examples? SendGrid. They have a webpage that says "We continue to retry messages for up to 72 hours," but they (sometimes?) don't. Good news is, they've been so spammy that I don't care any more. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Trying to find the CIDR ranges for DigitalOcean
On 2020-10-09 03:19, Steve Atkins via mailop wrote: > > I like Hurricane Electric's tools. > > https://bgp.he.net/AS14061 > After a copy/paste, grep, and consolidation of those ranges I wind up with... 10.127.40.0/24 10.196.66.0/24 10.212.2.0/24 10.214.2.0/24 27.111.228.0/22 37.139.0.0/19 69.55.49.0/24 80.240.128.0/20 82.196.0.0/20 95.85.0.0/18 103.253.144.0/22 138.68.34.0/24 138.68.36.0/22 138.68.40.0/21 138.68.48.0/20 138.197.240.0/22 138.197.252.0/22 141.0.169.0/24 141.0.170.0/24 159.89.32.0/20 159.89.48.0/21 163.47.8.0/22 164.90.224.0/20 164.90.248.0/24 164.90.252.0/22 185.14.184.0/22 188.226.128.0/17 192.34.56.0/21 204.48.16.0/20 208.68.36.0/22 69.55.54.0/23 138.68.0.0/19 138.68.32.0/23 138.197.192.0/19 159.89.0.0/19 159.89.58.0/23 164.90.192.0/19 164.90.240.0/21 165.232.32.0/19 206.81.0.0/19 192.81.208.0/20 67.205.128.0/18 104.236.0.0/16 138.197.128.0/18 138.197.224.0/20 159.89.60.0/22 159.89.64.0/18 164.90.128.0/18 165.232.64.0/18 178.62.0.0/16 207.154.192.0/18 209.97.128.0/18 107.170.0.0/16 146.185.128.0/18 192.241.128.0/17 64.227.0.0/17 134.122.0.0/17 143.110.128.0/17 5.101.96.0/20 198.211.96.0/19 104.131.0.0/16 128.199.128.0/16 198.199.64.0/18 142.93.0.0/16 165.22.0.0/16 167.71.0.0/16 67.207.80.0/19 138.68.64.0/18 64.225.0.0/17 138.68.128.0/17 138.197.64.0/17 159.89.128.0/17 174.138.0.0/17 46.101.128.0/16 45.55.128.0/16 188.166.0.0/16 68.183.0.0/16 104.248.128.0/16 134.209.0.0/16 157.245.128.0/16 159.65.0.0/16 161.35.0.0/16 165.227.0.0/16 167.99.128.0/16 167.172.128.0/16 178.128.0.0/16 206.189.0.0/16 139.59.128.0/16 157.230.0.0/16 159.203.64.0/16 162.243.0.0/16 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] STARTTLS - Constant Contact and yahoo.co.jp
On 2020-08-26 12:50, Scott Mutter via mailop wrote: > I've been toying with the idea of forcing outbound SMTP connections to > use TLS, but thought I'd take a quick look and see who might miss mail > if this done. This sounds good at first but if you make a flow chart, all paths lead to either "nothing changes" or "shoot yourself in the foot." There's no scenario that I know of where forcing TLS (as opposed to "opportunistic" TLS) improves anything. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.
On 2020-08-11 16:53:46, Benoit Panizzon via mailop wrote: > > Now a sendgrid customers complains to us, that his emails are being > rejected because of this listing. > > But that makes me wonder: Doesn't sendgrid deal with such issues like > asking for delisting after blocking the sender itself and re-uses > recently (last phish received on 14. July) 'abused' ip addresses for > other customers? > In the past few months there have been several threads on mailop and similar lists (sdlu, spamassassin-users, nanog, ...) complaining about how SendGrid doesn't seem to do anything at all to stop the ongoing blatant phishing campaigns from their servers. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is DNS-over-HTTPS bad? Sure. (was: Happy Holidays Everyone!)
On 2020-07-06 06:37:54, Matt Harris via mailop wrote: > > If said fascist regime has decided to muddle their DNS > infrastructure by serving bogus authoritative responses for some set > of domains they don't like, why would anyone think they wouldn't > just set up " use-application-dns.net" to force end-users to > continue to use their DNS servers which implement that blocking, > too? > On this episode of What Could Possibly Go Wrong: we use a centralized, government-controlled database of who's good and bad to fight fascism. Guess who's hanging out in your browser's root CA store? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Microsoft Block list (S3150)
On 2020-06-25 01:33, Scott Mutter via mailop wrote: > > Just once, I'd love to get a response from Microsoft that explains why > they're the only ones blocking an IP address. When your customers can't send email to Microsoft or Gmail, they cancel their account with you and move their email to Microsoft or Gmail. * Why won't Exchange follow the SMTP standards? * Why can't Outlook implement STARTTLS correctly? * Can Outlook finally support CalDAV and CardDAV? * How come all my mail comes through as winmail.dat? All of these questions from the past 20 years have the same answer. It's simply a novel method to outlaw not paying them. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Microsoft: Forged SPF HELO
SpamAssassin now adds a point whenever the HELO name is forged but the SPF check on that HELO name passes. Looking through our logs, the major offender here seems to be outlook.com. For examples, helo : NAM11-CO1-obe.outbound.protection.outlook.com ip : 40.107.220.95 dig $helo A : 23.103.198.207 dig $helo TXT: v=spf1 include:spf.protection.outlook.com -all helo : nam11-dm6-obe.outbound.protection.outlook.com ip : 40.107.223.121 dig $helo A : 23.103.135.207 dig $helo TXT: v=spf1 include:spf.protection.outlook.com -all ... All of them have the same generic SPF record, which is fine, and so they all pass the HELO SPF check. But that means that every outbound outlook.com server with a HELO that doesn't resolve to its IP is getting hit with an extra spam point. I know these aren't real servers and these aren't real names and there aren't real humans in charge over there et cetera =) But if the names can be made to match when an SPF record is present, it would eliminate a penalty that's getting added to a lot of outlook.com mail. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SendGrid Abuse unresponsive
On 5/4/20 10:49 PM, Will Boyd via mailop wrote: > Hi Kyle, > > I've located those tickets. It looks like a colleague did reply on > Wednesday to 4218173 and the reply went to Angelo. I'm not on our abuse > team but will ping them with both ticket numbers to follow up. > If you'll allow me to hijack this thread while it has some eyeballs... Apr 30 15:27:58 mx1 postfix/postscreen[12495]: NOQUEUE: reject: RCPT from [198.37.144.39]:25470: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= That message was never retried, even though this page says you'll retry for 72 hours: https://sendgrid.com/docs/glossary/deferrals/ That sample is fresh in my mind, but it's not a unique problem. We do pre-queue scanning and sometimes you're just gonna get a busy signal. We'd all love it if you could re-send at least once per the RFC so that people will stop calling us about lost messages =) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] viva.com.do postmaster
On 2/4/20 3:48 PM, Michael Peddemors via mailop wrote: > UCE-PROTECT-2 and UCE-PROTECT-3 to be more precise.. > It might be that you have bad 'neighbours'. Am I confused? I mean, I know I'm confused now. Are you two confused? =) I sent my message from 65.246.80.16. The recipient's server -- the one that rejected the message -- is 190.8.37.13, and is listed on UCEPROTECT L2/L3. 65.246.80.16 should be totally clean. I suspect the problem is with 190.8.37.13 (viva.com.do), which is why I was trying to contact them in the first place. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] viva.com.do postmaster
I am trying to report the fact that your blacklist check is broken: > : host tiburon.viva.com.do[190.8.37.13] said: 550 > 5.7.1 > Recipient not authorized, your IP has been found on a block list (in reply > to RCPT TO command) but I can't, because your blacklist check is broken. The sending server is 65.246.80.16, and is not blacklisted as far as I can tell. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 2/3/20 5:04 PM, Brandon Long wrote: > > I always wanted to lower it, the messages that take longer than a day > are in the noise, and a lot of time that's because a mailbox is so busy > that it's on the edge of being able to actually handle the volume, and > the problem is more one of flow control (twice in two threads, wow) It's easy to lie (inadvertently) with statistics. If you draw the window big enough, you can ignore any potential problem as statistical noise. Basically 100% of the time, messages do go through instantaneously. But when your office floods and you have to call someone in to replace, reinstall, and restore the whole thing from backup, now 100% of your messages are delayed. 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. Customers really love hearing that they're not going to lose any mail when that happens. The rest of the time, yeah, it's a bit long. But we're not trying to accomodate the one guy who's over quota on a random Tuesday. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 2/2/20 12:52 PM, Chris Adams via mailop wrote: > Just an idle Sunday question... how long do you have your mail server(s) > configured to queue and retry messages before bouncing them back to the > sender? > > I know back in the day, 5 days was the norm, to handle servers that were > only sometimes connected, outages, etc. The five-days number is recommended by the RFCs. I always assumed that number was to account for "long weekends." If your server crashes on somebody else's property on Friday, and if Monday is a holiday, you can still get mail that is retried for 5 days. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Best strategy to prune address list
On 11/24/19 12:17 PM, Jaroslaw Rafa via mailop wrote: > > Just to be precise, you should check for either MX or A/ record. This prevents you from eliminating a huge number of bad addresses, though, to save a negligible amount of good ones. For the same reason, I would recommend verifying the addresses against a simple regular expression to catch typos, rather than against the full rfc5322 grammar which allows basically anything. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail marking email from me as spam
On 10/14/19 9:29 PM, Brandon Long via mailop wrote: > > > On Mon, Oct 14, 2019 at 3:54 PM Michael Orlitzky via mailop > mailto:mailop@mailop.org>> wrote:. > [snip] > > They don't care if you or anyone else can send/receive mail, ... > > > It seems like Gmail wouldn't last long as an email provider if no one > could send/receive email to it. > I don't believe that either (it's right out of the EEE playbook), but it's not quite what I said. I said "Google doesn't care," and for that the proof is in the pudding. We've been delivering mail to gmail all day every day since it was born. Bazillions of messages over however many years. Had thousands of delivery/spam problems (on both ends) that the world is better off having resolved. And yet, after all those years, messages, and problems -- you're the closest thing to a real human "gmail support" person that I've ever encountered. Even so, the best you can do is to tell this guy that perhaps maybe if he potentially switches hosting providers then probably in all likelihood it could fix his issue in theory with any luck. So while you personally seem like a nice dude and I know you're trying to help, the fact that you ultimately can't (and that begging on mailop is tier 1 support in the first place) just cements my impression that Google as an organization doesn't care. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail marking email from me as spam
On 10/14/19 6:03 AM, Jaroslaw Rafa via mailop wrote: >> Small senders do just fine getting into Google. > > Well, as I already mentioned, I moved my mailserver to my current hosting > right about 18 months ago. Had no problems - until now. So, the fact that > you have no problems currently doesn't mean you can't run into problems > later - with no fault on your part whatsoever. Email delivery to big > receivers like Google just isn't as reliable as it should be. > I'm replying at a random point in this thread. I see two separate problems here that are getting conflated. 1. It's not fair to judge a sender by his neighbors. Well, kind of. Our in-house blacklists are tended manually, and we keep evidence for every listing so that if we later have to explain ourselves, we can. If I get one spam from one IP in your netblock, I ban that IP. If I get spam from two IPs in your netblock, I ban them both. If I get spam from three, and I have to spend half an hour typing up commit messages and pushing to repos and classifying evidence... then to hell with you, I'm blocking the whole thing. It's now *your* problem. That's the price you pay for having a real human over here. However, if we block you, you can just read the rejection message and get in touch with me or a coworker easily and we'll add an exception for you, because we care that our users get your mail. This is where the second issue comes into play. In general, overzealous blocking is not a life or death issue; but with Google, there's no one to appeal to. And that's the crux of your problem. This first issue about reputation is being argued pointlessly. The real problem is that 2. Google doesn't give a shit about you. They don't care if you or anyone else can send/receive mail, because that's not how they make money. You're not going to convince them to care, and so long as they don't, your problems are only going to get worse. No one's going to tell you how to fix *this* issue because there is no solution -- that's why you're getting the next best thing, namely advice to switch providers and pray that Google doesn't feel like blocking your new host, too. "Old man yells at cloud," but that's the truth. Being a good guy isn't a great business model in any unregulated industry. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On 5/8/19 1:48 PM, Ken O'Driscoll via mailop wrote: > There is likely more, above is, as I said, off the top of my head. Good > luck. > One to add: * Sign up for feedback loops with the major providers. I see a remarkable number of phished-credential bots that are smart enough to send one message every ~five minutes. Our automated defenses miss those, until Comcast or AOL starts sending me complaints. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] No MX record on domain is a bounce by Gmail
On 5/4/19 2:06 PM, Reynold McGuire via mailop wrote: > > Industry standards, best practices and 30+ years of SMTP say to follow MX. You're lying about at least two of those things. Throw away your users' mail if you want, but don't spread dangerous misinformation. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
