Bug 6430 - Would it be good to consider like an MSA a trusted relay authenticating a user?
Summary: Would it be good to consider like an MSA a trusted relay authenticating a user?
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 3.3.1
Hardware: All All
: P2 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-06 12:30 UTC by Giampaolo Tomassoni
Modified: 2011-04-04 13:20 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
This patch escalates an authenticating trusted relay to an MSA text/plain None Giampaolo Tomassoni [NoCLA]
Add msa_on_auth_networks setting patch None Giampaolo Tomassoni [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Giampaolo Tomassoni 2010-05-06 12:30:06 UTC
Created attachment 4758 [details]
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.
Comment 1 RW 2010-05-06 17:02:57 UTC
I think this would cause problems for internal relays that use LMTPA.
Comment 2 Giampaolo Tomassoni 2010-05-07 03:23:59 UTC
(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.
Comment 3 Giampaolo Tomassoni 2010-05-07 03:25:18 UTC
(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."
Comment 4 Giampaolo Tomassoni 2010-05-26 08:27:55 UTC
Created attachment 4760 [details]
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.
Comment 5 Mark Martinec 2011-03-22 23:40:40 UTC
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.
Comment 6 Giampaolo Tomassoni 2011-04-04 04:42:12 UTC
(In reply to comment #5)

Mark, your patch is fine to me.

But what if one is not using amavisd?
Comment 7 Mark Martinec 2011-04-04 10:50:12 UTC
> 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.
Comment 8 Giampaolo Tomassoni 2011-04-04 13:20:08 UTC
(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.