DJ Lucas a écrit : > Noel Jones wrote: >> >> Very likely there are other, better ways to combat this spam. Look >> for other traits you can use to reject it. >> > I am, by no means, anything even close to expert WRT the whole SMTP > process, but, I do think that I can provide (or at least what I believe > to be) a valid, albeit opinionated, counter argument. See below. >> some things to look for: >> - client listed on some RBL >> - client name that looks dynamic >> - using your domain or IP as HELO >> - unusual headers >> - body text unlikely to be found in legit mail >> >> If that doesn't help, consider adding SpamAssassin and/or ClamAV. > From my POV, this one check saves me a small few (100, 200?) DNS/RBL > lookups per month and a few CPU cycles by not getting to header checks, > body checks, and finally SA (which is probably the most expensive check > in the stack, followed immediately by virus scanning). I can probably > parse my logs and give a real number, but it would seem insignificant to > those running large servers. It is my _choice_ to be as efficient as > possible. > > <IMO> > Please correct me if I've made an invalid assumption (but do take notice > of the "IMO" qualifier!) > > I can find absolutely no reason to inadvertently mislead, or worse, > intentionally deceive the recipient by forging the envelope sender's > address. In fact, the only reason I can see, is to intentionally > deceive the recipient. Is there any other reason?
some services use the "user" address because they believe that they are acting on behalf of the user. examples include - "send to a friend" (postcard, article, ...), "invite a friend", "sell/buy/offer...", ... - interfaces to mailing lists such as nabble - user posting via his ISP/hotel/.... relay. - "classical" forwarding (.forward, aliases, ...) SPF, DKIM and other anti-spam measures (such as the one discussed here) are rendering these problematic. but you can't simply call this "poor practice" or "deceptive practice". so yes, you can establish a policy that states "nobody can use our addresses in the envelope sender except from trusted networks or via secure submission on port 587". but you must be aware of the implications so that you can explain them to your users. note that the envelope sender is not used to deceive the user, because the user does not see it. it is generally used to fool "silly whitelists" (some people whitelist their own domains, ...). spammers who want to deceive the user forge the From: header. > It is plain irresponsible, even if allowed by RFC. Even more so given > that most (all?) mail clients will honor the from header and display it, > in big, bright, flashy, bold text, in a prominent location for the end > user to see (and reply to). Maybe I've missed something, but I really > cannot find a good reason to allow it. Even the BlackBerry example > given above is an example of poor practice in my opinion, but it can be > an ALLOWed exception if it is out of your control. > > But that is all a matter of principal, not a technical reason. The > technical reason (minor increase in efficiency) was above, but I also > provide one more weak technical argument. Another possible (but pretty > unlikely now days) side effect of allowing such message mangling to > occur is that it could lead to backscatter if an intermediate server is > mis-configured. That is not my problem if it is 'properly' denied at > the door and not allowed (either direction) by my server. > </IMO> > > That particular Postfix directive was created for some reason, so > somebody, somewhere must agree. Anyway, bottom line, it is my server. > I try to protect my small number of users from the outside world (and > themselves) as best I can. If they don't like my policy, they can find > another place to put their mail. Others may not be lucky enough to be > able to enforce such a policy, as the counter argument would be to find > a less rigid admin. ;-) What is 'acceptable' has to be determined on a > site by site basis. If it works for this site...great! If it doesn't, > then get rid of it. > > I hope that came off as a constructive, alternative vantage point rather > than being argumentative. :-) >
