You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Peter Matulis <pe...@yahoo.ca> on 2004/12/14 05:55:03 UTC
consensus on SPF
Hi, I have heard that SPF is controversial among mail administrators. Why is that? How many
people use it (on this mailing list)?
Peter
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
Re: consensus on SPF
Posted by Nate Carlson <na...@natecarlson.com>.
On Tue, 14 Dec 2004, Yassen Damyanov wrote:
> Why not configure your MTA to relay mail ONLY on encrypted authenticated
> sessions, and deliver locally (after some anti-spam checks) on plain
> sessions, all this done at port 25?
The subject at hand is getting SPF working for providers that block port
25; this won't help in that case. I'd have to hope that people who have
SPF set up would also only allow encrypted, authenticated sessions to send
mail to the 'net at large with their servers. :)
------------------------------------------------------------------------
| nate carlson | natecars@natecarlson.com | http://www.natecarlson.com |
| depriving some poor village of its idiot since 1981 |
------------------------------------------------------------------------
Re: consensus on SPF
Posted by Codger <li...@pmbx.net>.
Sorry, but this is not true. Eudora uses also 465.
On Dec 15, 2004, at 4:58 PM, Morris Jones wrote:
> David B Funk wrote:
>> Eudora will not let you set any port other than 25 for outgoing SMTP.
>
> Hopefully these will be fixed soon. I just guessed at the
> configuration for my wife's Mac running Eudora, and set the outgoing
> mailserver to mail.whiteoaks.com:587 and it worked fine.
>
> Best regards,
> Mojo
>
Kindest regards,
Ron
The men and women of our great country, whose service or
whose heart for an oppressed and weak people has led to
the altar of final sacrifice, cry out loudly declaring
freedom a treasured right, not a privileged commodity.
These are true heroes.
Re: consensus on SPF
Posted by Morris Jones <mo...@whiteoaks.com>.
David B Funk wrote:
> Eudora will not let you set any port other than 25 for outgoing SMTP.
Hopefully these will be fixed soon. I just guessed at the configuration
for my wife's Mac running Eudora, and set the outgoing mailserver to
mail.whiteoaks.com:587 and it worked fine.
Best regards,
Mojo
--
Morris Jones
Monrovia, CA
http://www.whiteoaks.com
Old Town Astronomers: http://www.otastro.org
Re: consensus on SPF
Posted by Tony Finch <do...@dotat.at>.
On Wed, 15 Dec 2004, David B Funk wrote:
> On Wed, 15 Dec 2004, Christopher X. Candreva wrote:
> >
> > Depoly SPF, use the submission port to talk to your own mail server, problem
> > solved.
Although that allows you to support roaming users, SPF still breaks mail
forwarding. It's usable as a SpamAssassin check, perhaps, but not as the
sole reason for SMTP-time rejection (despite what SPF fanatics claim).
> Total agreement with this, but try to actually deploy it, client issues
> galore.
You have to support both STARTTLS on port 587 and TLS-on-connect (the
old-style nonstandard SMTPS) on port 465. In Exim:
daemon_smtp_ports = 25 : 465 : 587
tls_on_connect_ports = 465
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: SOUTHWEST
VEERING WEST 7 OR GALE 8, OCCASIONALLY SEVERE GALE FORCE 9 FOR A TIME. RAIN OR
SHOWERS. MODERATE OR GOOD. ROUGH.
Re: consensus on SPF
Posted by "Christopher X. Candreva" <ch...@westnet.com>.
On Wed, 15 Dec 2004, David B Funk wrote:
> Total agreement with this, but try to actually deploy it, client issues
> galore.
> Eudora will not let you set any port other than 25 for outgoing SMTP.
Technically you can, but effectively you are right since they make you jump
through hoops to do so. You have to move a file called literraly 'esoteric'
from an extrastuf directory to the main install. We found the procedure on
their site, and also have it in our support base.
http://friday.westnet.com/faq/article.php?id=012
And the truely bizzare thing is -- it used to be there by default, and they
actually took it out.
> Outlook will let you set an alternate SMTP port but if you do it breaks
> TLS. etc...
I use this as another way to convince people to move away from Outlook. :-)
-Chris
==========================================================
Chris Candreva -- chris@westnet.com -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/
Re: consensus on SPF
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 15 Dec 2004, Christopher X. Candreva wrote:
> On Tue, 14 Dec 2004, jdow wrote:
>
> > > Why not configure your MTA to relay mail ONLY on encrypted authenticated
> > > sessions, and deliver locally (after some anti-spam checks) on plain
> > > sessions, all this done at port 25?
[snip..]
> Actually, port 25 is NOT supposed to be used for an end-user client to
> submit mail to a server. Port 587 was designated the submission port some
> time ago, and should be used for all end-user to SMTP server connections.
>
> This is WHY port 25 is being blocked or redirected.
>
> Depoly SPF, use the submission port to talk to your own mail server, problem
> solved.
Total agreement with this, but try to actually deploy it, client issues
galore.
Eudora will not let you set any port other than 25 for outgoing SMTP.
Outlook will let you set an alternate SMTP port but if you do it breaks
TLS. etc...
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: consensus on SPF
Posted by "Christopher X. Candreva" <ch...@westnet.com>.
On Tue, 14 Dec 2004, jdow wrote:
> > Why not configure your MTA to relay mail ONLY on encrypted authenticated
> > sessions, and deliver locally (after some anti-spam checks) on plain
> > sessions, all this done at port 25?
>
> Setup an alternative mailer port for your machine on a different port
> number?
Actually, port 25 is NOT supposed to be used for an end-user client to
submit mail to a server. Port 587 was designated the submission port some
time ago, and should be used for all end-user to SMTP server connections.
This is WHY port 25 is being blocked or redirected.
Depoly SPF, use the submission port to talk to your own mail server, problem
solved.
==========================================================
Chris Candreva -- chris@westnet.com -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/
Re: consensus on SPF
Posted by jdow <jd...@earthlink.net>.
From: "Yassen Damyanov" <yd...@troyer.co.at>
> On Tuesday 14 December 2004 15:52, Clarke Brunt wrote:
> >
> > You can set up your own SMTP server which listens on an alternative port
(to
> > avoid redirection of 25), and allows relaying for _authenticated_
> > connections, then arrange to submit _all_ your mail through it. Then
your
> > SPF record will always match. Of course it might not be practical, when
'on
> > the road', to configure all your email clients to use authenticated SMTP
> > through an unusual port.
>
> Why not configure your MTA to relay mail ONLY on encrypted authenticated
> sessions, and deliver locally (after some anti-spam checks) on plain
> sessions, all this done at port 25?
Setup an alternative mailer port for your machine on a different port
number?
> I don't know about other MTAs but postfix 2.1 allows this setup. If
anyone's
> inretested, I can post a config file that implements this.
Please do.
{^_^}
Re: consensus on SPF
Posted by Yassen Damyanov <yd...@troyer.co.at>.
On Tuesday 14 December 2004 15:52, Clarke Brunt wrote:
>
> You can set up your own SMTP server which listens on an alternative port (to
> avoid redirection of 25), and allows relaying for _authenticated_
> connections, then arrange to submit _all_ your mail through it. Then your
> SPF record will always match. Of course it might not be practical, when 'on
> the road', to configure all your email clients to use authenticated SMTP
> through an unusual port.
Why not configure your MTA to relay mail ONLY on encrypted authenticated
sessions, and deliver locally (after some anti-spam checks) on plain
sessions, all this done at port 25?
I don't know about other MTAs but postfix 2.1 allows this setup. If anyone's
inretested, I can post a config file that implements this.
Yassen Damyanov
Re: consensus on SPF
Posted by jdow <jd...@earthlink.net>.
From: "Clarke Brunt" <cl...@yeomannavigation.co.uk>
> jdow wrote:
> > Even more to the point SPF is NOT a reason to accept or reject mail.
> > All it does is verify the domain from which it originated. That is a
> > tool for SCORING spam not for outright elimination of messages that
> > have bad SPF records and accepting those that have good SPF records.
> > It is perfectly legitimate for a spammer to build his own SPF record
> > and get approved by such mal-configured tools. All the SPF record
> > does is give you confidence of the veracity of one hop in the chain.
>
> I agree that a 'pass' result from an SPF test does nothing to show that a
> message isn't spam (so I go on the use SpamAssassin on it), but it seems
to
> me that a 'fail' result is a perfectly good reason to reject a message
> outright, which is what I do (without it even being passed to
SpamAssassin).
>
> After all, a 'fail' result means that the owner of the domain from which
the
> message purports to come has gone to some trouble to set up an SPF record
> saying "mail from my domain will only ever arrive at your mail server
> directly from the following list of servers..., please feel free to reject
> any which pretends to be from my domain but which comes from _other_
> servers". It's more than "one hop in the chain" - it's the _last_ hop,
from
> _somewhere_ to my mail server, the one that I can be certain of without
> looking at headers, because I can _see_ what IP address is talking to my
> server.
We've just had one of the cases wherein a failed SPF record is no help
at all float by our eyes. Rejecting on one single criterion is generally
a bad idea. SPF in itself does not prove a whole lot due to the way ISPs
set themselves up. The chief thing SPF does is clutter up name server
traffic to prove something of little or no use when scoring spam.
Now, if we all had a nice government imposed encrypted stamp to place
on our email to validate it would even that prove squat?
(In the mobile user's case, however, he could help make his SPF more
meaningful and everyone else's if he tunneled email in through a
secure route even as relatively insecure as smtp auth on a port other
than 25. A ppp tunnel to his system'd work even better if slower.)
{^_^}
Re: consensus on SPF
Posted by David Brodbeck <gu...@gull.us>.
Tony Finch wrote:
>On Tue, 14 Dec 2004, Clarke Brunt wrote:
>
>
>>it seems to me that a 'fail' result is a perfectly good reason to reject
>>a message outright, which is what I do (without it even being passed to
>>SpamAssassin).
>>
>>
>
>How many users do you have? Do none of them have vanity addresses?
>
>
I would say it's the job of the person setting up the SPF record to
worry about that. You're just following their instructions.
Re: consensus on SPF
Posted by Tony Finch <do...@dotat.at>.
On Tue, 14 Dec 2004, Clarke Brunt wrote:
>
> it seems to me that a 'fail' result is a perfectly good reason to reject
> a message outright, which is what I do (without it even being passed to
> SpamAssassin).
How many users do you have? Do none of them have vanity addresses?
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: SOUTHWEST 4 OR 5. RAIN
AT TIMES. MODERATE OR POOR. MODERATE.
Re: consensus on SPF
Posted by Clarke Brunt <cl...@yeomannavigation.co.uk>.
jdow wrote:
> Even more to the point SPF is NOT a reason to accept or reject mail.
> All it does is verify the domain from which it originated. That is a
> tool for SCORING spam not for outright elimination of messages that
> have bad SPF records and accepting those that have good SPF records.
> It is perfectly legitimate for a spammer to build his own SPF record
> and get approved by such mal-configured tools. All the SPF record
> does is give you confidence of the veracity of one hop in the chain.
I agree that a 'pass' result from an SPF test does nothing to show that a
message isn't spam (so I go on the use SpamAssassin on it), but it seems to
me that a 'fail' result is a perfectly good reason to reject a message
outright, which is what I do (without it even being passed to SpamAssassin).
After all, a 'fail' result means that the owner of the domain from which the
message purports to come has gone to some trouble to set up an SPF record
saying "mail from my domain will only ever arrive at your mail server
directly from the following list of servers..., please feel free to reject
any which pretends to be from my domain but which comes from _other_
servers". It's more than "one hop in the chain" - it's the _last_ hop, from
_somewhere_ to my mail server, the one that I can be certain of without
looking at headers, because I can _see_ what IP address is talking to my
server.
Sure: the spammers can get proper domains and set up SPF records resulting
in 'pass', but then we just reject their junk with SpamAssassin in the usual
way. But most spammers just continue to invent email addresses of innocent
people in their "MAIL FROM" commands, and provided that 'innocent domain'
has published SPF, then I'm pleased to see my mail server rejecting lots of
such junk as soon as the "MAIL FROM" is given - they never even get to
transmit the body of the message.
--
Clarke Brunt
Re: consensus on SPF
Posted by jdow <jd...@earthlink.net>.
From: "Clarke Brunt" <cl...@yeomannavigation.co.uk>
> Jonathan Nichols wrote:
> > I scrapped SPF, actually. Found that certain providers, such as
> > T-Mobile, re-direct & intercept outbound port 25 traffic, making SPF
> > more of a pain in the neck.
> >
> > Example: I try to send mail to this list from a T-Mobile Hotspot
> > (Starbucks) - it gets kicked back because SF.net uses SPF, and my SPF
> > records don't show m55415454.tmodns.net in the SPF records. So what can
> > I do? Add all of t-mobile to my SPF records? What happens next time
> > something like that occurs?
> >
> > In the end it was just easier to back off of SPF for now.. maybe later..
>
> Indeed, if you have to send mail while 'on the road', through other
people's
> servers (bearing in mind that some providers might redirect port 25), then
> publishing SPF for your own domain which rejects mail from these servers
is
> to be avoided!
Even more to the point SPF is NOT a reason to accept or reject mail.
All it does is verify the domain from which it originated. That is a
tool for SCORING spam not for outright elimination of messages that
have bad SPF records and accepting those that have good SPF records.
It is perfectly legitimate for a spammer to build his own SPF record
and get approved by such mal-configured tools. All the SPF record
does is give you confidence of the veracity of one hop in the chain.
{^_^}
Re: consensus on SPF
Posted by David Brodbeck <gu...@gull.us>.
On Tue, 14 Dec 2004 13:52:37 -0000, Clarke Brunt wrote
> Jonathan Nichols wrote:
> > Example: I try to send mail to this list from a T-Mobile Hotspot
> > (Starbucks) - it gets kicked back because SF.net uses SPF, and my SPF
> > records don't show m55415454.tmodns.net in the SPF records. So what can
> > I do? Add all of t-mobile to my SPF records? What happens next time
> > something like that occurs?
> You can set up your own SMTP server which listens on an alternative
> port (to avoid redirection of 25), and allows relaying for _authenticated_
> connections, then arrange to submit _all_ your mail through it. Then
> your SPF record will always match. Of course it might not be
> practical, when 'on the road', to configure all your email clients
> to use authenticated SMTP through an unusual port.
Isn't this what the "submission" port is for? 583, or something like that?
Re: consensus on SPF
Posted by Clarke Brunt <cl...@yeomannavigation.co.uk>.
Jonathan Nichols wrote:
> I scrapped SPF, actually. Found that certain providers, such as
> T-Mobile, re-direct & intercept outbound port 25 traffic, making SPF
> more of a pain in the neck.
>
> Example: I try to send mail to this list from a T-Mobile Hotspot
> (Starbucks) - it gets kicked back because SF.net uses SPF, and my SPF
> records don't show m55415454.tmodns.net in the SPF records. So what can
> I do? Add all of t-mobile to my SPF records? What happens next time
> something like that occurs?
>
> In the end it was just easier to back off of SPF for now.. maybe later..
Indeed, if you have to send mail while 'on the road', through other people's
servers (bearing in mind that some providers might redirect port 25), then
publishing SPF for your own domain which rejects mail from these servers is
to be avoided!
I've only dared end my SPF records with ~all so far (i.e. softfail), which
is unlikely to cause anyone to reject mail outright.
If the providers you are posting through happen to publish SPF records
themself, then you could use an 'include' in your own record. e.g. I've got
'include:ntlworld.com' in mine. But this isn't very satisfactory, as you are
(a) relying on SPF records which are out of your control, and (b) allowing
any spammers who might also use ntlworld to spoof mail from you.
You can set up your own SMTP server which listens on an alternative port (to
avoid redirection of 25), and allows relaying for _authenticated_
connections, then arrange to submit _all_ your mail through it. Then your
SPF record will always match. Of course it might not be practical, when 'on
the road', to configure all your email clients to use authenticated SMTP
through an unusual port.
But all the above is concerned with publishing your _own_ SPF record.
Whether or not you set up your own, I don't see why you shouldn't check
other people's. If someone goes to the trouble of publishing an SPF record
which specifically says "reject mail which purports to come from me, but
which doesn't come from the following servers...", then rejecting such mail
seems appropriate. If it really is genuine mail from them, then they'll get
the bounce which usually includes an explanation of what's wrong with their
SPF record.
--
Clarke Brunt
Re: consensus on SPF
Posted by Jonathan Nichols <jn...@pbp.net>.
Clarke Brunt wrote:
>>Hi, I have heard that SPF is controversial among mail administrators. Why
>
> is that? How many
>
>>people use it (on this mailing list)?
>
>
> It's certainly not a simple subject: anyone who isn't familiar see
> http://spf.pobox.com/
>
> So long as you're careful, and realise that mistakes might precent mail
> getting through (whether yours, or your ability to receive other people's),
> then it seems to me to be a _good thing_.
>
I scrapped SPF, actually. Found that certain providers, such as
T-Mobile, re-direct & intercept outbound port 25 traffic, making SPF
more of a pain in the neck.
Example: I try to send mail to this list from a T-Mobile Hotspot
(Starbucks) - it gets kicked back because SF.net uses SPF, and my SPF
records don't show m55415454.tmodns.net in the SPF records. So what can
I do? Add all of t-mobile to my SPF records? What happens next time
something like that occurs?
In the end it was just easier to back off of SPF for now.. maybe later..
Re: consensus on SPF
Posted by Clarke Brunt <cl...@yeomannavigation.co.uk>.
> Hi, I have heard that SPF is controversial among mail administrators. Why
is that? How many
> people use it (on this mailing list)?
It's certainly not a simple subject: anyone who isn't familiar see
http://spf.pobox.com/
So long as you're careful, and realise that mistakes might precent mail
getting through (whether yours, or your ability to receive other people's),
then it seems to me to be a _good thing_.
I'm not referring to the domain I'm posting from now, so no point you
attempting to check my SPF records :-), but I've published SPF records for a
couple of domains, and check for SPF in the MTA (Exim4) when receiving,
rejecting at SMTP time anything that gets a hard failure. I'm seeing it
reject quite a lot a spam with forged "MAIL FROM" envelope sender.
I'm not quite so sure about the use of SPF inside SpamAssassin, as it hasn't
necessarily got access to the full information that the receiving MTA would
have. I've looked at the code in SpamAssassin, but have forgotten some of
the details. It presumably has to poke through headers looking for any
evidence of the sending IP address, the MAIL FROM, and the HELO, whereas all
these would be self-evident to an MTA. That said, I can't see its use in
SpamAssassin doing any harm, as it just contributes towards the score like
everything else.
--
Clarke Brunt
Re: consensus on SPF
Posted by Matt Kettler <mk...@evi-inc.com>.
At 04:05 AM 12/15/2004, jdow wrote:
>From: "Matt Kettler" <mk...@comcast.net>
> >
> > At 11:55 PM 12/13/2004 -0500, Peter Matulis wrote:
> > ie: jdow wrote:
> > > The chief thing SPF does is clutter up name server traffic to prove
> > > something of little or no use when scoring spam.
> >
> > A true argument, but utterly missing the point, unfortunately.
> >
>
>I'm not advocating getting rid of it now. I am advocating using it with
>full knowledge of what happens when it doesn't do what it should for
>idiot anti-spam reasons. The law of unintended consequences stomps you
>on the foot too often. This is a heavy triphammer.
That's a good point. You definitely should proceed with caution. But that
doesn't
Re: consensus on SPF
Posted by jdow <jd...@earthlink.net>.
From: "Matt Kettler" <mk...@comcast.net>
>
> At 11:55 PM 12/13/2004 -0500, Peter Matulis wrote:
> ie: jdow wrote:
> > The chief thing SPF does is clutter up name server traffic to prove
> > something of little or no use when scoring spam.
>
> A true argument, but utterly missing the point, unfortunately.
>
I'm not advocating getting rid of it now. I am advocating using it with
full knowledge of what happens when it doesn't do what it should for
idiot anti-spam reasons. The law of unintended consequences stomps you
on the foot too often. This is a heavy triphammer.
{^_^}
Re: consensus on SPF
Posted by Matt Kettler <mk...@comcast.net>.
At 11:55 PM 12/13/2004 -0500, Peter Matulis wrote:
>Hi, I have heard that SPF is controversial among mail administrators. Why
>is that?
I think mostly because people view it as a general purpose anti-spam tool.
With such a perspective, it's easy to poke holes in and declare it useless.
"Spammers can just register their own domain and publish SPF records..."
etc... Of course, they are right. But they are attacking the obvious.
SPF isn't intended to stop people from sending spam, it's intended to stop
forgery, or at least make it more difficult. IMO, it's actually more
powerful against viruses than spam, but it does act as a good weapon
against joe-jobs, and helps against phishers posing as ebay.com. In the
long run, this can also make it's impacts on spammers, as sender domain
whitelists and blacklists can be made more readily. Imagine a day where you
can verify that an email from joe@hotmail.com passed through hotmails
servers. This is what SPF offers. It's not a tool to bring global spamming
to a halt, but it's easy, simple, and makes certain aspects of email more
usefl.
Of course, there's other arguments too.. Redirectors, forwarding services,
etc, but these have their solutions. (Hint: SPF at each stage, and when you
remail, use a return path that points at your own servers like a mailing
list does. Poof, problem solved.)
>How many people use it (on this mailing list)?
At present I publish SPF records, but I don't yet check SPF records on
inbound mail.
Note: sorry for the late mail, this was in my outbox since this morning.. I
forgot to send.. Since then, several in this thread have made the classic
anti-spf argument that I mention here..
ie: jdow wrote:
> The chief thing SPF does is clutter up name server traffic to prove
> something of little or no use when scoring spam.
A true argument, but utterly missing the point, unfortunately.