On Thu, Feb 23, 2012 at 08:28:05AM -0800, rg86...@airpost.net wrote: > On 02/23/2012 06:53 AM, /dev/rob0 wrote: > > I see the goal as being, in part, to detect a spammer in THIS > > transaction. That sounds reasonable to me. But the proper thing > > here would be to use a policy service in smtpd_data_restrictions. > > I'd have to create a policy service, right? Some sort of > additional filter, or some such?
A policy service is an external daemon, yes. Examples of such which are in common use include policyd and postfwd. > I didn't get to this yet, so some more reading is required. > I'll pore over my book and the site, but any good references > you can share? http://www.postfix.org/SMTPD_POLICY_README.html and the sites for both aforementioned third-party projects. > > Also I consider it reckless and irresponsible to accept and > > discard mail unless you are absolutely certain it is spam. I > > would not have such confidence in this case. > > That's simply an operating choice. > > If the spam-address is one of the recipients, I am absolutely sure > it's spam. Most spam trap operators are not so confident. There are possible ways in which legitimate senders might accidentally hit a spamtrap. Similarly, a hostile third party could submit spamtrap addresses to listservs and legitimate bulk mailers. Granted, multi-recipient mail including spamtrap addresses is unlikely to be seen from responsible bulk mailers, but what if Aunt Minnie made a stray click in her mail client, or mistyped a few characters ... ? Typical spamtrap-driven DNSBL services look for multiple hits for spamtrap addresses, not just one, to make a listing decision. Or in some cases such as CBL, they combine the envelope check with content examination. My view remains unchanged; I would not do what you are describing. Naturally you are free to disagree and do it anyway, but by posting here, you opened it up for opinions, and you got mine. > The only thing I would find 'reckless and irresponsible' is > delivering such email to ANY of its intended targets. > > > If a spammer is paid per delivery, why not reject? That way > > said spammer has to alter the results from his ratware to show > > more delivery success. :) > > Because, as I understand it ... > > On Thu, Feb 23, 2012, at 09:15 AM, Noel Jones wrote: > > REJECT doesn't really help with multi-recipient mail. > > ... REJECT fails on the multi-recipient disposal. > On Thu, Feb 23, 2012, at 10:31 AM, Wietse Venema wrote: > > > REJECT doesn't really help with multi-recipient mail. > > > > Agreed. rejecting mail that hits a spamtrap would require a > > flag that is raised before DATA time, and that is tested at > > DATA time. However I shudder at the thought of adding more > > code to the current smtpd access engine. I'm still not clear on why a REJECT (or any other valid access(5) result, DISCARD included) wouldn't work with a check_policy_service lookup at DATA, but I have to defer to Wietse and Noel. I hope either of them will explain where I am wrong about this. <pause to check> <Explanation received from Noel> > >> would be to use a policy service in smtpd_data_restrictions. > > Recipient checks in smtpd_data_restrictions are ineffective with > multi-recipient mail. When there are multiple recipients, > check_recipient_access cannot be performed and is silently skipped, > and policy services are supplied an empty recipient value. > http://www.postfix.org/postconf.5.html#smtpd_data_restrictions Oh, thanks. But in theory could this work if the policy daemon was checked twice, once in smtpd_recipient_restrictions and then again in smtpd_data_restrictions? I can see that it might be a challenge to ensure that the RCPT TO check is correlated with the DATA check, but protocol_state=DATA might then look to see what happened from the same helo_name / client_address et c. at protocol_state=RCPT ? Or ... /me RTFMs ... * The "instance" attribute value can be used to correlate different requests regarding the same message delivery. ... I apologize if I have muddied up the issue here, but at least I am learning something, and maybe others will too. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
