I think this would cause problems for internal relays that use LMTPA.

(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.

(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."

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.

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.

(In reply to comment #5)

Mark, your patch is fine to me.

But what if one is not using amavisd?

> 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.

(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.