On 2025-01-20 at 10:03:56 UTC-0500 (Mon, 20 Jan 2025 10:03:56 -0500) Steve Charmer <stevecharm...@gmail.com> is rumored to have said:
> spam emails sent by bots using Amazon SES servers are getting through > because i have amazonses.com in my whitelist due to several "important > / trusted companies" using amazon ses. > > How does this rule work, to separate the "Received: ", versus the "From: " ? SPF only is defined for the envelope sender address (RFC5321.MailFrom) and the EHLO/HELO domain name argument. Authentication of the From header address (RFC5322.From) can be done by DKIM. You can make SA trust authentication of a domain authenticated by either means (i.e. using either RFC5321.MailFrom or RFC5322.From) by using the welcomelist_auth directive instead of welcomelist_from_spf. You can authenticate the RFC5322.From only using DKIM with welcomelist_from_dkim. See "perldoc Mail::SpamAssassin::Conf" for the details. > > the header "From: " is NOT in my whitelist, > but the value of "Amazonses.com" IS IN my whitelist Amazon SES uses that domain in their RFC5321.MailFrom values (and in their EHLOs) so a listing of just that domain will cover all of their customers. > why is it using the value from the header "Received: " and not the > value from the header "From: " ? SPF is using the SMTP envelope sender address, formally called the RFC5321.MailFrom value, which is often but not always preserved in delivered mail in a "Return-Path" header and sometimes included in Received headers. In some cases (e.g. null-sender bounce messages) the domain name used in the introductory EHLO or HELO command of the SMTP session is checked, and that typically only appears in the Received header. SPF is only specified for use with those two sources, because it was designed to be very low-cost and operate in SMTP without parsing any any actual message data (e.g. headers) and so could spare the receiver the cost of actually receiving spam before rejecting it. That is not relevant to SpamAssassin EXCEPT that it means that there is no recognized way to use SPF with From headers and no one publishes SPF records expecting them to be applied to From headers, therefore we cannot use SPF against From headers. > how can I improve the spam filtering? In this case I would recommend reworking your 'welcomelist_from_spf' (or 'whitelist_from_spf' if your prefs are older) directives into 'welcomelist_from_dkim' or 'welcomelist_auth' that actually target the mail you want. For Amazon SES, you probably just want welcomelist_from_dkim directives for the specific sender domains, IF they sign their mail with DKIM. > headers: > -------------------------- > Received: from [54.240.4.1] (port=52099 > helo=a4-1.smtp-out.eu-west-1.amazonses.com) > by mail.eee.com with esmtp (Exim 4.86_2) > (envelope-from > <01020194838ad102-b7f40763-2fee-4834-935a-d1adfa2b0318-000...@eu-west-1.amazonses.com>) There's the RFC5321.MailFrom. > id 1tZqGT-0001qQ-Gq > for st...@eee.com; Mon, 20 Jan 2025 06:48:24 -0500 > > From: =?utf-8?Q?SUPPORT?= <unterstutz...@frizbiz.cycloid.io> > > > 24 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level > mail domains are different Check that. It is awfully high for anything that's not intended to be absolute. This rule is NOT one that should be anywhere near absolute, as it will hit nearly every mailing list of any sort (other than the ones people manage with their own mail clients.) > > -100 USER_IN_SPF_WELCOMELIST From: address is in the user's SPF > welcomelist It also may be helpful to reduce the power of that rule or to use the "default" variants of the welcomelist* directives which are weaker and can be overruled by an aggregate of other derogatory rule matches. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
