spf-discuss
[Top] [All Lists]

Re: Question on how things work

2004-06-04 12:56:25
Well the way I see it from an administration standpoint, in most cases my users are behind sympatico servers which causes problems with smtp auth because sympatico blocks port 25 unless I move my smtp server, which means that each user has to be setup to use a different
port (until sympatico blocks that one too).

Adding sympatico.ca and the corporate side .on.aibn.com would be ok but I've noticed that there are a lot of servers that apperently send mail. even though the users are setup to so a smtp.whaterver they keep connecting to different smtp servers.. the big ones are tomts28-srv.bellnexxia.net which starts at 1 and goes to who knows :) on different subnets, which would cause problems
inserting all of them.

There will always be isp's that force you to use they're servers and in most cases they won't want to do anything special to accommodate a home business or something like that who has they're server somewhere
else.

I'm not sure what you mean by per user SPF records ?

So I'm not nuts :) WEEEEE gonna put this down on the calender... someone want to witness it..
nobody's going to believe that I'm not nuts :) lol..... <g>


Dave


At 03:36 PM 6/4/2004, you wrote:
On Fri, Jun 04, 2004 at 03:15:30PM -0400, Dave Lewis wrote:
|
| So if I have things right I would in theory add my servers to the spf list
| by mx or ip or whatever and add
| in the includes: section any isp that my users use to send mail on behalf
| of the domains I host for them ?

This is an interesting question.

Suppose your user has vanitydomain.com, but sends mail
through ISP.net.

Before the merger, with SPFv1, the answer would've been:

  Given that your users want to use vanitydomain.com
  in the return-path of mail they send through ISP.net's
  mail servers,

  We assume that ISP.net will acccept mail from their MUAs;
  the return-path in that mail is vanitydomain.com

  We assume that the ISP does not do anything with the 2822 headers.

  We assume that the ISP does not perform SRS.

  If the above are true, you will need to either:

    - create per-user SPF records under vanitydomain.com, or

    - just include all the different ISP.nets in
      vanitydomain.com's SPF record.

  These two steps would be unnecessary if the ISP does
  perform SRS.

After the merger, with SPF/Caller-ID, the answer is now:

  Given that your users want to use vanitydomain.com in the
  return-path of mail they send through their ISPs' mail
  servers,

  We assume that ISP.net will acccept mail from their MUAs;
  the return-path in that mail is vanitydomain.com

  When they send mail through their ISP's mail servers, that
  connection may or may not be SMTP AUTH'ed.

  IF the connection is SMTP auth'ed,
    We assume that the MUA will set "From: user(_at_)vanitydomain(_dot_)com".
    We assume that the ISP will set "Sender: user(_at_)isp(_dot_)net".

  IF the connection is not SMTP auth'ed,
    We assume that the MUA will set "From: user(_at_)vanitydomain(_dot_)com".
    The ISP may or may not set "Sender: unknown-user(_at_)isp(_dot_)net".

  We assume that the ISP does not perform SRS.

  IF the ISP is SUBMITTER-aware,
    The ISP will send mail with
     MAIL FROM:<user(_at_)vanitydomain(_dot_)com> 
SUBMITTER=<user(_at_)isp(_dot_)net>

    You will not need to create per-user SPF records for vanitydomain.com.

  IF the ISP is not SUBMITTER-aware,

    You will need to create the per-user records as above.

  Creating the per-user records would be unnecessary if the
  ISP were SUBMITTER-aware.

|
| also in this case is SASL really necessary for me ?
|

doing SASL reduces the problem to the webmail scenario which
is easier.

  If you provide SMTP AUTH to your users,

    There is a one-time tech support / outreach burden to
    get them all to switch to using your mail servers,
    instead of ISP.net's.

    Then you don't need to do any fancy includes in your SPF record.

  This is the most elegant solution.

|
| Am I completely off base or am I smoking some good wacky tabacky ?
|

Your question is a good one and I think the above comparison
shows how the tradeoffs differ.  Which scenario do you think
will be easier for the market to adopt?

1) ISPs don't do SRS: publishing domains need to support per-user SPF records.
2) ISPs do SUBMITTER: ISPs need to support SUBMITTER, nobody else does anything.
3) SMTP AUTH: you need to get your users to SMTP AUTH in to you.


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com