Mailing List Archive

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462

g.wagenknecht@planet-wagenknecht.de changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |g.wagenknecht@planet-
| |wagenknecht.de





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From chris@westnet.com 2004-03-29 07:58 -------
I posted the SMTH AUTH headers for sendmail. How hard would it be to have rules
for at least the major MTAs (sendmail, postfix, qmail, etc).

In configuration, a site useing SMTP AUTH would select their MTA. For sendmail
at least, the hostname of the AUTH machine is also necessary. Haveing that in
the rule makes each site's rule unique, and difficult to forge.

This would be a general form of the 'hack' I posted.

Is this a reasonable approach ?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From bugzilla.spamassassin.org@dale.us 2004-03-29 08:14 -------
This still won't fix the pop-before-smtp problem as it leaves no extra headers
and is still in quite widespread use. Can someone remind me why SA doesn't just
always skip scanning the first IP in Received when the notfirsthop flag is set?

Something like, skip scanning first hop unless it is the only other hop in the
message?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From jm@jmason.org 2004-03-29 11:26 -------
'Can someone remind me why SA doesn't just always skip scanning the first IP in
Received when the notfirsthop flag is set? Something like, skip scanning first
hop unless it is the only other hop in the message?'

That is *exactly* what it does -- and it will still produce FPs in this
situation. To recap, here's what this bug is describing

1. user authenticates with your MTA, from a dynamic IP address:
dynamic-pool.someisp.net

2. user submits a msg to an address @ your MTA: your-mta.you.net

3. your MTA scans the message, since the message is for delivery to a local user

4. the only Received hdr is one saying

Received: from dynamic-pool.someisp.net .... by your-mta.you.net

There are no other Received hdrs. By the rules of notfirsthop, we *HAVE* to use
that IP for the Dynablock lookup, as you yourself describe.

5. it hits.

(I think comment #2 is are not talking about this case. It sounds like some
REceived hdr format is not being parsed by SA -- which causes dynablock FPs.
But that is a different bug, if it is a bug -- no samples or header data was
posted, so I have no idea. *This* bug is about the SMTP AUTH thing!)


The correct response is to:

1. for the POP-before-SMTP case, allow SA to give bonus "nice" points to IPs
that have authed via POP, bug 3086. (If you're talking about POP-before-SMTP,
best to go there.)

2. match header data that indicates that the submitter used SMTP AUTH. That's
this bug. And I agree with Chris Candreva, we need more samples from the other
MTAs, and this may be a reasonable approach.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From quinlan@pathname.com 2004-03-29 12:42 -------
Subject: Re: detect SMTP AUTH to avoid dynablock FPs on legit msg submission

> 1. for the POP-before-SMTP case, allow SA to give bonus "nice" points
> to IPs that have authed via POP, bug 3086. (If you're talking about
> POP-before-SMTP, best to go there.)

Shouldn't it still be up to the MTA to tag the Received: line as
authorized? I suppose POP-before-SMTP could be done with some front-end
making the information unavailable to the MTA.

> 2. match header data that indicates that the submitter used SMTP AUTH.
> That's this bug. And I agree with Chris Candreva, we need more
> samples from the other MTAs, and this may be a reasonable approach.

If by (2), you mean we should just handle authorized hosts in one of the
following ways: trust them, don't include them in notfirsthop testing,
or consider them non-dynamic, then I agree.

Daniel





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From jm@jmason.org 2004-03-29 13:40 -------
Subject: Re: detect SMTP AUTH to avoid dynablock FPs on legit msg submission

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> 1. for the POP-before-SMTP case, allow SA to give bonus "nice" points
>> to IPs that have authed via POP, bug 3086. (If you're talking about
>> POP-before-SMTP, best to go there.)
>
>Shouldn't it still be up to the MTA to tag the Received: line as
>authorized? I suppose POP-before-SMTP could be done with some front-end
>making the information unavailable to the MTA.

That's how it is done currently -- there's several scripts that tail
the POP/IMAP logfile and update an access DB file.

>> 2. match header data that indicates that the submitter used SMTP AUTH.
>> That's this bug. And I agree with Chris Candreva, we need more
>> samples from the other MTAs, and this may be a reasonable approach.
>
>If by (2), you mean we should just handle authorized hosts in one of the
>following ways: trust them, don't include them in notfirsthop testing,
>or consider them non-dynamic, then I agree.

meaning don't include them in nfh testing.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAaJe7QTcbUG5Y7woRApnqAJ9ntutP9pMidkukeenV7dJdr9dD+QCgzuzs
PzWjhp0cBbDq0j/NYE0xaN8=
=JHdV
-----END PGP SIGNATURE-----





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From sidney@sidney.com 2004-03-29 14:22 -------
Why can't we have a configuration option that lists the local MTAs that only
accept mail from trusted clients? Then there would be no need to parse various
SMTP_AUTH indicators or do anything special for POP-before-SMTP, and it would
handle any other authorization method. The effect of the option would be to
disable the one Received header rule of notfirsthop when the MTA is in the list.

The simplest form of the option would be to accept all, i.e, disable the one
Received header header to notfirsthop. That would be used when the delivering
MTA does not accept unauthorized connections from outside the network.

This will not help if an ISP uses the same MTA to receive mail from other MTAs,
to receive mail from authorized clients, and to deliver the mail locally. But at
that point I would say it is their configuration problem. If they want a way to
distinguish between mail that arrives authenticated and mail that arrives
unauthenticated they should logically separate the server that they tell users
to use to send mail and the ones that their MX records point to.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From g.wagenknecht@planet-wagenknecht.de 2004-03-29 20:54 -------
Re comment 13:

You suggestions (especially the last paragraph) imply that everybody must have
two mailservers one for users and one for MX records. Do you really want to
force small companies with their own hosting and with only 10 users to buy a
second mailserver for this?





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From sidney@sidney.com 2004-03-29 21:43 -------
> force small companies [ ... ] to buy a second mailserver

I said they should _logically_ separate the servers. That can be done on one
computer with two ip address aliases on the same network interface. Or use one
ip address with an authentication method that uses a different port such as
using SMTP/TLS or a VPN instead of STARTTLS or POP-before-SMTP. This isn't just
a SpamAssassin issue. You use one ip address as your domain's public MX server,
and a different ip address as the authenticating mail relay for your
users/employees. That makes it trivially easy to separate handling of possible
outide spam from mail that your users send. If you use one ip address for both,
you have a difficult problem. If your setup is so small and low budget that you
cannot have two static ip addresses and you have to use STARTTLS or
POP-before-SMTP, you probably should be using your ISP's mail server as the MX
server for your domain, even if you want to do the bulk of the mail processing
on your own server. That indirection will also take care of this problem.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From jm@jmason.org 2004-03-29 23:16 -------
yeah - it's the addition of SMTP AUTH/POP-before-SMTP, without separation of
incoming and outgoing servers, that makes this hard.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From sidney@sidney.com 2004-03-29 23:47 -------
"Doctor, Doctor, it hurts when I do this"

"Then don't do that"

If using one server for three different functions makes it so difficult, I would
suggest that they separate the functions into separate (virtual) servers rather
than that SA get imperfectly kludged to look up temporary POP access ip
addresses and parse various SMTP/AUTH indicators.

Well, maybe I'm giving up too easily and somebody will come up with an elegant
solution to the problem.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From bugzilla.spamassassin.org@dale.us 2004-03-30 06:03 -------
"yeah - it's the addition of SMTP AUTH/POP-before-SMTP, without separation of
incoming and outgoing servers, that makes this hard."

Justin, if the servers *are* separate phyiscal servers and one of the above
methods is in use, how is it supposed to be configured? Should trusted_networks
not list the outgoing MTA? If it is listed in trusted_networks, it seems to
skip that hop too and still test the dynamic client.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From jm@jmason.org 2004-03-30 12:11 -------
'Justin, if the servers *are* separate phyiscal servers and one of the above
methods is in use, how is it supposed to be configured? Should trusted_networks
not list the outgoing MTA? If it is listed in trusted_networks, it seems to
skip that hop too and still test the dynamic client.'

With separate servers for incoming (MX) and outgoing (MSA), when an
authenticated user connects to the MSA, their mail is delivered to user accounts
without spam scanning being applied. Only messages arriving from unauth'd
internet clients are scanned.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.