Re: consensus on SPF
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 <[EMAIL PROTECTED]> 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
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 -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: consensus on SPF
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
I like to think of SPF as my 'license' to use my domain or the domains that I host to send email as though it is from one of my users. If I have SPF records, I WANT other mail servers to respect that it is my wish that ONLY MY authenticated users send email marked as such with my permission. I tell my users, don't use email forwarding. Its complicated enough just to get their emailer configured correctly even when they are NOT using email forwarding. That's our policy. On Dec 14, 2004, at 6:29 PM, Kevin W. Gagel wrote: The intent of SPF was to provide a mechanism to verify that the sending server and the claimed domain the mail was from was the same. A failure allows the email admin to do what 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
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
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
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: consensus on SPF
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 -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: consensus on SPF
Max Paperno wrote: More on a personal level, why does the SPF @ pobox.com site look like a corporate advertisement for a product? Why do we need a bunch of clipart images to "sell" something like a mail protocol if it's really such a good idea? Why do I get the feeling someone wants to make $$$ off this? What happened to the list of issues that people have with SPF that used to be on that site? All that just rubs me the wrong way. "SPF has already been adopted by AOL, Earthlink and Google. Shouldn't your company be next?" Sounds like marketing talk, not geek-speak. I agree. The SPF site used to be much more geeky. To give them the benefit of the doubt, I would assume that their primary motivation would be to get as many people as possible to support SPF. It might make sense that you would use the same marketing techniques to achieve this goal. The objections page is still there. It is linked on the Sitemap, at the least: http://spf.pobox.com/objections.html Stuart Johnston
Re: consensus on SPF
At 04:05 AM 12/15/2004, jdow wrote: From: "Matt Kettler" <[EMAIL PROTECTED]> > > 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
At 03:24 AM 12/15/2004, Max Paperno wrote: At 12/15/2004 03:13 AM -0500, Matt Kettler wrote: >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.) Poof, problem created. What am I supposed to do with a message that gets returned to my "remailer" address? Keep track of where it came from just in case? For how long? No mail server I know of does this currently, nor is there any formal spec, RFC, etc. that establishes a precedent. I'm not trying to pick an argument, nor will I respond to one on-list. This discussion has been hacked to death on Postfix list and probably many others. No need for storage, just use a return path that encodes the original sender in the user name. Lots of legitimate newsletters use this technique so they can unsubscribe bounces. Heck, even THIS LIST does it for the recipient address: Return-Path: <[EMAIL PROTECTED]> It would be straightforward to use the same trick to encode the actual return path based on the original sender. Yes, this does mean implementing it, but no it doesn't create the storage system you suggest, and there's plenty of precedent for this kind of encoding technique.
Re: consensus on SPF
From: "Matt Kettler" <[EMAIL PROTECTED]>
>
> 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
[Sorry I'm not replying to the original mail, I seem to have missed it] At 12/14/2004 10:01 AM +, someone wrote: >> Hi, I have heard that SPF is controversial among mail administrators. Why >is that? How many >> people use it (on this mailing list)? My main beef is that SPF breaks forwarding for domains which wrongly assume that no one would want to forward their mail legitimately. Eg. someone from AOL sends mail to one of our hosting clients, whose setup forwards the mail to a 3rd party server. If the 1st (aol) and 3rd party uses SPF, the mail would get flagged/rejected. Essentially if you set up restrictive SPF records for your domain, you're saying that no one is allowed to forward your messages (except the servers you specify). Perhaps that is desirable to some, but IMHO this _breaks_ SMTP. At 12/15/2004 03:13 AM -0500, Matt Kettler wrote: >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.) Poof, problem created. What am I supposed to do with a message that gets returned to my "remailer" address? Keep track of where it came from just in case? For how long? No mail server I know of does this currently, nor is there any formal spec, RFC, etc. that establishes a precedent. I'm not trying to pick an argument, nor will I respond to one on-list. This discussion has been hacked to death on Postfix list and probably many others. More on a personal level, why does the SPF @ pobox.com site look like a corporate advertisement for a product? Why do we need a bunch of clipart images to "sell" something like a mail protocol if it's really such a good idea? Why do I get the feeling someone wants to make $$$ off this? What happened to the list of issues that people have with SPF that used to be on that site? All that just rubs me the wrong way. "SPF has already been adopted by AOL, Earthlink and Google. Shouldn't your company be next?" Sounds like marketing talk, not geek-speak. Cheers, -Max
Re: consensus on SPF
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 [EMAIL PROTECTED] 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.
Re: consensus on SPF
From: "Kevin W. Gagel" <[EMAIL PROTECTED]>
> From: "jdow" <[EMAIL PROTECTED]>
> > From: "Clarke Brunt" <[EMAIL PROTECTED]>
> >
> > > Jonathan Nichols wrote:
> ---snip---
> > 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.
>
> The intent of SPF was to provide a mechanism to verify that
> the sending server and the claimed domain the mail was from
> was the same. A failure allows the email admin to do what
> they want at that point. Discard, reject, bounce or send it
> through a tagging system like SA.
>
> In other words it was designed to allow you to reject IF you
> want to. So yes, it is a reason to accept or reject - IF
> that is what they want to do. I don't because it has not yet
> gained the widespread acceptance needed to help me reduce my
> workload. But I have published records to help others reject
> mail claiming to come from my domain. In fact since
> publishing the records I have not had complaints coming to
> me about forged spam. So I think its starting to gain
> acceptance and doing what its inteded to do.
All well and good. But if you perform an engineering analysis on its
failure mechanisms it's not really telling you much of anything that
is useful given the vagaries of the Internet today. People have not
figured out everything you have to go through to make your own SPF
records safe and useable for yourself when legitimate recipients may
be overreacting to erroneous SPF records. At the moment any serious
reliance on SPF failure will up your false positive rate. IMOAO the
false positive is a FAR greater annoyance than the missed spam. And
if the false positive results in rejected emails this can be both
very expensive and exquisitely annoying to users. If YOU are the
only user than you have performed your own analysis and accept the
risks. If it is part of a large ISP you might want to rethink your
employer's risks in summarily rejecting emails solely on the basis
of a failed SPF record at a time that this is fairly well expected
to happen on quite legitimate emails.
{^_^}
Re: consensus on SPF
From: "Clarke Brunt" <[EMAIL PROTECTED]>
> 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
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
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 <[EMAIL PROTECTED]> 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
- Original Message Follows - From: "jdow" <[EMAIL PROTECTED]> To: Subject: Re: consensus on SPF Date: Tue, 14 Dec 2004 12:42:38 -0800 > From: "Clarke Brunt" <[EMAIL PROTECTED]> > > > Jonathan Nichols wrote: ---snip--- > 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. The intent of SPF was to provide a mechanism to verify that the sending server and the claimed domain the mail was from was the same. A failure allows the email admin to do what they want at that point. Discard, reject, bounce or send it through a tagging system like SA. In other words it was designed to allow you to reject IF you want to. So yes, it is a reason to accept or reject - IF that is what they want to do. I don't because it has not yet gained the widespread acceptance needed to help me reduce my workload. But I have published records to help others reject mail claiming to come from my domain. In fact since publishing the records I have not had complaints coming to me about forged spam. So I think its starting to gain acceptance and doing what its inteded to do. = Kevin W. Gagel Network Administrator Information Technology Services (250) 561-5848 local 448 -- The College of New Caledonia, Visit us at http://www.cnc.bc.ca Virus scanning is done on all incoming and outgoing email. --
Re: consensus on SPF
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
From: "Yassen Damyanov" <[EMAIL PROTECTED]>
> 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
From: "Clarke Brunt" <[EMAIL PROTECTED]>
> 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
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 | [EMAIL PROTECTED] | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981|
Re: consensus on SPF
On Tue, 14 Dec 2004 13:52:37 -, 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
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
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
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
> 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
