Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
-- Jim Flowers jflowers@ezo.net
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same IP as its A record.
Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Implementing domainkeys I hear will require Exim be recompilled on the machine it needs to be used on too.
http://wiki.exim.org/DomainKeys
Matt
On Nov 28, 2007, at 11:06 AM, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same
IP as its A record.Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
My SPF record originally only had mx and my ip block (Which contains
all my servers). Had no problems for 2 years. A week or two ago a
user complained one domain (some programmers domain which I thought
was amusing) was rejecting based on SPF, and it turns out they only
worked with the 'a' listing in there. They were running Exchange..
Just an FYI.. cover all your bases :/
Rick
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same IP as its A record.
Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information.
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
-- Dean Brooks dean@iglou.com
(Dean, sorry you'll see this twice...I forget that the Dovecot list, unlike every other list I'm subscribed to, does not "reply to list" by default...)
Dean Brooks wrote:
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
-- Dean Brooks dean@iglou.com
Yes, but DomainKeys suffers from patent bloat and restrictive licensing, which is antithetical to the open-source ideals of projects such as Dovecot. ...thanks so much, Yahoo....
RobertC
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information.
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
Where does DKIM fit in all this? Could Exim compile it in without the license restrictions of domainkeys? I use Directadmin which is based on exim and dovecot.
http://wiki.exim.org/DomainKeys http://wiki.exim.org/DKIM
Matt
On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote:
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same
IP as its A record.Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
I disagree.
The only way you should be using SPF on the receiving end is as an
additional weight for spam scoring.
That covers forwarding, ddns home users, and misc other issues. Not
only can you not be assured that an email is sent from a particular
host, but you can't be assured everyone's upstream DNS has cached
your record properly. IMHO, to assume a DNS record is going to be
kept up to date and correct 100% of the time is just silly. By
requiring an exact match to prevent a rejection, those who do this
are risking many outright rejections which negatively affect their
perceived service levels.
Rick
On Wed, Nov 28, 2007 at 11:45:29AM -0600, Rick Romero wrote:
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
I disagree. The only way you should be using SPF on the receiving end is as an
additional weight for spam scoring.
Well, perhaps, but that's not how it was originally designed to be used. I don't disagree that it has devolved into just another spam scoring device though.
It's not even a very good one, since you can't easily determine if a message is simply being forwarded. As such, the score modifiers tend to be low.
-- Dean Brooks dean@iglou.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rick Romero wrote:
On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote:
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same IP as its A record.
Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring.
Some time ago there was a similar discussion on the postfix ML and I had pretty much the same arguments that you had.
But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve.
Udo Rader http://www.bestsolution.at
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFHTa6BuhFd84GLxP8RAh2uAJ43FN6z1DZkEP6Uun0CxnuA+iSukQCfcqiY bSBpLiK6MmDvahOLmYt0lTc= =zmqd -----END PGP SIGNATURE-----
On Nov 28, 2007, at 12:08 PM, Udo Rader wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rick Romero wrote:
On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote:
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the
same IP as its A record.Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys
on top of SPF. SPF pretty much does everything domainkeys does but
simpler.Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of
the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring.
Some time ago there was a similar discussion on the postfix ML and
I had pretty much the same arguments that you had.But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they
really do it!) is to register some new domain, enter valid SPF records for it
and then their scoring might even improve.
I only give negative points for non-matching records. No positive
points. (Unless I misconfigured something, that's how I believe -
and want - it to work).
The idea being that even if the record doesn't match, if it's a valid
email you won't have enough other negatively scoring components to
completely drop it.
If there is a negative match on spam then we're also compensating for
changes in the structure of the email that might get it past bayesian
filters.
If there is no record, or a positive match, then IMHO we're really
neither better nor worse off.
The 'spammers create domains' argument almost negates the sender
verification system entirely - assuming you're giving positive points
for any valid records.
Rick
Udo Rader http://www.bestsolution.at
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFHTa6BuhFd84GLxP8RAh2uAJ43FN6z1DZkEP6Uun0CxnuA+iSukQCfcqiY bSBpLiK6MmDvahOLmYt0lTc= =zmqd -----END PGP SIGNATURE-----
on 11/28/2007 10:08 AM Udo Rader spake the following:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rick Romero wrote:
On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote:
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring.
Some time ago there was a similar discussion on the postfix ML and I had pretty much the same arguments that you had.
But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve. That is why you don't score on pass, but incremental score on fails. That way a fail will bump the score a bit, but a pass won't negate the other hits.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve.
DKIM and domainkeys are really no better in that respect. Spammers typically do not go through that much effort though.
Matt
on 11/28/2007 10:46 AM Matt spake the following:
But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve.
DKIM and domainkeys are really no better in that respect. Spammers typically do not go through that much effort though.
Matt
I do see some benefit, at least for us. We get a lot of mail from a bank, but I cannot whitelist the bank by domain, because of phishing. So I either have to write some custom rules and experiment, whitelist each individuals address as they hit, or validate their domainkey and bump any scores back down enough to clear the filters. I think I will look at enabling the dkim plugin in spamassassin and see what happens.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matt wrote:
But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve.
DKIM and domainkeys are really no better in that respect. Spammers typically do not go through that much effort though.
yes, IMHO this entire sender verification thing (whatever that may be) is quite useless when it comes to prevent spamming but is quite useful when it comes to prevent phishing.
That's why we don't use it even for spam scoring anymore. It is not worth the resources, IMHO again at least :-)
Udo Rader http://www.bestsolution.at
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD4DBQFHTbkguhFd84GLxP8RAr8nAJdq02VRDE+jIHG8mF//lCgZAmBrAJ9s2hAC 1LfHpCBn1c86DJC86Fj5vw== =WYDo -----END PGP SIGNATURE-----
Dean Brooks wrote:
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same IP as its A record.
Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system.
One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler.
Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address.
SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway.
DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information.
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
I second that. I've wasted a lot of time with SPF and it's useless.
On Wed, Nov 28, 2007 10:14:31 AM -0800, Marc Perkel (marc@perkel.com) wrote:
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
I second that. I've wasted a lot of time with SPF and it's useless.
Maybe. Or maybe, more exactly, is useless to use, but it's necessary to have. The reality today is that if you manage a mail server you simply have to get your SPF right, no matter what you do or do not with SPF of _incoming_ messages. What the message that starts the thread means is that, if anybody with a @dovecot.org address (or any other domain address with the same SPF status) sends a CV to some dream company he'd like to work for, but the address he wrote is an hotmail one (or is forwarded to an hotmail one) that company will never see his CV and hire somebody else.
And there are too many people with an Hotmail account (and you not knowing they have an hotmail account) which you or your users may NEED to contact to ignore such cases.
Marco
Help *everybody* love Free Standards and Free Software http://digifreedom.net/
Hello,
M. Fioretti pisze:
On Wed, Nov 28, 2007 10:14:31 AM -0800, Marc Perkel (marc@perkel.com) wrote:
Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't.
I second that. I've wasted a lot of time with SPF and it's useless.
Maybe. Or maybe, more exactly, is useless to use, but it's necessary to have. The reality today is that if you manage a mail server you simply have to get your SPF right, no matter what you do or do not with SPF of _incoming_ messages. What the message that starts the thread means is that, if anybody with a @dovecot.org address (or any other domain address with the same SPF status) sends a CV to some dream company he'd like to work for, but the address he wrote is an hotmail one (or is forwarded to an hotmail one) that company will never see his CV and hire somebody else.
And there are too many people with an Hotmail account (and you not knowing they have an hotmail account) which you or your users may NEED to contact to ignore such cases.
I have heard the same arguments thousand times on various MTA-related lists. I thought this list was dedicated to dovecot and so maybe we could drop this thread? It does not seem dovecot-related and the thread
- as usual in such a case - is generating quite a heavy traffic.
Best regards,
Zbigniew Szalbot
Marco
I may be sorry I brought this up. There's nothing wrong with your TXT record. This server acts as a virus/spam processor for mail relayed from a legacy server (for historical reasons). It filters with MailScanner/SpamAssassin. Looking through the SpamAssassin debug code, it checks my relay as the 'Envelope-from' and fails on -all. Although the information is there, the SpamAssassin plugin isn't sophisticated enough to trace it back to the originating server.
And, yes - it assigns a minor score (default 0.69) for SPF_FAIL and I don't lose any digests as Bayes just overwhelms it.
As long as your unqualified domain name has an A record and a matching PTR record SPF should work just fine (as long as there aren't any relays in-between).
Sorry for any inconvenience. Thanks for your excellent project.
On Wed, 28 Nov 2007 17:28:32 +0200, Timo Sirainen wrote
On Wed, 2007-11-28 at 11:17 -0400, Jim Flowers wrote:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
Care to tell also why? dovecot.org's mails are sent from the same IP as its A record.
-- Jim Flowers jflowers@ezo.net
on 11/28/2007 10:49 AM jflowers spake the following:
I may be sorry I brought this up. There's nothing wrong with your TXT record. This server acts as a virus/spam processor for mail relayed from a legacy server (for historical reasons). It filters with MailScanner/SpamAssassin. Looking through the SpamAssassin debug code, it checks my relay as the 'Envelope-from' and fails on -all. Although the information is there, the SpamAssassin plugin isn't sophisticated enough to trace it back to the originating server.
Look at trusted_relays in spamassassin. http://wiki.apache.org/spamassassin/TrustedRelays
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
11/28/2007 7:17 AM Jim Flowers spake the following:
Your spf record is broken:
dovecot.org. 39942 IN TXT "v=spf1 a -all"
-- Jim Flowers jflowers@ezo.net
Checking to see if there is a valid SPF record.
Found v=spf1 record for dovecot.org v=spf1 a -all
evaluating... SPF record passed validation test with pySPF (Python SPF library)!on
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
participants (12)
-
Dean Brooks
-
jflowers
-
Jim Flowers
-
M. Fioretti
-
Marc Perkel
-
Matt
-
Rick Romero
-
Robert Cooper
-
Scott Silva
-
Timo Sirainen
-
Udo Rader
-
zbigniew szalbot