Re: [exim-dev] [Bug 2341] delay_warning failing to send mess…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Jasen Betts
Datum:  
To: exim-dev
Betreff: Re: [exim-dev] [Bug 2341] delay_warning failing to send messages
On 2018-12-05, Andrew C Aitchison via Exim-dev <exim-dev@???> wrote:
> On Wed, 5 Dec 2018, admin--- via Exim-dev wrote:
>
>> https://bugs.exim.org/show_bug.cgi?id=2341
>>
>> --- Comment #8 from Jeremy Harris <jgh146exb@???> ---
>> Thanks. It seems I'm on the right track; now we need to decide if that is
>> now too much notification... there's no per-sender tracking on this, it's
>> per-deferred message, so (as in your test) one sender will get a warning
>> for every message they send, repeated per the delay_warning setting
>> as modified by the queue run occasions.
>>
>> Leaving it like that will be simplest. I'll commit that for now, but opinions
>> on any need for additional control are welcom.
>
> Like David, I'd expect and want a message for every delayed message.
>
> However, if someone malicious finds a full mailbox, could they use it
> to amplify attacks on a third party ?
> On the face of it, sending an almost null message to the full mailbox
> could result in larger messages being sent to an innocent third-party.
> What happens when a message with multiple senders (is that reply-to or from)
> is delayed; does each one get a delay warning ?
>
> [ Am I giving too many hints to spammers by asking in a public list ? ]


NDRs go to the envelope sender, so they will bounce back to a single
address (per message), but there can be several "delayed" messages and
a single bounce (retry timeout exceeded) for each input, so that
provides small-scale amplification, until the timeout is reached,
after that no amplification.

where available SPF is one mitigation for this. It prevents the attacker
from forging the sender address.

--
When I tried casting out nines I made a hash of it.