You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@issues.apache.org on 2011/04/21 02:48:29 UTC
[Bug 6575] New: Mail::SpamAssassin::Plugin::SPF does test From:
header
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
Summary: Mail::SpamAssassin::Plugin::SPF does test From: header
Product: Spamassassin
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Plugins
AssignedTo: dev@spamassassin.apache.org
ReportedBy: me@junc.org
this fails if From: and envelope sender is not equal, so how to make this
better ?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #3 from software+spamassassin@kd6lvw.ampr.org 2011-04-21 14:42:14 EDT ---
1) With modifications proposed in #6490, one needs to check
"Authentication-Results:" for SPF results as well (RFC 5451). (This
enhancement has not yet been committed - I don't have that ability). Note that
6490 also adds "SPF_NONE" as a valid condition.
2) If using an MTA with the milter interface (postfix or sendmail), I find that
such a header has NOT been actually added at the time that SA is run (called
during the SMTP DATA phase at EOM). The interface seems to apply changes and
additional headers AFTER SA has run, meaning that SA sees the unmodified
message. Therefore, adding the header will not help in this case.
What is proposed will work if SA is invoked after delivery; e.g. by procmail.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #5 from software+spamassassin@kd6lvw.ampr.org 2011-05-05 19:31:52 UTC ---
Good question. However, an SPF check can go forward if "Return-Path" is
present (since that is the envelope-from data). Also, some people specifically
disable the "Received-SPF"/"Authentication-Results" check because they consider
that as untrusted, especially for forwarded mail.
Although technically incorrect, I do feel that "from" (as a fallback to RP)
should be tested as in the plurality of e-mail, it will be correct. SPF
testing "from" will also catch the case where spam is forged in the headers to
be from the recipient, as those who do send messages to themselves will often
know where such messages will source and can designate an SPF string which will
detect such forgeries. Testing "from" is better than testing nothing.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #4 from Darxus <Da...@ChaosReigns.com> 2011-05-05 16:46:16 UTC ---
Should SPF tests require a Authentication-Results or Received-SPF header, and
get skipped if they don't exist, since SPF isn't intended to be used with the
>From header?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #7 from D. Stussy <so...@kd6lvw.ampr.org> ---
Sender-ID is not part of RFC 4408 and therefore not part of SPF. It is part of
RFC 4406 which the SpamAssassin community has rejected (or so is my
understanding). What is implemented is the pure form of SPF; nothing more.
Personally, the very idea that Microsoft tried to take someone else's idea
(despite the ultimate co-authorship of the RFC) and claim it as their own after
adding some additional operation (or corruption) is actually offensive and for
that reason alone is reason enough to reject any further exploration of the
concept.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
Darxus <Da...@ChaosReigns.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Darxus@ChaosReigns.com
--- Comment #2 from Darxus <Da...@ChaosReigns.com> 2011-04-21 12:19:19 EDT ---
The solution is to this problem is to do SPF at your MTA and insert the
Received-SPF: header, which I recently learned SA will use:
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_SPF.html#item_ignore_received_spf_header
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #9 from Benny Pedersen <me...@junc.eu> ---
i think using Mail::SPF and dropping Mail::SPF::Query will solve sender-id
testing as not tested anymore, can other confirm this ?
if so maybe make optional setting for enable or disable sender-id testing with
a warning not to turn it on unless trusted_networks is setup correct for all
ips that is forwarding emails ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
software+spamassassin@kd6lvw.ampr.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |software+spamassassin@kd6lv
| |w.ampr.org
--- Comment #1 from software+spamassassin@kd6lvw.ampr.org 2011-04-21 05:24:54 EDT ---
OK, but that's what is available in the message. The actual envelope data does
not necessarily get passed. Depending on the actual MTA => SA interface, the
envelope data may not be available, or it may be available and a dummy
"Return-Path: <_envelope_from_>" could be inserted (even if not a final
delivery). As this is MTA dependent, just how would you propose "fixing" it?
In my opinion, SPF checking should be at the MTA level directly (and during
SMTP at the "MAIL FROM" stage, while SA typically runs after the "DATA" state
-- at EOM or after SMTP message acceptance).
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
Benny Pedersen <me...@junc.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |me@junc.org
--- Comment #6 from Benny Pedersen <me...@junc.org> ---
Mail::SPF does not check Sender-ID, should it ?
sid-milter do check Sender-ID, but default settings its just add the AR header
here i use -r 5 mode in sid-filter without any problems at all, but i wish that
softfails was tempfailed in mta, so senders got time to resolve the spf record
in dns, as it is now none see the faults, and "you are the only one that have
the problem" :(
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6575] Mail::SpamAssassin::Plugin::SPF does test From: header
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6575
--- Comment #8 from Benny Pedersen <me...@junc.eu> ---
sender id is just what i like to get rid of in sa testing with spf, if spf test
does use from: then its sender id aware, this is why i started this bug
using pupolicyd-spf now and just wait to turn over to AR headers when sa can
handle this problem :)
after that problem is gone
--
You are receiving this mail because:
You are the assignee for the bug.