The issue regarding SRS is only important if you have mailboxes that = forward to another email server. For example, I have customers who host domains with me and have certain email addresses in their domains forward to mailboxes at yahoo, hotmail, or aol. If I create SPF records in their domains, there is a chance yahoo, hotmail, or aol might block their forwarded email when they do their SPF filtering. That is why it is so important to have the SRS stuff in place before publishing SPF records.
The SASL SMTP issue is important because I want to be able to enable SPF = and my customers do not connect to the net from within some IP range that I = own. My customers go through various ISPs around the world. Some of their = ISPs are blocking outbound port 25 traffic. If I publish SPF for these = domains and the customers in those domains cannot connect to my servers on port = 25 due to their ISP's blocking efforts, then my customers' emails will be blocked by SPF at remote servers because they will be sending from their ISP's IP instead of mine. Logically, I want to allow a port other than = 25, and port 587 is the recommended one. However, without SASL SMTP, I = would be making port 587 as dumb as port 25. If I am going to allow a port other than 25 to accept SMTP connections, then that other port must be locked = down to only allow authenticated connections such as SMTP AUTH. If I do not = lock down port 587 with SMTP AUTH, then spammers will get around the port 25 blocks and spam directly to port 587. I am extremely excited about the forgery blocking benefits of SPF once everything is properly deployed. SPF alone will not be that big of a = deal, but a properly deployed SPF aware mail server combined with all of the = other anti spam tech at our disposal will be extremely effective. The = important thing is the whole picture. Simply running as SPF filter will help you reduce some inbound spam that is forged. But the big picture about = properly deploying all aspects of SPF is what gets me excited. I host tens of thousands of domains and hundreds of thousands of email accounts, and properly deploying all of the SPF tech (SPF records, SPF filters, SRS, = SASL SMTP) is going to help me do my part to protect my customer's accounts = from being victims of forgery. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] = On Behalf Of Kevin Williams Sent: Tuesday, October 12, 2004 1:05 PM To: [EMAIL PROTECTED] Subject: [xmail] Re: SPF Wow, I hope that's not true. The SPF site leaves me with the impression=20 that the DNS record checking, Received-SPF header, SMTP AUTH, and SRS=20 are all pieces which can be implemented in steps and should not fail=20 when all steps are not yet implemented. I have the impression that if a=20 server is rejecting messages because SRS is not implemented on the=20 sending server, that's a bad implementation on their part and not the=20 fault of the sender or sending server. Honestly, I don't yet see the benefit to SRS because it seems like a=20 huge hassle, requiring servers to be re-architected. If SPF is designed=20 to fail without SRS, then I don't see how it will ever succeed. Shiloh Jennings wrote: > Without SRS and SASL SMTP support, publishing SPF records for your =3D > domains > can cause problems. One potential problem is with forwarded email. = =3D > Some of > your forwarded email could be blocked by other ISPs if you publish SPF > records without proper SRS support within your email server. >=20 > -----Original Message----- > From: [EMAIL PROTECTED] = [mailto:[EMAIL PROTECTED] =3D > On > Behalf Of Kevin Williams > Sent: Tuesday, October 12, 2004 12:16 PM > To: [EMAIL PROTECTED] > Subject: [xmail] Re: SPF >=20 > Please explain why you think it is not practical to add the SPF = record=3D20 > to your DNS. Publishing an SPF record in your DNS is step 1, and you = do=3D20 > not need to do anything else if you don't feel like it. This just = makes=3D20 > life easier for everyone who receives messages from your domains. >=20 >=20 > Shiloh Jennings wrote: >=20 >=20 >>AUTH only. The other issue is SRS (Sender Rewriting Scheme). With = =3D >=20 > SRS =3D3D >=20 >>and >>SASL SMTP support, it is not practical to enable SPF within our own = =3D >=20 > DNS >=20 >>records. It is unfortunate, because I would love to be able to fully = =3D >=20 > =3D3D > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] >=20 > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] >=20 - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
