Re: [mailop] greylisting, SendGrid is deleting your mail

[John Levine via mailop]

It appears that Gellner, Oliver via mailop  said:
>> That occasionally happens, but since I whitelist any /24 that has 
>> successfully retried, it doesn't happen very much.
>
>I see, this looks like a better approach. Unfortunately many greylisting 
>implementations only whitelist senders for a few days or even
>less. Or they fail to sync connections across different MTAs / regions. 

There's an unfortunate tendency for people to imagine that if X is a
useful anti-spam measure, doing more X is better, which is usually wrong. 
Greylisting everything is worse than just greylisting unknown hosts, and
a 5 second greet pause delay works as well as 5 minutes.

My greylister remembers hosts for 90 days, on the theory that if they
haven't sent mail for three months, they probably won't send mail
ever. It also has a single daemon shared among all the MTAs to track
the retries and whitelist.

I recently added a greet pause for hosts subject to greylisting and I
have to admit it works pretty well. Most of the hosts that get the
pause are early talkers. It appears that nearly all hosts that aren't
also retry. If that continues to be true, I'll just ditch the retries
since the greet pause is less disruptive.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[Gellner, Oliver via mailop]

> On 24.06.2023 at 19:38 John Levine via mailop wrote:

> According to Gellner, Oliver via mailop :
>>
>>It matters if the greylisting takes place before or after RBL / domain
>>reputation checks. If the greylisting comes first, I could imagine that the 
>>connections from most of those bots would have been blocked anyway (with a 
>>5xx response code).

> No, this is after DNSBL checks, which catch about 85% of attempted 
> connections. Those get, ah, special handling.

>>and thereby introduces noticeable breakage into email communication. As
>>a commercial ESP I wouldn’t set it up. It’s annoying for the users when
>>they repeatedly have to wait for registration emails, order
>>confirmation with payment details, when they are on the phone with
>>someone and want to discuss a document, which just doesn’t arrive at
>>the other end, and so on. Let alone cases where messages aren’t
>>delivered at all,

> That occasionally happens, but since I whitelist any /24 that has 
> successfully retried, it doesn't happen very much.

I see, this looks like a better approach. Unfortunately many greylisting 
implementations only whitelist senders for a few days or even less. Or they 
fail to sync connections across different MTAs / regions. Example from the last 
hours (redacted):

2023-06-28 06:33 170.10.152.242 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 07:45 207.211.30.242 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 08:01 91.220.42.201 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 09:04 205.139.110.141 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 09:55 205.139.110.221 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:13 62.140.10.22 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:40 91.220.42.211 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:41 195.130.217.241 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:55 91.220.42.241 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 11:10 207.211.30.221 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'

It goes on like this every day, all day long. The second attempt then succeeds, 
but this is just braindead.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[John R Levine via mailop]

Do you have any idea how many of those would be tripped up by a
Postfix-style banner delay?


Good question. I've been meaning to add a greet pause but haven't yet
gotten around to it.


I got around to it and now do a greet pause before I greylist.  Most of 
the hosts on the Spamhaus BLs are early talkers but that's not a surprise 
and I wouldn't waste effort greylisting them.  Instead I accept the mail, 
reject at the end of data, and put it in the spamtrap to collect 
statistics.


After it runs for a while I'll see what the numbers look like

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting

[John Levine via mailop]

It appears that Al Iverson via mailop  said:
>I think John also said he's auto-whitelisting a bunch of stuff based
>on an initial pass, which is an automation step I surely wish I had.

If you greylist everything, that's going to be awful. After a host has
successfully retried once, there's no point in greylisting again.

I've heard people claim that they greylist for a long time in hope
that in the interim spammy hosts will appear on DNSBLs but that
seems like minimal benefit for a lot of damage.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting

[Al Iverson via mailop]

On Sun, Jun 25, 2023 at 3:33 AM ml+mailop--- via mailop
 wrote:
>
> On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote:
>
> > The question, however, is: will it ble..., erm, can one do without
> > greylisting?
>
> It would mean more spam is coming through - so for my case greylisting
> is not useless -- which was the unsubstantiated claim to which I
> replied.

Sounds a bit more like YMMV.

My typical spam problems at my personal domains didn't seem fazed by
greylisting. But I guess my personal experience is "unsubstantiated."

I think John also said he's auto-whitelisting a bunch of stuff based
on an initial pass, which is an automation step I surely wish I had.

Cheers,
Al Iverson


-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting

[ml+mailop--- via mailop]

On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote:

> The question, however, is: will it ble..., erm, can one do without
> greylisting?

It would mean more spam is coming through - so for my case greylisting
is not useless -- which was the unsubstantiated claim to which I
replied.

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting

[Carsten Schiefner via mailop]

Hi N.N. -

On 24.06.2023 21:57, ml+mailop--- via mailop wrote:

On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:

What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?


It isn't.

(it works fairly well for the way I'm using it...)


No doubts.

The question, however, is: will it ble..., erm, can one do without 
greylisting?


That at least is my experience.

I recently had to build my exim setup from scratch: without greylisting, 
when the former setup had it. Initially I have had plans to also deploy 
greylisting for the new setup, but eventually dropped these.


Because interestingly enough there has not been any noticable increase 
in spam influx. At all.


Disclaimer: I run a super small mail server compared to the setups being 
discussed here; a couple of hundred virtual email addresses, less than 
ten real accounts.


Cheers,

-C.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting

[ml+mailop--- via mailop]

On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:
> What if we just got to the heart of the matter and admitted that
> greylisting is useless 2023?

It isn't.

(it works fairly well for the way I'm using it...)

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[John Levine via mailop]

According to Gellner, Oliver via mailop :
>
>> On 24.06.2023 at 06:56 John Levine via mailop wrote:
>>
>> It appears that Al Iverson via mailop  said:
>>> What if we just got to the heart of the matter and admitted that
>>> greylisting is useless 2023?
>>
>> Because it's still quite useful if you do it sensibly.  Here's what my
>> logs say for the past two years, by number of IPs
>>
>> greylist but never retried: 13573
>> greylist and did retry: 9299
>>
>> whitelisted or previously retried: 6519
>>
>> More than half of the addresses I greylist never retry, and spot
>> checks of the logs show that's overwhelmingly bots.
>
>It matters if the greylisting takes place before or after RBL / domain 
>reputation checks. If the greylisting comes first, I could imagine that
>the connections from most of those bots would have been blocked anyway (with a 
>5xx response code).

No, this is after DNSBL checks, which catch about 85% of attempted
connections. Those get, ah, special handling.

>and thereby introduces noticeable breakage into email communication. As a 
>commercial ESP I wouldn’t set it up. It’s annoying for the users
>when they repeatedly have to wait for registration emails, order confirmation 
>with payment details, when they are on the phone with someone and
>want to discuss a document, which just doesn’t arrive at the other end, and 
>so on. Let alone cases where messages aren’t delivered at all,

That occasionally happens, but since I whitelist any /24 that has successfully 
retried,
it doesn't happen very much.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[John Levine via mailop]

It appears that Bill Cole via mailop  said:
>>  greylist but never retried: 13573
>>  greylist and did retry: 9299
>>
>>  whitelisted or previously retried: 6519
>>
>> More than half of the addresses I greylist never retry, and spot
>> checks of the logs show that's overwhelmingly bots.
>
>Do you have any idea how many of those would be tripped up by a 
>Postfix-style banner delay?

Good question. I've been meaning to add a greet pause but haven't yet
gotten around to it.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[Bill Cole via mailop]

On 2023-06-24 at 00:49:46 UTC-0400 (24 Jun 2023 00:49:46 -0400)
John Levine via mailop 
is rumored to have said:


It appears that Al Iverson via mailop  said:

What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?


Because it's still quite useful if you do it sensibly.  Here's what my
logs say for the past two years, by number of IPs

 greylist but never retried: 13573
 greylist and did retry: 9299

 whitelisted or previously retried: 6519

More than half of the addresses I greylist never retry, and spot
checks of the logs show that's overwhelmingly bots.


Do you have any idea how many of those would be tripped up by a 
Postfix-style banner delay?




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[Gellner, Oliver via mailop]

> On 24.06.2023 at 06:56 John Levine via mailop wrote:
>
> It appears that Al Iverson via mailop  said:
>> What if we just got to the heart of the matter and admitted that
>> greylisting is useless 2023?
>
> Because it's still quite useful if you do it sensibly.  Here's what my
> logs say for the past two years, by number of IPs
>
> greylist but never retried: 13573
> greylist and did retry: 9299
>
> whitelisted or previously retried: 6519
>
> More than half of the addresses I greylist never retry, and spot
> checks of the logs show that's overwhelmingly bots.

It matters if the greylisting takes place before or after RBL / domain 
reputation checks. If the greylisting comes first, I could imagine that the 
connections from most of those bots would have been blocked anyway (with a 5xx 
response code).

I’m writing „most“, as surely greylisting does block spam messages which would 
otherwise not have been caught, but as with every antispam measure one has to 
weigh its benefits and costs, especially false positives. Unfortunately 
greylisting tends to have a lot of false positives and thereby introduces 
noticeable breakage into email communication. As a commercial ESP I wouldn’t 
set it up. It’s annoying for the users when they repeatedly have to wait for 
registration emails, order confirmation with payment details, when they are on 
the phone with someone and want to discuss a document, which just doesn’t 
arrive at the other end, and so on. Let alone cases where messages aren’t 
delivered at all, as can be seen in this thread or in the one just a few days 
old: „Strange mail delivery from microsoft“ (although the temporary errors in 
this thread might be due to maintenance work or some software errors, I‘m not 
sure).

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[John Levine via mailop]

It appears that Al Iverson via mailop  said:
>What if we just got to the heart of the matter and admitted that
>greylisting is useless 2023? 

Because it's still quite useful if you do it sensibly.  Here's what my
logs say for the past two years, by number of IPs

 greylist but never retried: 13573
 greylist and did retry: 9299

 whitelisted or previously retried: 6519

More than half of the addresses I greylist never retry, and spot
checks of the logs show that's overwhelmingly bots.

I suspect that Sendgrid's problem is that they gush so much spam that
mail systems have cranked the spam filters way up, so they run into
delivery problems that better behaved mail systems don't have. I have
a bunch of special rules that whitelist a modest set of known good
return addresses and report most of the rest as spam to them, for what
little good that does.

R's,
John



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[John Levine via mailop]

According to Alessandro Vesely via mailop :
>> That update quite deliberately did *not* make changes that were incompatible 
>> with decades of existing practice.  Forcing large mail farms to send 
>> retries 
>> from the same IP would be a significant and painful change which means that 
>> in 
>> practice they would have ignored it.
>
>RFC 6647 came in 2012.

True, but so what?  Section 4.1 specifically describes the issue of retries
from different IPs and section five recommends that greylisters fuzz the
sending IP to deal with it.



-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Alessandro Vesely via mailop]

On Wed 21/Apr/2021 23:48:10 +0200 John R Levine via mailop wrote:

On Wed, 21 Apr 2021, Peter Nicolai Mathias Hansteen wrote:

SMTP was defined in the late 1970s and we didn't invent greylisting
until about 2003. I don't think you can blame them for not being
clairvoyant.


No clairvoyance was required for taking account of greylisting in the 2008 
update that the article was about, but you’re probably right in a largish 
chunk of cases about this bit:


That update quite deliberately did *not* make changes that were incompatible 
with decades of existing practice.  Forcing large mail farms to send retries 
from the same IP would be a significant and painful change which means that in 
practice they would have ignored it.



RFC 6647 came in 2012.

Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Dave Warren via mailop]

On 2021-04-21 13:34, John Levine via mailop wrote:

It appears that Peter Nicolai Mathias Hansteen via mailop  
said:

Greylisting implementations tend to expect retries to come from the same IP 
address as the original one. Some of us are still quite cross that
the writers-of-RFCs did not care to make that a MUST requirement (see [1] for 
my grumble on that from a while back).

SMTP was defined in the late 1970s and we didn't invent greylisting
until about 2003. I don't think you can blame them for not being
clairvoyant.

I find that fuzzing the IP addresses to anything in the same ipv4 /24
or ipv6 /64 handles most of the different IP retries without letting
any more spam through.


I also just ignore the IP completely for mail marked as SPF:PASS. A 
quick and easy way to let the sender define what IPs they use and I 
don't need to worry about the outbound IP changing.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[John R Levine via mailop]

On Wed, 21 Apr 2021, Peter Nicolai Mathias Hansteen wrote:

SMTP was defined in the late 1970s and we didn't invent greylisting
until about 2003. I don't think you can blame them for not being
clairvoyant.


No clairvoyance was required for taking account of greylisting in the 2008 
update that the article was about, but you’re probably right in a largish chunk 
of cases about this bit:


That update quite deliberately did *not* make changes that were 
incompatible with decades of existing practice.  Forcing large mail farms 
to send retries from the same IP would be a significant and painful change 
which means that in practice they would have ignored it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Peter Nicolai Mathias Hansteen via mailop]

> 21. apr. 2021 kl. 21:34 skrev John Levine via mailop :
> 
> It appears that Peter Nicolai Mathias Hansteen via mailop  
> said:
>> Greylisting implementations tend to expect retries to come from the same IP 
>> address as the original one. Some of us are still quite cross that
>> the writers-of-RFCs did not care to make that a MUST requirement (see [1] 
>> for my grumble on that from a while back).
> 
> SMTP was defined in the late 1970s and we didn't invent greylisting
> until about 2003. I don't think you can blame them for not being
> clairvoyant.

No clairvoyance was required for taking account of greylisting in the 2008 
update that the article was about, but you’re probably right in a largish chunk 
of cases about this bit:

> I find that fuzzing the IP addresses to anything in the same ipv4 /24
> or ipv6 /64 handles most of the different IP retries without letting
> any more spam through.

Cheers,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[John Levine via mailop]

It appears that Peter Nicolai Mathias Hansteen via mailop  
said:
>Greylisting implementations tend to expect retries to come from the same IP 
>address as the original one. Some of us are still quite cross that
>the writers-of-RFCs did not care to make that a MUST requirement (see [1] for 
>my grumble on that from a while back).

SMTP was defined in the late 1970s and we didn't invent greylisting
until about 2003. I don't think you can blame them for not being
clairvoyant.

I find that fuzzing the IP addresses to anything in the same ipv4 /24
or ipv6 /64 handles most of the different IP retries without letting
any more spam through.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Peter Nicolai Mathias Hansteen via mailop]

> 21. apr. 2021 kl. 12:23 skrev Neil Youngman via mailop :
>> 
> 
> It doesn't behave exactly like a normal mail server, but it does retry
> more than five times. Not all retries are from the same IP, but I have
> observed that retries from the same IP don't get delivered.

That may be the exact source of the problem.

Greylisting implementations tend to expect retries to come from the same IP 
address as the original one. Some of us are still quite cross that the 
writers-of-RFCs did not care to make that a MUST requirement (see [1] for my 
grumble on that from a while back).

If you can’t guarantee that, please consider letting the retries run for a 
reasonable amount of time, at least a few days.

Some of us have bent over backwards to compensate for those failures by 
introducing mechanisms to whitelist hosts that appear in known sites’ SPF 
records and a few other tricks (see [2]].

[1] 
https://bsdly.blogspot.com/2008/10/ietf-failed-to-account-for-greylisting.html 

[2] https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 


All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Chris via mailop]

Retrying from a different IP is exactly the wrong thing to do to a
greylisting implementation.  Despite the fact that I know a number of
ESPs do this.

Basic greylisting is to tempfail the first attempt from a given IP of
the "same email", because almost all spambots try once and give up.

The implementor can "embellish" that with all sorts of additional
heuristics - automatically identify "good ips", and allow them in
without greylisting, identify "bad ips", and turn it into a blacklisting
with (effectively) tarpitting, identify bad ranges ("all trying to send
me the same failed-greylisting shit!") etc.

Some mail systems are like sysadmins who are in turn like grizzly bears
- poke them too many times they get annoyed, even if you're offering
them yummy raw meat. As I've been telling senders for years, if your
mailer behaviour causes the MTA's, let alone the sysadmin's notice,
you've lost already.

At this point I can only suggest figuring out whether it's "just you" or
not, by trying to send someone there an email from somewhere completely
unrelated.

Then try to contact their sysadmin.


On 2021-04-21 06:23, Neil Youngman via mailop wrote:
> On 21/04/2021 11:00, Chris wrote:
>> Aside from the possibility that the message is simply wrong, or the
>> implementation broken, is your mail server acting like most other
>> servers when presented with a failure (soft or hard)?
>>
>> Your posting seems to be that you give up after the second try.
>>
>> Most servers will try at least 5 times for such, only giving up after
>> hours (sendmail defaults at 4 days).
> 
> It doesn't behave exactly like a normal mail server, but it does retry
> more than five times. Not all retries are from the same IP, but I have 
> observed that retries from the same IP don't get delivered.
> 
> Neil Youngman
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Heiko Schlittermann via mailop]

Stuart Henderson via mailop  (Mi 21 Apr 2021 14:38:14 CEST):
> On 2021/04/21 12:55, Tim Bray via mailop wrote:
> > Like fire up an exim?
> 
> This exim?
> https://www.openwall.com/lists/oss-security/2021/04/21/1
> 
> "The current Exim versions (and likely older versions too) suffer from
> several exploitable vulnerabilities. These vulnerabilities were reported
> by Qualys via secur...@...m.org back in October 2020.
> 
> Due to several internal reasons it took more time than usual for the Exim
> development team to work on these reported issues in a timely manner."

Maybe I should have added, that none of the reported vulnerabilites (and
possible exploits) are publicly known yet, to the best of our and the
reporter's knowledge.

-- 
Heiko


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Stuart Henderson via mailop]

On 2021/04/21 10:23, Neil Youngman via mailop wrote:
> On 21/04/2021 11:00, Chris wrote:
> > Aside from the possibility that the message is simply wrong, or the
> > implementation broken, is your mail server acting like most other
> > servers when presented with a failure (soft or hard)?
> > 
> > Your posting seems to be that you give up after the second try.
> >
> > Most servers will try at least 5 times for such, only giving up after
> > hours (sendmail defaults at 4 days).
> 
> It doesn't behave exactly like a normal mail server, but it does retry
> more than five times. Not all retries are from the same IP, but I have 
> observed that retries from the same IP don't get delivered.
> 
> Neil Youngman

Retries from different IPs (even within the same /24 or so) will
certainly cause problems for some greylisting software.

Also make sure the addresses used in SMTP are identical for each try
(say, not changing the sender address etc.)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Stuart Henderson via mailop]

On 2021/04/21 12:55, Tim Bray via mailop wrote:
> Like fire up an exim?

This exim?

https://www.openwall.com/lists/oss-security/2021/04/21/1

"The current Exim versions (and likely older versions too) suffer from
several exploitable vulnerabilities. These vulnerabilities were reported
by Qualys via secur...@...m.org back in October 2020.

Due to several internal reasons it took more time than usual for the Exim
development team to work on these reported issues in a timely manner."

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Tim Bray via mailop]

On 21/04/2021 11:23, Neil Youngman via mailop wrote:

It doesn't behave exactly like a normal mail server, but it does retry
more than five times. Not all retries are from the same IP, but I have
observed that retries from the same IP don't get delivered.



Can you just deliver to a normal mailserver for problem domains and see 
what happens?


Like fire up an exim?

Tim

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Neil Youngman via mailop]

On 21/04/2021 11:00, Chris wrote:
> Aside from the possibility that the message is simply wrong, or the
> implementation broken, is your mail server acting like most other
> servers when presented with a failure (soft or hard)?
> 
> Your posting seems to be that you give up after the second try.
>
> Most servers will try at least 5 times for such, only giving up after
> hours (sendmail defaults at 4 days).

It doesn't behave exactly like a normal mail server, but it does retry
more than five times. Not all retries are from the same IP, but I have 
observed that retries from the same IP don't get delivered.

Neil Youngman


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Neil Youngman via mailop]

On 20/04/2021 11:00, Hans-Martin Mosner wrote:
>> Normally I would expect the retries to pass greylisting. Does anyone have
>> any insight into why this is not behaving as expected? The destination is
>> exeter.ac.uk.
>>
>> Neil Youngman
> The exeter.ac.uk postmaster is probably the only one who can tell you what 
> really happens, but as with all spam-reducing
> heuristics it is quite possible that this system is somehow broken.

I tried the exeter.ac.uk postmaster, but got no response.

I agree that it is probably simply broken. Sometimes it's helpful to be
able to identify the failure mode, particularly if it is in a system 
that is used elsewhere.

> Another possibility, which would for example apply to the mail systems for 
> which I'm responsible, is that temp rejection
> is used to defer mail from questionable sources until a manual check shows 
> that they're likely genuine (or in some
> cases, until a rbl hit indicates that others received the mail and 
> categorized it as spam). In this case, we wouldnt
> talk about greylisting in the error message, though, as that is misleading.

If something is causing our mail to be flagged as questionable that would
also be worth knowing. 

This one of those questions where I don't expect to get a definite
answer, but I might still learn something valuable from the discussion.

Neil Youngman


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Dave Warren via mailop]

On 2021-04-20 03:24, Hans-Martin Mosner via mailop wrote:

Another possibility, which would for example apply to the mail systems for 
which I'm responsible, is that temp rejection
is used to defer mail from questionable sources until a manual check shows that 
they're likely genuine (or in some
cases, until a rbl hit indicates that others received the mail and categorized 
it as spam). In this case, we wouldnt
talk about greylisting in the error message, though, as that is misleading.


Never hurts to remember that some of us are jerks when it comes to 
providing clues to spammers too.


Back when I was running a small hosting company I would try to report 
the least significant DNSBL hit in the rejection message when in reality 
there was a more complex scoring system at play, and resolving that 
listing would do nothing more than give you a new (but also valid) DNSBL 
hit on your next attempt.


It wasn't misleading, technically, but by the time an IP tripped the 
scoring system to an outright reject before even seeing the message body 
it was pretty certain they were living in a sewer anyway, so why not let 
senders work their way up?


There was also a link to generate a whitelisting request for the odd bit 
of legitimate mail.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Chris via mailop]

Aside from the possibility that the message is simply wrong, or the
implementation broken, is your mail server acting like most other
servers when presented with a failure (soft or hard)?

Your posting seems to be that you give up after the second try.

Most servers will try at least 5 times for such, only giving up after
hours (sendmail defaults at 4 days).

In fact, if you're giving up in a unusually low number of retries (like
just one), that may cause your IP to be penalized in some way -
increasing retries you need to do OR outright blacklisting - but getting
a 4xx simply because the code handling greylisting only answers in one
way, and the permanently blocked by the greylisting code gets the same
answer as greglisting proceeding as intended.


On 2021-04-20 05:06, Neil Youngman via mailop wrote:
> I have observed that messages from our system are temporarily rejected
> as greylisted by one destination but they are never accepted on retry.
> The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
> for 5 minutes". We retry after 10 minutes and get the same response.
> 
> Normally I would expect the retries to pass greylisting. Does anyone have
> any insight into why this is not behaving as expected? The destination is
> exeter.ac.uk.
> 
> Neil Youngman
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Heiko Schlittermann via mailop]

Neil Youngman via mailop  (Di 20 Apr 2021 11:06:10 CEST):
> I have observed that messages from our system are temporarily rejected
> as greylisted by one destination but they are never accepted on retry.
> The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
> for 5 minutes". We retry after 10 minutes and get the same response.

That is 451 as the response to the "DATA" command? Or to the final dot, after
the DATA beeing sent?

The mentioned 1 recipient was the only recipient? Then I'd ask why they
do not reject the individual recipient with 4xx already at the RCPT
phase, or, if they do, why - after having a rejected recipient, your
server tries to send DATA.

In case they're greylisting after the final dot, make sure that not only
the IP, the sender, and the recipients list are identical to the first
attempt, but also the DATA (header+body) of your message.

I think, this will be difficult, if possible at all. Depends on *your*
mailsystem. And of course on their processing of the header+body.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Paul Smith via mailop]

On 20/04/2021 10:06, Neil Youngman via mailop wrote:


I have observed that messages from our system are temporarily rejected
as greylisted by one destination but they are never accepted on retry.
The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
for 5 minutes". We retry after 10 minutes and get the same response.

Normally I would expect the retries to pass greylisting. Does anyone have
any insight into why this is not behaving as expected? The destination is
exeter.ac.uk.
exeter.ac.uk's email administrator is probably the only one who can say 
for certain. Anything else is a guess.


Make sure the retried message is from exactly the same return path email 
address AND IP address as the originally tried message. If either of 
these is different, the receiving server could think that it's a new 
message, so it will start a new greylist delay for that message.


Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Hans-Martin Mosner via mailop]

Am 20.04.21 um 11:06 schrieb Neil Youngman via mailop:
> I have observed that messages from our system are temporarily rejected
> as greylisted by one destination but they are never accepted on retry.
> The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
> for 5 minutes". We retry after 10 minutes and get the same response.
>
> Normally I would expect the retries to pass greylisting. Does anyone have
> any insight into why this is not behaving as expected? The destination is
> exeter.ac.uk.
>
> Neil Youngman

The exeter.ac.uk postmaster is probably the only one who can tell you what 
really happens, but as with all spam-reducing
heuristics it is quite possible that this system is somehow broken.

Another possibility, which would for example apply to the mail systems for 
which I'm responsible, is that temp rejection
is used to defer mail from questionable sources until a manual check shows that 
they're likely genuine (or in some
cases, until a rbl hit indicates that others received the mail and categorized 
it as spam). In this case, we wouldnt
talk about greylisting in the error message, though, as that is misleading.

Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Greylisting never passing on retry

[Neil Youngman via mailop]

I have observed that messages from our system are temporarily rejected
as greylisted by one destination but they are never accepted on retry.
The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
for 5 minutes". We retry after 10 minutes and get the same response.

Normally I would expect the retries to pass greylisting. Does anyone have
any insight into why this is not behaving as expected? The destination is
exeter.ac.uk.

Neil Youngman


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop