Re: [exim-dev] [Bug 2341] delay_warning failing to send messages
On 2018-12-05, Andrew C Aitchison via 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 --- >> 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 Git Commit changed: What|Removed |Added CC||g...@exim.org --- Comment #10 from Git Commit --- Git commit: https://git.exim.org/exim.git/commitdiff/de6f74f297d040a34746bc8e1829ad4b867441c9 commit de6f74f297d040a34746bc8e1829ad4b867441c9 Author: Jeremy Harris AuthorDate: Wed Dec 5 16:09:01 2018 + Commit: Jeremy Harris CommitDate: Wed Dec 5 17:09:00 2018 + send delay-mdn for any queurun past delay_warning, even if not retry time yet. bug 2341 doc/doc-txt/ChangeLog|8 +- src/src/deliver.c| 54 +- src/src/macros.h |2 + src/src/retry.c | 21 +- test/confs/0098 | 16 + test/log/0098| 16 + test/mail/0098.CALLER| 63 ++ test/rejectlog/0098 |3 + test/runtest |2 +- test/scripts/-Basic/0098 | 19 + test/stderr/0275 |4 +- test/stderr/0278 |4 +- test/stderr/0357 | 15 +- test/stderr/0358 | 14 +- test/stderr/0361 | 12 +- test/stderr/0386 |8 +- test/stderr/0388 |8 +- test/stderr/0402 | 20 +- test/stderr/0403 |4 +- test/stderr/0404 | 2436 +- test/stderr/0408 |4 +- test/stderr/0487 |4 +- test/stderr/0529 | 10 +- test/stderr/0554 |7 +- test/stderr/2600 |4 +- test/stderr/2610 |4 +- test/stderr/2620 |4 +- test/stderr/5004 |4 +- test/stderr/5005 | 16 +- test/stderr/5006 |4 +- test/stdout/0098 |2 + 31 files changed, 1479 insertions(+), 1313 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #9 from David Carter --- I think that the new behaviour is fine. Each warning message contains summary information: The message identifier is: 1gUXhL-0007kL-sO The date of the message is:Wed, 05 Dec 2018 13:58:43 + The subject of the message is: Test message and full headers about the specific message in question. I imagine that senders would get confused if they only received notifications for a subset of the messages that they sent. For example in an "Over quota" situation small messages may still be delivered even when large ones get stuck. 20+ messages from a single sender in a short time is a pathological test case. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #8 from Jeremy Harris --- 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. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #7 from David Carter --- Okay, I installed a patched version of Exim 4.91 onto a spare mailhub and tweaked the delay_warning configuration: delay_warning = 1h:4h:8h:24h:30d I then sent 26 test messages to a local account which has run out of quota. An hour later I received precisely 26 warning messages, almost all of which immediately followed a "retry time not reached" warning: 2018-12-05 14:59:00 + 1gUXhU-0007lX-pk == x...@hermes.cam.ac.uk routing defer (-51): retry time not reached Only a single actual delivery attempt on that particular queue run. So that definitely looks like an improvement. Is there anything else that you would like me to test? -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #6 from Jeremy Harris --- (In reply to David Carter from comment #5) > The deliver.c part of your patch appears to apply cleanly against a vanilla > Exim 4.91 tarball: > Would that be a useful test? Yes; please do. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #5 from David Carter --- I'm a bit nervous about running current master (and I would have to rejig my build scripts). The deliver.c part of your patch appears to apply cleanly against a vanilla Exim 4.91 tarball: patching file src/deliver.c Hunk #1 succeeded at 5840 with fuzz 1 (offset -45 lines). Hunk #2 succeeded at 6557 (offset -51 lines). Hunk #3 succeeded at 6580 (offset -51 lines). Hunk #4 succeeded at 6592 (offset -51 lines). Hunk #5 succeeded at 6617 (offset -51 lines). Hunk #6 succeeded at 6671 (offset -51 lines). Hunk #7 succeeded at 7006 (offset -51 lines). Hunk #8 succeeded at 7975 (offset -55 lines). Hunk #9 succeeded at 8002 (offset -55 lines). Hunk #10 succeeded at 8125 (offset -55 lines). Would that be a useful test? -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
