Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

Sender with multiple MTAs=delays for every message

Sender with multiple MTAs=delays for every message

2017-03-12 by Thomas Cameron

Hi, all -

With so many organizations using mail services like Google and Microsoft
and Amazon and the like, I am seeing more and more messages being
delayed by greylisting for *every* e-mail.

I had a mail conversation with someone today. They use some Amazon
hosted mail service. The first email came from [sender1] and was relayed
through ec2-54-153-11-11.us-west-1.compute.amazonaws.com. The second
mail came from [sender1] but from
ec2-54-153-22-22.us-west-1.compute.amazonaws.com, and so on. Every new
e-mail wound up coming through a different relay on Amazon.

What winds up happening is, EVERY new e-mail is delayed, often times
several hours because they don't retry in a timely fashion.

I'm definitely not a milter-greylist expert. Is there something I'm
missing? This is becoming more and more of a hassle every day.

Thanks!
Thomas

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-12 by Greg Troxel

"Thomas Cameron thomas.cameron@..." writes:
>
> I had a mail conversation with someone today. They use some Amazon
> hosted mail service. The first email came from [sender1] and was relayed
> through ec2-54-153-11-11.us-west-1.compute.amazonaws.com. The second
> mail came from [sender1] but from
> ec2-54-153-22-22.us-west-1.compute.amazonaws.com, and so on. Every new
> e-mail wound up coming through a different relay on Amazon.
>
> What winds up happening is, EVERY new e-mail is delayed, often times
> several hours because they don't retry in a timely fashion.

[This list has bad behavior with Reply-To and rewriting the sender....]

A few ideas:

* There's a notion of whitelisting address ranges that are inhabited by
  this kind of distributed retrying.

* In an age where greylisting is normal, it's buggy of a sender not to
  retry from the same address.  Good luck with that approach :-)

* Perhaps milter-greylist could by default or could be configured to
  consider hosts in the same /24 (not enough for your case) or /16 to be
  the same.

What I do is just add whitelist entries when I have trouble.

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-12 by Marcus Schopen

Hi,

Am Sonntag, den 12.03.2017, 11:54 -0400 schrieb Greg Troxel 
gdt@... [milter-greylist]:
"Thomas Cameron thomas.cameron@..." writes:
> >
> > I had a mail conversation with someone today. They use some Amazon
> > hosted mail service. The first email came from [sender1] and was relayed
> > through ec2-54-153-11-11.us-west-1.compute.amazonaws.com. The second
> > mail came from [sender1] but from
> > ec2-54-153-22-22.us-west-1.compute.amazonaws.com, and so on. Every new
> > e-mail wound up coming through a different relay on Amazon.
> >
> > What winds up happening is, EVERY new e-mail is delayed, often times
> > several hours because they don't retry in a timely fashion.

I've seen that too, especially with Amazon emails.

[This list has bad behavior with Reply-To and rewriting the sender....]
> 
> A few ideas:
> 
> * There's a notion of whitelisting address ranges that are inhabited by
>   this kind of distributed retrying.
> 
> * In an age where greylisting is normal, it's buggy of a sender not to
>   retry from the same address.  Good luck with that approach :-)

I like that idea :D

* Perhaps milter-greylist could by default or could be configured to
>   consider hosts in the same /24 (not enough for your case) or /16 to 
> be
>   the same.

check subnetmatch option, e.g.:

# all addresses within the same class C network are considered the same
subnetmatch /24

Ciao
Marcus

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-13 by manu@...

Thomas Cameron thomas.cameron@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> I'm definitely not a milter-greylist expert. Is there something I'm
> missing? This is becoming more and more of a hassle every day.

The sample config file comes with default whitelist containing blocks of
known mail farms. You can add the one missing: 

first mail comes from ec2-54-153-11-11.us-west-1.compute.amazonaws.com,
that resolves to 54.153.11.11. WHOIS database says this is
54.144.0.0/12, allocates to Amazon. Therefore you whitelist
54.144.0.0/12.

Second mail is from ec2-54-153-22-22.us-west-1.compute.amazonaws.com,
which resolves to 54.153.22.22 in the same netblock.

Of course if someone want to contribute an up-to-date list for the
sample config file, patch is welcome.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-13 by Thomas Cameron

On 03/12/2017 10:54 AM, Greg Troxel gdt@... [milter-greylist] wrote:
> 
> "Thomas Cameron thomas.cameron@..." writes:
>>
>> I had a mail conversation with someone today. They use some Amazon
>> hosted mail service. The first email came from [sender1] and was relayed
>> through ec2-54-153-11-11.us-west-1.compute.amazonaws.com. The second
>> mail came from [sender1] but from
>> ec2-54-153-22-22.us-west-1.compute.amazonaws.com, and so on. Every new
>> e-mail wound up coming through a different relay on Amazon.
>>
>> What winds up happening is, EVERY new e-mail is delayed, often times
>> several hours because they don't retry in a timely fashion.
> 
> [This list has bad behavior with Reply-To and rewriting the sender....]
> 
> A few ideas:
> 
> * There's a notion of whitelisting address ranges that are inhabited by
>   this kind of distributed retrying.

Unfortunately, I have other customers (and friends) who use outlook.com.
They have SCADS of outbound hosts:

mail-sn1nam02on0136.outbound.protection.outlook.com
mail-sn1nam02on0139.outbound.protection.outlook.com
mail-sn1nam01on0130.outbound.protection.outlook.com
mail-dm3nam03on0130.outbound.protection.outlook.com
mail-dm3nam03on0131.outbound.protection.outlook.com
mail-cys01nam02on0114.outbound.protection.outlook.com
mail-cys01nam02on0115.outbound.protection.outlook.com
...

A quick grep|sort|uniq through my maillog shows almost 500 hostnames
from protection.outlook.com having delivered e-mail to my tiny little
mail server!

> * In an age where greylisting is normal, it's buggy of a sender not to
>   retry from the same address.  Good luck with that approach :-)

It *does* retry the same message from the same address. The problem is,
if the person sends me 5 emails, they come from five different sending
MTAs. Each one starts the delay all over again, and I see delays like this:

X-Greylist: Delayed for 14:02:47 by milter-greylist-4.5.16
(mail-west.camerontech.com [104.131.155.84]); Sat, 11 Mar 2017 11:47:45
+0000 (UTC)

That is PER EMAIL, since each one seems to come from a different MTA.

> * Perhaps milter-greylist could by default or could be configured to
>   consider hosts in the same /24 (not enough for your case) or /16 to be
>   the same.

Well, these hosts seem to come from 104.47.32.x through 104.47.42.x. I
suppose I could whitelist all those subnets.

> What I do is just add whitelist entries when I have trouble.

I tired that. I tried:

list "whitelist domains" domain { \
     domain.tld \
}

racl whitelist list "whitelist domains"

But they are still delayed. I suppose I could also try

list "whitelist domains" domain { \
     domain.tld \
     outbound.protection.outlook.com \
}

racl whitelist list "whitelist domains"

But then I'm whitelisting EVERYTHING coming through outlook.com. I don't
know how smart that would be.

Thoughts?

RE: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-13 by Bruncsak, Attila

> Hi, all -
> 
> With so many organizations using mail services like Google and Microsoft
> and Amazon and the like, I am seeing more and more messages being
> delayed by greylisting for *every* e-mail.
> 
> I had a mail conversation with someone today. They use some Amazon
> hosted mail service. The first email came from [sender1] and was relayed
> through ec2-54-153-11-11.us-west-1.compute.amazonaws.com. The second
> mail came from [sender1] but from
> ec2-54-153-22-22.us-west-1.compute.amazonaws.com, and so on. Every
> new
> e-mail wound up coming through a different relay on Amazon.
> 
> What winds up happening is, EVERY new e-mail is delayed, often times
> several hours because they don't retry in a timely fashion.
> 
> I'm definitely not a milter-greylist expert. Is there something I'm
> missing? This is becoming more and more of a hassle every day.
> 
> Thanks!
> Thomas
> 

I am using this configuration before greylisting:

racl whitelist spf pass

The big providers with multi-host sending scheme normally 
has correct SPF records too.

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-13 by Emmanuel Dreyfus

On Sun, Mar 12, 2017 at 07:33:41PM -0500, Thomas Cameron thomas.cameron@... [milter-greylist] wrote:
> mail-sn1nam02on0136.outbound.protection.outlook.com
> mail-sn1nam02on0139.outbound.protection.outlook.com
> mail-sn1nam01on0130.outbound.protection.outlook.com
> mail-dm3nam03on0130.outbound.protection.outlook.com
> mail-dm3nam03on0131.outbound.protection.outlook.com
> mail-cys01nam02on0114.outbound.protection.outlook.com
> mail-cys01nam02on0115.outbound.protection.outlook.com

WHOIS says  104.40.0.0/13 is allocated to Microsoft, you
could whitlist all that space.
-- 
Emmanuel Dreyfus
manu@...

Re: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-13 by manu@...

'Bruncsak, Attila' attila.bruncsak@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> I am using this configuration before greylisting:
> racl whitelist spf pass

You never get SPF-enabled spam?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

RE: [milter-greylist] Sender with multiple MTAs=delays for every message

2017-03-14 by Bruncsak, Attila

> 
> > I am using this configuration before greylisting:
> > racl whitelist spf pass
> 
> You never get SPF-enabled spam?
> 
I may get. But it is working for me very reliably,
no complain from users about excessive delays
of ham e-mails due to multi-host senders.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.