I was thinking of implementing grey listing, and was wondering if this idea[1] is still up to date with current standards.
Questions I wonder about when sending the 451 4.7.1 to the sender are:
1. Is the sender required to deliver the message to the same server
(when you have multiple mx records)
2. Is the sender required to use the same from (eg. no idea if @#$#@
like mailchimp change their from bounce-mc.us5_10712807.8832082-dfaa67f206@mail154.atl121.mcsv.net)
1. Is the sender required to deliver the message to the same server
(when you have multiple mx records)
2. Is the sender required to use the same from (eg. no idea if @#$#@
like mailchimp change their from bounce-mc.us5_10712807.8832082-dfaa67f206@mail154.atl121.mcsv.net)
1. Is the sender required to deliver the message to the same server
(when you have multiple mx records)
That's a good question. IMHO, it's up to you. What requirements do you want to impose?
In some ways, this is a question of state. As in does each MX have it's
own independent state or is the state shared among them?
E.g. does
connecting to the first high priority / low numbered MX count as the
grey list for the second not as high priority / not as low numbered MX
or not?
2. Is the sender required to use the same from (eg. no idea if @#$#@
like mailchimp change their from
bounce-mc.us5_10712807.8832082-dfaa67f206@mail154.atl121.mcsv.net)
If we stop and think about things for a moment, why would the SMTP
envelope sender or recipient change in between transmission attempts?
As
such, I would think that the envelope addresses SHOULD be the same
across transmission attempts.
Now perhaps you are speaking to scoping of the grey listing, as in what constitutes the tuple that is grey listed; sender, recipient(s), sending host?
After many years of grey listing I switched to no-listing (w/ TCP reset) which is stateless on the recipient's end. It works by pushing the
state into the sending server's end by causing the sender to properly
retry multiple MXs.
yes the ip address is indeed included as a default/example. I am also questioning if this is acceptable.
I already noticed in my own testing environment that the delivery is
being attempted already a few minutes later on the 2nd mx.
I am even receiving spam on mx hosts that I have removed from the dns,
they just archive this info somewhere.
So I decided to try and turn the blocking into grey listing, but the
sender is getting a greylist dsn with an api url to the mx host.
Just clicking the link will allow the message go thru on the next attempt.
In time I will just increase the greylist timeout from now 2h to as high
as I do not receive annoying newsletters/spam or what ever.
None wrote:
1. Is the sender required to deliver the message to the same server
(when you have multiple mx records)
No, the sender is (in general) required to try all MXs.
That can be fairly annoying if a domain has many MXs and
uses graylisting.
2. Is the sender required to use the same from (eg. no idea if @#$#@
like mailchimp change their from
bounce-mc.us5_10712807.8832082-dfaa67f206@mail154.atl121.mcsv.net)
The much more interesting question is whether you include the client
IP address in your graylisting DB -- because that can change.
On 4/6/22 8:42 AM, None wrote:
I am even receiving spam on mx hosts that I have removed from the dns,
they just archive this info somewhere.
This seems ... unexpected to me.
If you have multiple MXes at the same priority, they need to share
the greylist database.
For a while I tried a greylister that did 4xx at the end of data
and remembered a checksum of the message, and found that some bulk
mailers regenerate the message so it has new timestamps.
It's just a way to see whether a mail client knows how to retry
after a soft reject. Once it does that, there's no point in further greylisting the same source.
It's just a way to see whether a mail client knows how to retry
after a soft reject. Once it does that, there's no point in further
greylisting the same source.
I largely agree.
Though I do think that I'd put an upper bound on how long I'd retain
that state. -- I usually had my systems configured such that this >information was volatile and did not persist across daemon invocations.
I found that an additional turn through the grey list once every couple
of months wasn't a problem and didn't noticeably add to the overall
average delay.
It shouldn't be. For some reason many spambots have hard coded
obsolete lists of MXes built into them. I see a trickle of spam to
hosts that stopped being MXes years ago.
For a while I tried a greylister that did 4xx at the end of data and
remembered a checksum of the message, and found that some bulk mailers
regenerate the message so it has new timestamps.
So I decided to try and turn the blocking into grey listing, but the
sender is getting a greylist dsn with an api url to the mx host.
Just clicking the link will allow the message go thru on the next
attempt.
I would discourage relying on information from your SMTP delay actually
being surfaced back to the end user. I've found that such information frequently doesn't make it to the end user. Even when it does make it
to the end user, chances are quite good that they will not know what to
do with it.
So I decided to try and turn the blocking into grey listing, but the
sender is getting a greylist dsn with an api url to the mx host.
Just clicking the link will allow the message go thru on the next attempt.
That is a bad idea unless you want to find yourself widely blocked.
This sort of challenge-response nonsense was somewhat popular 20
years ago but I thought it was mostly eradicated by now.
My understanding is that the OP is returning custom error messages
during the initial SMTP transaction and /NOT/ sending independent challenge-response messages.
Most spam has forged return addresses, so you're sending those
challenges to random strangers who never sent you mail and will
correctly interpret your challenges as spam from you, and act
accordingly.
This sort of challenge-response nonsense was somewhat popular 20 years
ago but I thought it was mostly eradicated by now.
Indeed, indeed, I was actually wondering if there is a difference in how
4xx errors are being treated (in regards relaying this back to the
sender) Currently I am getting a notification after 4h. While 5xx are >instant.
The alternative would be storing the message locally, sending a 5xx
error with a link to allow the message archived thru.
According to None <hzcnjkx656@tormails.com>:
Indeed, indeed, I was actually wondering if there is a difference in how
4xx errors are being treated (in regards relaying this back to the
sender) Currently I am getting a notification after 4h. While 5xx are
instant.
Oh, OK. That's shooting yourself in the foot. Approximately nobody
notifies users about 4xx rejections unless they repeat long enough
(days) that the message times out.
The alternative would be storing the message locally, sending a 5xx
error with a link to allow the message archived thru.
I think that's shooting yourself in the other foot. If your rejection
shows up in a person's mailbox, they'll probably think it is a weird
phish and ignore it.
But a lot of entirely legit mail does not
come from people, like newsletters and order confirmations for
stuff you've bought. Those 5xx will be seen by nobody and the
mail will just disappear.
But a lot of entirely legit mail does not
come from people, like newsletters and order confirmations for
stuff you've bought. Those 5xx will be seen by nobody and the
mail will just disappear.
Yes that is a really weird concept "I can contact you, but you are not >allowed to contact me". I can't wait for the legislation where the >noreply@... stuff is being banned.
Um, you are aware of the difference between the envelope and the
message header, I hope?
Those 5xx rejection messages go to the envelope address. Every
discussion list hosted by Mailman or Sympa or LISTSERV sends the
bounces to a robot that tries to figure out what the problem was and
prune addresses that bounce consistently. Ditto any competent
bulk message or transaction system. That has nothing to do with the
address in the From header to which manual replies would be sent.
Indeed, indeed, I was actually wondering if there is a difference in how
4xx errors are being treated (in regards relaying this back to the
sender)
Currently I am getting a notification after 4h. While 5xx are instant.
The alternative would be storing the message locally, sending a 5xx
error with a link to allow the message archived thru.
Although I am clueless on how to re-initiate the process of delivery
from these stored emails. With the greylisting I can just wait for the
sender to solve this for me.
Indeed, looks like that. Even error codes about the amount of recipients being to high are not directly relayed back to the sender.
One would think that such required 'manual' alteration would be notified immediately. But I will try a few others.
From my experience I can not really conclude people are not reading the
error messages.
8--
Even if, I can't be blamed if someone else is failing to read something.
Next time they read it, when they want to get thru.
Yes that is a really weird concept "I can contact you, but you are not allowed to contact me". I can't wait for the legislation where the noreply@... stuff is being banned.
Companies/users that send from spamming networks, I offer ip
whitelisting (when they get dedicated ip), email address (envelope from) white listing, and now a link in a dsn.
I think that is quite a nice service towards people being cheap sending
via third rate services.
Yes. yes. Currently my reasons for using this are
- envelope should be route-able, from: idk (only skipped a bit through
these rfc's)
- most 'normal' email have an envelope = from:
- spf check results are already available
- automated systems (not made in India) are expecting errors there and
most likely have some sort of exception handling that tries to report something back (on a web interface).
I will have to test between these two. I am more and more thinking about dumping all the email traffic in something like prometheus/influx, so I
can compare and graph the results better over time.
On 4/9/22 5:46 AM, None wrote:
Yes. yes. Currently my reasons for using this areI believe the envelope sender is an opportunity to encode debugging information. E.g. VERP.
- envelope should be route-able, from: idk (only skipped a bit through these rfc's)
I believe that there are other SMTP options that are woefully under
used; ORCPT, notify, etc.
- most 'normal' email have an envelope = from:Maybe. Don't rely on it.
- spf check results are already availableI feel the need to state that there is a big difference in what happens during the SMTP transaction vs what happens after. Rejecting the
- automated systems (not made in India) are expecting errors there and
most likely have some sort of exception handling that tries to report something back (on a web interface).
message during the SMTP transaction leaves the responsibility with the sending system, thus putting it on the hook for undesirable behavior. Bouncing after accepting a message means that you are on the hook for
the undesirable behavior. -- Focus on what you can influence. Reject
at SMTP time if possible.
I will have to test between these two. I am more and more thinking about dumping all the email traffic in something like prometheus/influx, so II'll take John's statement one step further. I prefer it when the
can compare and graph the results better over time.
sending system (CRM et al.) is actually the SMTP client so that it has /direct/ visibility into things. Sometimes it's possible to learn
/more/ information /faster/ than having things loop through an
intermediate SMTP relay. Especially if the receiving system uses proper
or enhanced status codes.
--
Grant. . . .
unix || die
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 49:36:46 |
| Calls: | 6,711 |
| Calls today: | 4 |
| Files: | 12,243 |
| Messages: | 5,354,783 |
| Posted today: | 1 |