Re: SPF and SMTP AUTH
Rene Caspari wrote: Yes, this seems to be the problem, for authentication we use an external daemon for pop-before-smtp. Exim (3.36 - I know, its extremely outdated :-) reads the database file for the IP to allow relaying. So there is no "authenticated" content in the Received-headers, but a new MX setup is in progress, because of that I will not resolve the problem with the old setup. The POPAuth plugin will easily resolve that problem for you if you're using a hash database like Sendmail's access.db for the pop-before-smtp database. If you stop to have a snack, you'll still be able to setup the plugin in under five minutes. Daryl
Re: SPF and SMTP AUTH
* Mark [2006-11-22 13:02]: > > -Original Message- > > From: Rene Caspari [mailto:[EMAIL PROTECTED] > > > > How can I configure spamassassin to do not recognize the > > dialin account as a mailserver? > > The better route, really, is to configure your MTA, mail.domain.tld, to > set "pass" for trusted mechanism you have in place (like SASL). Your MTA > would then generate a header like this: > > Received-SPF: pass (mail.domain.tld: 1.2.3.4 > is authenticated by a trusted mechanism > > In your current setup, it seems, you basically use "softfail" so as not > have to deal with rejects from (authenticated) dynamic relays; but > "softfail" was not really meant for that purpose, of course. > Yes, this seems to be the problem, for authentication we use an external daemon for pop-before-smtp. Exim (3.36 - I know, its extremely outdated :-) reads the database file for the IP to allow relaying. So there is no "authenticated" content in the Received-headers, but a new MX setup is in progress, because of that I will not resolve the problem with the old setup. Thx anyway. bye, rene -- · http://rene.ahrcas.net · Rene Caspari · GPG-KeyID: 0xCA40A793 · - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Petition gegen §35 (BWahlG), Stimmabgabe mit Wahlgeraeten: http://itc.napier.ac.uk/e-Petition/bundestag/view_signatures.asp?PetitionID=294
Re: SPF and SMTP AUTH
Mark wrote: -Original Message- From: Rene Caspari [mailto:[EMAIL PROTECTED] Sent: dinsdag 21 november 2006 12:09 To: users@spamassassin.apache.org Subject: SPF and SMTP AUTH I have a little problem with SPF: For domain.tld there is a SPF record, which says that mail.domain.tld is allowed to sending mails from [EMAIL PROTECTED] If I use mail.domain.tld with a dialin account by SMTP AUTH, spamassassin says SPF_SOFTFAIL because initially the mail was sent by the dialin account and not mail.domain.tld. How can I configure spamassassin to do not recognize the dialin account as a mailserver? The better route, really, is to configure your MTA, mail.domain.tld, to set "pass" for trusted mechanism you have in place (like SASL). Your MTA would then generate a header like this: Received-SPF: pass (mail.domain.tld: 1.2.3.4 is authenticated by a trusted mechanism In your current setup, it seems, you basically use "softfail" so as not have to deal with rejects from (authenticated) dynamic relays; but "softfail" was not really meant for that purpose, of course. Mark, his MTA isn't even checking SPF. Even if he were, it wouldn't help his SpamAssassin configuration. Daryl
RE: SPF and SMTP AUTH
> -Original Message- > From: Rene Caspari [mailto:[EMAIL PROTECTED] > Sent: dinsdag 21 november 2006 12:09 > To: users@spamassassin.apache.org > Subject: SPF and SMTP AUTH > > > I have a little problem with SPF: > > For domain.tld there is a SPF record, which says that > mail.domain.tld is allowed to sending mails from [EMAIL PROTECTED] > If I use mail.domain.tld with a dialin account by SMTP AUTH, > spamassassin says SPF_SOFTFAIL because initially the mail was > sent by the dialin account and not mail.domain.tld. > > How can I configure spamassassin to do not recognize the > dialin account as a mailserver? The better route, really, is to configure your MTA, mail.domain.tld, to set "pass" for trusted mechanism you have in place (like SASL). Your MTA would then generate a header like this: Received-SPF: pass (mail.domain.tld: 1.2.3.4 is authenticated by a trusted mechanism In your current setup, it seems, you basically use "softfail" so as not have to deal with rejects from (authenticated) dynamic relays; but "softfail" was not really meant for that purpose, of course. - Mark
Re: SPF and SMTP AUTH
On Tuesday 21 November 2006 12:07, Rene Caspari wrote: > Hi, > > I have a little problem with SPF: > > For domain.tld there is a SPF record, which says that mail.domain.tld is > allowed to sending mails from [EMAIL PROTECTED] > If I use mail.domain.tld with a dialin account by SMTP AUTH, > spamassassin says SPF_SOFTFAIL because initially the mail was sent by > the dialin account and not mail.domain.tld. OK, so domain.tld is your domain, mail.domain.tld is the MX for that domain as well as the MSA that receives outbound mail from dialin users, and SpamAssassin says SPF_SOFTFAIL of mail received by mail.domain.tld from dialin users? > How can I configure spamassassin to do not recognize the dialin account > as a mailserver? In that case it should work as long as SpamAssassin trusts mail.domain.tld *and* the MSA/MTA at mail.domain.tld adds a Received: line that correctly states that the client was authenticated. If possible, you can also list your dialin IP ranges in trusted_networks. See http://wiki.apache.org/spamassassin/DynablockIssues and http://wiki.apache.org/spamassassin/TrustPath. Please post the unobfuscated header of a mail that hit SPF_SOFTFAIL if you need more help. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp9ffanUpFd5.pgp Description: PGP signature