[doubled112]

Is Cloudflare a cheapo VPS?

It is a cheap VPS, but it would still be nice if there was a way to know (not assume) beforehand.

> 550 5.7.1 Unfortunately, messages from [IP ADDRESS] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).

> Your IP(s) qualify for conditional mitigation.

Still blocked. The system is working as expected.

[inigyou]

Cloudflare is one of the shadiest hosts around, almost as bad as the big three clouds.

[TZubiri]

You can't have the cake and eat it too.

Either you use cheap infrastructure that attackers can buy by the bulk for sybil attacks.

Or you pay a reasonable price for a slice of an IP block that doesn't share its reputation with elcheapos.

[doubled112]

No disagreement here. I had never planned to use it for email, but I was bored and I already had it when I got an idea.

[jeffbee]

I would simply like to point out that 550 at SMTP time is not a bounce.

[doubled112]

You get an email bounce back with an error code in it. Is there some other definition I'm unaware of?

Wait, that is probably from the local mailer, and otherwise the sender may never know about the rejected messages.

[b112]

5xx are bounces, a perm failure. 4xx error codes are temp (retry) errors.

[jeffbee]

Incorrect. A bounce is a delivery status notification generated by a mailer after it has already accepted a message for delivery. A 5xx permanent error is a refusal to accept the message in the first place.

[TZubiri]

Is this standarized terminology in some RFC like SMTP? Or is it presumably some well established folk lingo?

[turpentine]

jeffbee isn't offering any explanation, maybe because it's obvious to them they don't think they need to, or something like that... so I'll volunteer one.

If you send an email, your client would talk to your local MTA (i.e. the SMTP server you own or are authorised to relay mail through, e.g. ISP). The local MTA usally just accepts the email to insert it into a queue for attempting delivery. When your MTA processes the queue, and talks to another and gets 5xx or 4xx response, your MTA will generate a "bounce" (non-delivery report) email that lands in your inbox with the details of the response it received.

So jeffbee is correct that when the local MTA gets a 5xx or 4xx response code in the SMTP session with target MTA, that /the response code is not a bounce/. Microsoft responding with 5xx or 4xx in the SMTP session, they are not bouncing the email. They are refusing to accept delivery.

For Microsoft to "bounce every email" from the original parent commenter, it would have accept each email first, and then use the return path address of each email accepted to send a bounce email asynchronously, i.e. the bounce is not part of the original session.

If a MTA talks to another MTA who accepts a message for delivery, they can then bounce the email at any later point via the address specified in the return path header. Why? Maybe incoming email is queued and scanned, because it would take too long to determine if it passes secondary rules when it's initially being accepted.

Given how this works, you could take an email inbox you received a year ago, or five... and send an email with whatever content to the return path address, and you have "bounced" the original email.

[b112]

They're referring to the bounced notification message, not the fact that the mail bounced. Verb and noun.

A 5xx is a bounce, and results in a bounced email message. Variances always abound, but I'll stick with my 30 year old terminology, and it is correct.

[jeffbee]

That's fair with regards to your statement, but "doubled112" assigned the agency to Microsoft, saying that "Microsoft bounces" their traffic, which is demonstrably not what is happening.