On 11/18/24 9:08 AM, Michael Richardson wrote:
The message about the spam was in fact spam.
But, it forged a valid From: so it got through.
I'd like to fix the SPF/DKIM/spam-filter such that it more aggressively kills
this kind of forgery, assuming that wireshark.org has the right policies set.
--- Begin Message ---
On 18/11/2024 21:55, Guy Harris wrote:
> On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote:
>
>> The message about the spam was in fact spam.
>
> So what is the purpose of those types of spam? Testing a list's spam
> detectors?
The sender may have sent an infected do
On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote:
> The message about the spam was in fact spam.
So what is the purpose of those types of spam? Testing a list's spam detectors?
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
On Nov 18, 2024, at 12:15 PM, Michael Richardson wrote:
> Denis Ovsienko wrote:
>> One complication here is that in some cases libpcap may not be aware of
>> a device capability until it gets an error from the OS (as is the case
>> with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findall
On Nov 18, 2024, at 11:54 AM, Denis Ovsienko wrote:
> The current approach in libpcap is such that an application at some
> point tries to activate a device, and if the device does not support
> capturing packets, pcap_activate() fails with the
> PCAP_ERROR_CAPTURE_NOTSUP error code. One drawbac
The message about the spam was in fact spam.
But, it forged a valid From: so it got through.
I'd like to fix the SPF/DKIM/spam-filter such that it more aggressively kills
this kind of forgery, assuming that wireshark.org has the right policies set.
This kind of thing is fraught with false-positiv
Denis Ovsienko wrote:
> One complication here is that in some cases libpcap may not be aware of
> a device capability until it gets an error from the OS (as is the case
> with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findalldevs()
> would not be able to set "this device
