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
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
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
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
>
>
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
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 mus
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.
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
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
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.
>
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
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.
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,
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
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
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
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
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
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
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,
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,
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.
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
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
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,
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.
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:
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
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
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
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
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
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
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
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
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
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.
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).
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
64 matches
Mail list logo
