|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Questinair about email policy records to indicate proper source of email (RE: FW: The worst abuse e-mail ever, sverige.net)
> As such, when we have seen our IP blocks get blocked strictly because of > the rDNS entry having 'dsl' in it, a simple email to the admins > explaining that we are not providing dynamic services has gotten our > rDNS entries taken off of the blacklist. I don't particularly like situation where outside party has to "guess" if another ISP's address is dynamic or static and should or should not be source of email. This is not helpfull either to ISP and their customers not to those trying to filter email and guess what are good and bad ips. Lets suppose there was a standartized way that ISPs could enter in their DNS policy record that says that certain ip address is/is not used for sending email. Would you be interested in using this? If you answer yes and would like to help towards such a standard, please go through the questions I put below. Your answers will go toward a draft which has good chance of being used as part of Unified SPF. To help with creating something that will work well for ISP as well as for end-users, I'd like to receive answers from both major ISPs and smaller networks and small mail operators, but please answer in private so as not to anger moderators of this mail list. If you do want to discuss any particular details of the email policy technology, I'd request that signup for SPF discuss mail list: http://spf.pobox.com/mailinglist.html Now here are the questions, I'd like to receive feedback on: ------------------------------------------------------------------- 1. Are you ISP? What size? a. Major ISP (> 20,000 customers) b. Small or Mid-size ISP c. End-User network customer who runs mail server. Specify if its on i. dedicated line or co-located box ii. DSL or cable (residential variety) d. End-User who does not run own mail server 2. If you're ISP are you willing to quickly deploy these records if such standard becomes available? If so how quickly can you deploy it - a. 1-6 months b. 6-12 months c. > 12 months d. Would not deploy it 3. Are you willing to configure/upgrade your email server to check of these policy records and reject SMTP connection based on these records? a. Yes - will rely solely on these records b. No - will never deploy this c. Will not reject SMTP connection based solely on this record, but willing to make it part of overall email filtering system (i.e. adds points to SpamAssassin or similar) 4. Many users and even RIRs have expressed doubts about relying on IN-ADDR and said it has technical problems and/or that IN-ADDR zones are badly maintained by ISPs and that we should not rely on it. Do you agree? a. No - INADDR is well maintained by RIRs and ISPs b. Yes - INADDR is BAD and can't be fixed, we should not rely on it c. There are deployment issues with INADDR due to how ISPs use it but technically its good and we can rely on it. If you answered c: Does your ISP maintain IN-ADDR zones for all its IPs and do you quickly update it based on your customers requests? i. Yes we do. We update zones in < 1 day per customer requests ii. We maintain it, but don't update it as often as it maybe needed. We're willing to make an effort and answer tech support from customers in regards to in-addr records in < 24 hours or quicker (same level of support you provide for customer domains hosted on ISP dns servers). iii. We don't maintain INADDR records at all. But are willing to do it if it becomes a requirement for email 5. Would you prefer email policy records be entered in the IN-ADDR zone for each ip or would you prefer it to be entered as part of the HOST record for PTR address of the ip? a. IN-ADDR zone b. PTR HOST record c. Neither - prefer different alternative. Specify: ______________ Note: When thinking about this answer to #5 please also go back to question #4 and think what would be easier for you (as an ISP or end-user) to maintain and provide ability to update if you or your custoemers need to be able to update it. 6. The suggestion that has been made to allow DNS policy record for SMTP Mail server as used in EHLO to override policy record for IP as a way to get around non-cooperative or slow ISPs that don't let their customers control what record is in the INADDR zone. What do you think about this? a. No, we should not allow any other mail policy to override email record for ip b. Yes, that is ok if other policy records override ip records. c. This is ok for most cases when some other email policy record can override ip policy records, but in some cases, ISPs do need to specify records that can not be overridden. 7. For the policy record would you prefer to just say that no email is to come from the ip or would you prefer to be able to specify more complex record: a. Prefer to have two choices (outgoing SMTP yes/no) b. Prefer to have more then two choices: i. Three choices: - Full mail server exists on ip - IP only used as source of submission by end-users - No email connections should be sent ii. more then three choices Explain what you like to see: ___________________________ 8. Would you like to have an option as part of policy record that can be used so that other email servers when they see SMTP connection from certain ip would report back to you if ip is used for outgoing email connections? a. No, we don't need it b. Yes, I'd like to see it as option but will not use it much c. Yes, I'd like to see it and will set it up for many ips 9. Would you like to have an option as part of policy record that lets specify who the administrator is to contact in case email does come from specified ip that somebody does not like: a. No we do not need this - users should do whois on ip for abuse reports. b. Yes, this is good option, but we will not use it much c. Yes, this is good option and we'll use it for many ips 10. Would you like to have an option of contact information as part of policy record that can be used in 500 rejects and bounces? (i.e. if you set policy record that says no email is to come from the ip, additional email address is added and when email is rejects, email server would include that info so that whoever is trying to send the email would be notifed). a. We don't need it. Since whoever is using ip is already customer they should already know who to contact. b. Yes, this is usefull option 11. If you answered yes on #9 or #10, would you be ok if there was only one policy record of email contact for ip with different meaning depending on if email from ip is to be rejected or accepted? a. Yes - dual meaning is ok b. No - the contact info option should for one or the other 12. Do you consider that these email policy records for ips would be alternative for ISP port 25 blocking or a complimentary technology that can be used together with it? a. Yes. b. No No matter how you answer 12 (both for yes and no), I request that you justify your answer below and tell in your words why email policy records would or would not be usefull and why port 25 blocking can or can not continue to be promoted as proper way for ISPs to prevent email abuse from the their networks: ------------------------------------------------------------------------ If you took the time to complete this questionnaire, I really appreciate your contribution and if you do have any particular ideas in this area, please feel free to also include that. All this input will go towards a draft that we hope can be published as EXPERIMENTAL RFC within next 6 months and if it becomes used widely this may well become full internet standard. Thank you for your time. -- William Leibzon Elan Networks [email protected]
|