SPF question (2)
SYS...@mx.isti.cnr.it
X-PMDF-SPF: (recv=mx2.isti.cnr.it, send-ip=209.85.200.173) Could not find a
valid SPF record
when the message came from:
Return-path: <xx...@gmail.com>
From: xxxxx <xx...@gmail.com>
and by
dig gmail.com txt I get
;; ANSWER SECTION:
gmail.com. 190 IN TXT "v=spf1 redirect=_spf.google.com"
and I have the following entry in the FROM_ACCESS table
TCP|*|25|*|*|SMTP|*|tcp_local|*@*|* $C$[PMDF_SPF_LIBRARY,spf_lookup,\
$1,$4@$5,$5,X-PMDF-SPF]$E
So, I suspect that there is something of wrong in my configuration.
Francesco
Hunter Goatley
> SPF ?
> TXT ?
SPF information is stored in a TXT record.
> and I have the following entry in the FROM_ACCESS table
> TCP|*|25|*|*|SMTP|*|tcp_local|*@*|* $C$[PMDF_SPF_LIBRARY,spf_lookup,\
> $1,$4@$5,$5,X-PMDF-SPF]$E
> So, I suspect that there is something of wrong in my configuration.
The second use of "$5" is not what you want. That parameter specifies
the domain name that appears in the Received-SPF: header and
designates the local system. What you have wouldn't cause what you're
seeing, but it would generated a header that would show, in this case,
"gmail.com" where it would normally show your hostname.
I tried your mapping on my VMS system and had no trouble performing
the lookup and getting the Received-SPF: header.
You may want to turn on PMDF debugging and define this environment
variable to get some SPF debugging output:
PMDF_SPF_LOOKUP_DEBUG 1
My ignorance of UNIX will show here, as I'm not sure how you define
that so that it's defined for the PMDF processes.
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goath...@GOATLEY.COM http://www.goatley.com/hunter/
Francesco Gennai
It could be useful to check if the source IP of an incoming
SMTP connection is one of the IP addresses (or also subnets)
of the hosts listed in the MX records for the domain in the "SMTP mail from:"
You could argue that this is possible (simply) by inserting the correct SPF record in
the source domain, and that there is no guarantee that a site uses the same
IP addresses to receive and to send messages, but it is also true
that if I get such match I could have a feeling that the incoming message
could not be a spam. This is particolary true when I trust the source
organization (and .... the source organization has no SPF records).
My question is:
- is it possible to have the above check (check if the incomig IP address
matches one IP address of the MX nodes) in PMDF also when the source domain
has no SPF records?
Francesco
> > Which are the DNS records that the PMDF SPF routine search for?
> > SPF ?
> > TXT ?
> SPF information is stored in a TXT record.
> > and I have the following entry in the FROM_ACCESS table
> > TCP|*|25|*|*|SMTP|*|tcp_local|*@*|* $C$[PMDF_SPF_LIBRARY,spf_lookup,\
> > $1,$4@$5,$5,X-PMDF-SPF]$E
> > So, I suspect that there is something of wrong in my configuration.
> The second use of "$5" is not what you want. That parameter specifies
Hunter Goatley
> SMTP connection is one of the IP addresses (or also subnets)
> of the hosts listed in the MX records for the domain in the "SMTP mail from:"
> but it is also true
> that if I get such match I could have a feeling that the incoming message
> could not be a spam.
Careful, there. That's one of the false impressions most people have
about SPF itself. A lot of people think that if the message passes
the SPF check, then it's not spam. That's not true at all. Spammers
were among the first sites to deploy SPF records. An SPF "pass" is
only meaningful when you know the domain and trust its SPF records.
The same thing would be true here: just because it comes from one of
the MX systems for the domain does *not* mean it's not spam.
> This is particolary true when I trust the source
> organization (and .... the source organization has no SPF records).
> My question is:
> - is it possible to have the above check (check if the incomig IP address
> matches one IP address of the MX nodes) in PMDF also when the source domain
> has no SPF records?
That's a feature that could be added; it's not there currently. I'll
look into it....
Thanks.
Francesco Gennai
> > SMTP connection is one of the IP addresses (or also subnets)
> > of the hosts listed in the MX records for the domain in the "SMTP mail from:"
> > but it is also true
> > that if I get such match I could have a feeling that the incoming message
> > could not be a spam.
> Careful, there. That's one of the false impressions most people have
> about SPF itself. A lot of people think that if the message passes
> the SPF check, then it's not spam. That's not true at all. Spammers
> were among the first sites to deploy SPF records. An SPF "pass" is
> only meaningful when you know the domain and trust its SPF records.
> The same thing would be true here: just because it comes from one of
> the MX systems for the domain does *not* mean it's not spam.
Yes, I know very well all of this, but it is always useful to clarify. Thanks.
Infact I was speaking about trusted sites (and... that I could have
a good feeling....), where for any reasons I'm not able to contact the admin
to ask for an SPF record addition.
So, in this cases I would prefer an higher risk to receive spam (from
site that I trust), but to reduce (next to 0) the risk to have false positive!
> > This is particolary true when I trust the source
> > organization (and .... the source organization has no SPF records).
> > My question is:
> > - is it possible to have the above check (check if the incomig IP address
> > matches one IP address of the MX nodes) in PMDF also when the source domain
> > has no SPF records?
> That's a feature that could be added; it's not there currently. I'll
> look into it....
That could be a good idea.
And I hope to see soon the enanchment... ;-)
Thanks,
Francesco
> Thanks.
Jeremy Begg
>A question about checking incoming messages that could involve SPF.
>
>It could be useful to check if the source IP of an incoming
>SMTP connection is one of the IP addresses (or also subnets)
>of the hosts listed in the MX records for the domain in the "SMTP mail from:"
My experience is that such a check is not worth the effort. A while ago I
prepared some PMDF mappings which did exactly this for a small selection of
domains which were common SPAM sources at the time. I manually determined
the MX records in advance and arranged for mail with sender address in one
of those domains to be checked against my pre-prepared table of MX hosts.
The results were that legitimate mail was coming from servers *other* than
those in the domains' MX lists, for some domains. (I can't recall now which
ones.)
This was all intended to block incoming SPAM and because it wasn't reliable
I dropped it. I suppose that if the source IP address *is* an MX host for
the domain you could trust that the mail has not been forged. It might
still be SPAM, however.
Regards,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
| "OpenVMS Systems Management & Programming" |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: jer...@vsm.com.au |
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
Hunter Goatley
> those in the domains' MX lists, for some domains. (I can't recall now which
> ones.)
That's not too surprising since MX records define systems capable of
receiving mail from a domain and don't have to have anything to do
with what systems can send outgoing mail. That's what SPF was
designed to address....
I can see adding some header that indicates that it didn't come from
an MX system, but you couldn't automatically judge the message based
on that, just as you can't automatically allow messages in because the
pass the SPF check.
But it could still be useful information to know, and could be useful
for certain trusted domains.
> This was all intended to block incoming SPAM and because it wasn't reliable
> I dropped it. I suppose that if the source IP address *is* an MX host for
> the domain you could trust that the mail has not been forged. It might
> still be SPAM, however.
Yes, exactly.
Francesco Gennai
> Hi Francesco,
> >A question about checking incoming messages that could involve SPF.
> >
> >It could be useful to check if the source IP of an incoming
> >SMTP connection is one of the IP addresses (or also subnets)
> >of the hosts listed in the MX records for the domain in the "SMTP mail from:"
> My experience is that such a check is not worth the effort. A while ago I
> prepared some PMDF mappings which did exactly this for a small selection of
> domains which were common SPAM sources at the time. I manually determined
> the MX records in advance and arranged for mail with sender address in one
> of those domains to be checked against my pre-prepared table of MX hosts.
> The results were that legitimate mail was coming from servers *other* than
> those in the domains' MX lists, for some domains. (I can't recall now which
> ones.)
I think there is a misunderstanding about what I was trying to do.
a) SPF can simply check to assure that a message is coming from
a declared authorized source.
The declaration is by a TXT DNS record (also if there was a try
to define an SPF record).
One possibility (one of the most simple) is to arbitrary assume
that the servers defined by MX records are also source servers
for a domain.
At this point we can say that they are "authorized server" for
the declared domain.
Such declaration is the hand of the source site and this means that all
the above information can be used by spammers.
b) if we want SPF be useful we need to introduce the concept of "trusted
source". How much I can believe that you are not a spammers?
That is a problem that SPF cannot solve....
SPF simply say "that source is authorized to send message for this domain".
c) at this point if you look at the spam filters as potential cause
of false positive, SPF (in some cases) could help to reduce such
problem.
I think that these cases are a little percentage of the "spam world",
but they are interesting.
For example, if I know that the organization acme (acme.com) has relationship
with my own organization, I could have the follwing scenario
- they (acme) don't have TXT (SPF) records,
- they have a simple config where the incoming server (MX) is
the same of outgoing server.
I can use SPF like mechanisms (or any other solution) to check that message from
acme.com come from the autorized source (MX server in this simple case).
Note that this assertion MUST be strictly related to a trusted domain
that I MUST literally insert in some place in the "mapping" rule.
The assertion doesn't mean that any message coming from an authorized
server (determined by some SPF like mechanism) is not spam.
Someone could note that I can get the same result by inserting approriate
allow entries in PMAS for messages coming from that source, but in this
case I should care (for example) when the remote organization
change the IP address of the mail server (or the name.. it depends
by what I was checking).
With SPF like mechanisms I haven't this problem, the remote organization
can change IP/name, but since I rely my check on the DNS information
I don't care about to change any rule. They (acme) need to change
DNS information if they want continue "to do e-mail"...
And, what when the organization changes are so that the IP
source of e-mail is not more the same to the incoming server?
There are at least two possibilities:
- if they have a correct TXT/SPF record I can continue rely on that
- if they haven't a TXT/SPF record I will go back in the situation
when the risk to have false positive was higher, since my system
will no more be able to recognize the authorized source of ACME
organization e-mail.
In few words:
I was trying to use SPF to reduce false positive on messages
coming from -->"well know, trusted"<-- organization.
I must literally insert the domain of such trusted organization in some
mapping rules.
No generic rules is possible, since doesn't (cannot!) exist a generic
mechanism to check if an organization is trusted :-) ;-)
Hope this help.
Regards,
Francesco
> This was all intended to block incoming SPAM and because it wasn't reliable
> I dropped it. I suppose that if the source IP address *is* an MX host for
> the domain you could trust that the mail has not been forged. It might
> still be SPAM, however.
> Regards,