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 2010/05/06 18:30:10 UTC
[Bug 6430] New: Would it be good to consider like an MSA a trusted
relay authenticating a user?
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
Summary: Would it be good to consider like an MSA a trusted
relay authenticating a user?
Product: Spamassassin
Version: 3.3.1
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Libraries
AssignedTo: dev@spamassassin.apache.org
ReportedBy: g.tomassoni@libero.it
Created an attachment (id=4758)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4758)
This patch escalates an authenticating trusted relay to an MSA
When the SA deployment scenario is around a MX also acting as an MSA (like, in
example, in very simple sites), it is impossible to configure SA to trust the
whole relay chain only in case the user authenticated with the MX.
The msa_networks option can't be used in this case, because this way even the
non-authenticated messages arriving to the MX would be "trusted".
I am attaching here a patch against stock 3.3.1, which modifies the logic in
the Mail::SpamAssassin::Message::Metadata::Received class such that an
authenticating trusted MX would be considered like an MSA.
To me this mob seems ininfluent in the case in which one prefer to keep well
separate outgoing and ingoing message flows, in example by having a
well-defined set of trusted MXes for incoming mail, and a different set of MSAs
for accepting user mail for delivery.
However, the patch somehow puts a lot more "power" in the hands of the trusted
relays, which may possibly be debatable in some setups.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
Giampaolo Tomassoni <gi...@tomassoni.biz> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #4758|0 |1
is obsolete| |
--- Comment #4 from Giampaolo Tomassoni <gi...@tomassoni.biz> 2010-05-26 08:27:55 EDT ---
Created an attachment (id=4760)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4760)
Add msa_on_auth_networks setting
This patch fixes the possible problems introduced by the previous one, by not
changing the semantic of msa_networks, but instead adding a further setting:
msa_on_auth_networks.
Hosts and networks listed in the msa_on_auth_networks settings, will be
regarded as MSA iff they relay messages which they authenticate.
SA will regard them as trusted MXes when they are instead relaying messages
they receive not by an authenticated mean.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
Giampaolo Tomassoni <g....@libero.it> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |g.tomassoni@libero.it
--- Comment #2 from Giampaolo Tomassoni <g....@libero.it> 2010-05-07 03:23:59 EDT ---
(In reply to comment #1)
> I think this would cause problems for internal relays that use LMTPA.
Right, it may.
Another way may be to trigger the MSA bit when an authenticated protocol is
reported in the received header from nodes belonging to the msa_networks list,
but this way a new option would be needed (with appropriate default) in order
to break existing setups.
Something like "msa_requires_auth" or "msas_auth_user" with a default of "0"
would probably do the trick.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #3 from Giampaolo Tomassoni <g....@libero.it> 2010-05-07 03:25:18 EDT ---
(In reply to comment #2)
> Another way may be to trigger the MSA bit when an authenticated protocol is
> reported in the received header from nodes belonging to the msa_networks list,
> but this way a new option would be needed (with appropriate default) in order
> to break existing setups.
Of course, I meant "in order NOT to break existing setups."
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #1 from RW <rw...@googlemail.com> 2010-05-06 17:02:57 EDT ---
I think this would cause problems for internal relays that use LMTPA.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #7 from Mark Martinec <Ma...@ijs.si> 2011-04-04 10:50:12 EDT ---
> Mark, your patch is fine to me.
> But what if one is not using amavisd?
Tough luck then! :)
Now seriously: I'm ok with your patch, it does solve one additional
topology variation. Not sure how commonly such a setup would be useful,
perhaps when an external SOHO mailer is forwarding mail through a
company's MTA, or similarly for an internal (like departmental) MTA
doing the same, assuming it is using explicit authentication and not
relying on its internal network address (implicitly authenticating
by an internal IP address is way more common in such a scenario).
If others would find it useful, I'll give it my approval too. My concern
is that this whole business of internal / trusted / msa / msa_on_auth
is getting quite complicated and hard to understand, people even now
commonly just don't care to even configure internal/trusted properly,
and even with all these config options one still cannot cover some
mail flow topologies.
For example a setup where an internal (e.g. a departmental) small MTA
is forwarding/re-sending mail for its users to their external delivery
address passing them again through a central MTA running SpamAssassin
on their way out (I'll not go into argument about usefulness of outbound
spam filtering here). Currently there is no way (other than using an MSA)
to avoid DUL and similar blacklists on such messages, even though these
have been already spam-screened once on their way in to the site.
I guess I'll wait and see what others have to say on the matter.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #5 from Mark Martinec <Ma...@ijs.si> 2011-03-22 23:40:40 EDT ---
Giampaolo,
Not directly following your thoughts, but (assuming you are still
using amavisd) I'm suggesting the following simpler/smaller change,
which just allows the $originating flag as supplied by the caller
(amavisd in this case) be treated as an MSA submission. For example,
an authenticated roaming user using some nonstandard authentication
method (like pop-before-smtp) can be treated as authenticated
without having to insert such information into mail header section
and without a need to dedicated a separate mailer to act as an MSA.
(The $originating flag is being passed to SA since amavisd 2.7.0-pre12)
trunk:
Allow a caller-supplied 'originating' attribut be treated
as equivalent to submission via an MSA (as in msa_networks).
Sending lib/Mail/SpamAssassin/Message/Metadata/Received.pm
Committed revision 1084469.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #8 from Giampaolo Tomassoni <gi...@tomassoni.biz> 2011-04-04 13:20:08 EDT ---
(In reply to comment #7)
> > Mark, your patch is fine to me.
> > But what if one is not using amavisd?
> Tough luck then! :)
:)
> Now seriously: I'm ok with your patch, it does solve one additional
> topology variation. Not sure how commonly such a setup would be useful,
> perhaps when an external SOHO mailer is forwarding mail through a
> company's MTA, or similarly for an internal (like departmental) MTA
Though this patch I was attempting to address a problem rised by someone in the
list. Can't find it right now. I may search deeper if needed (it is more or
less one year old).
A possible usage case I can see is in all-in-one SOHO boxes.
That said, a work-around (at least with Amavis) is available. I agree with you
that probably usage numbers for this patch seems not high enough to justify the
burderns the maintenance of a new setting (the msa_on_auth_networks) may rise.
> I guess I'll wait and see what others have to say on the matter.
Ok. Lets see.
--
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 6430] Would it be good to consider like an MSA a trusted relay
authenticating a user?
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #6 from Giampaolo Tomassoni <gi...@tomassoni.biz> 2011-04-04 04:42:12 EDT ---
(In reply to comment #5)
Mark, your patch is fine to me.
But what if one is not using amavisd?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.