Re: Uninstalling postgrey
On Monday, May 25, 2020 10:26:56 PM EDT Ian Evans wrote: > On Mon, May 25, 2020 at 3:35 PM Ian Evans wrote: > > On Mon, May 25, 2020 at 4:09 AM Matus UHLAR - fantomas > > > > wrote: > >> On 24.05.20 21:04, Ian Evans wrote: > >> >Based on another thread here, I want to move to using > >> > >> postscreen/postwhite > >> > >> >and ditch postgrey. > >> > > >> >Just want to make sure I don't bungle stopping postgrey. > >> > > >> >So... > >> > > >> >- edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" > >> > >> from > >> > >> >smtpd_recipient_restrictions. > >> >- restart Postfix > >> >- purge the postgrey package. > >> > > >> >Then go about getting postscreen working. > >> > >> I'd set up postscreen before postgrey, that requires editing master.cf > >> too. > >> however, it's quite easy if you follow the docs. > > > > Thanks everyone for the tips. I'll get working on it. > > Just being purposefully thick here so I don't mess anything up. :-) > > In the Postfix docs it says, for example, to uncomment out this line in > master.cf: > > smtpd pass- - n - - smtpd > > The commented line in my master.cf says: > > #smtpd pass - - - - - smtpd > > So I'm assuming I not only uncomment the line but also change the third > hyphen to an 'n'? And so on with the other lines that might be different > between the docs and the current master.cf? Assuming postfix version > 3, it doesn't matter. The third hyphen is for the chroot value. In postfix << 3 the default was y, so an explicit n was needed. In postfix >= 3 the default is n, so leaving the '-' is the same as 'n'. Scott K
Re: Uninstalling postgrey
On Mon, May 25, 2020 at 3:35 PM Ian Evans wrote: > On Mon, May 25, 2020 at 4:09 AM Matus UHLAR - fantomas > wrote: > >> On 24.05.20 21:04, Ian Evans wrote: >> >Based on another thread here, I want to move to using >> postscreen/postwhite >> >and ditch postgrey. >> > >> >Just want to make sure I don't bungle stopping postgrey. >> > >> >So... >> > >> >- edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" >> from >> >smtpd_recipient_restrictions. >> >- restart Postfix >> >- purge the postgrey package. >> > >> >Then go about getting postscreen working. >> >> I'd set up postscreen before postgrey, that requires editing master.cf >> too. >> however, it's quite easy if you follow the docs. >> >> > Thanks everyone for the tips. I'll get working on it. > Just being purposefully thick here so I don't mess anything up. :-) In the Postfix docs it says, for example, to uncomment out this line in master.cf: smtpd pass- - n - - smtpd The commented line in my master.cf says: #smtpd pass - - - - - smtpd So I'm assuming I not only uncomment the line but also change the third hyphen to an 'n'? And so on with the other lines that might be different between the docs and the current master.cf?
Re: Uninstalling postgrey
On Mon, May 25, 2020 at 4:09 AM Matus UHLAR - fantomas wrote: > On 24.05.20 21:04, Ian Evans wrote: > >Based on another thread here, I want to move to using postscreen/postwhite > >and ditch postgrey. > > > >Just want to make sure I don't bungle stopping postgrey. > > > >So... > > > >- edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" > from > >smtpd_recipient_restrictions. > >- restart Postfix > >- purge the postgrey package. > > > >Then go about getting postscreen working. > > I'd set up postscreen before postgrey, that requires editing master.cf > too. > however, it's quite easy if you follow the docs. > > Thanks everyone for the tips. I'll get working on it.
Re: easiest way to reject/process emails based on Return Path
Dnia 25.05.2020 o godz. 12:59:30 yuv pisze: > > The legal issue is NOTICE. NOTICE is the fact that the recipient knew > or *should have known* the content of the message. Let me know if you > want me to expand on the concept of notice. You have explained it sufficiently in your message and I fully understand your concerns about this topic. However: > This is a conflation of the general case, and irrelevant to my concern. > In the OWN SERVER case, the law will find that the recipient has > willfully ignored the message and knew or should have known the > message. [...] > If the OWN SERVER sends a 250 and discards the message, the user is > both recipient and operator. The law will find sufficient notice and > the sender is protected. > > In the general case, the user is the MTA operator and is not the > recipient. That's the difference between us. For you, the "own server" case is irrelevant, as you think about general case. But you have in your very first post stated that you run your own (ie. your company's) server. So all further comments, advices and replies in this thread should be viewed in context of runing an own server and only in this context! So for you, the case of own server is irrelevant; for me - it's the only one that is relevant to this discussion; all others are irrelevant :) I would never advise anyone to do 250+silent discard as a third party, and probably the person who advised you to do this wouldn't as well. But - as I understand from your quotes above - it states no legal issue when done on own server. > The *ETHICAL ISSUE*, and the reason why I do not want to send a 250 and > discard the message in the conflated scenario: when I am the sender, > and I am told 250, and that 250 cause damage to me because it is a lie, > I am obviously not happy. Which wise person said 'Don't do unto others > what you don't want done unto you?' But if you do it on your own server (I will still hold on to the only relevant case ;)), it's practically equivalent to deleting a message without opening it. Do we still remember that your original question was about getting rid of superfluous Google Calendar notifications? You probably delete them without opening. So if you set up a filtering rule that matches them and only them - and deletes them before they reach your inbox - would it be different in any way? What's unethical in this (in this particular case ONLY)? Again, I repeat: I would never advise to do it as a third party. Only as a final recipient. That's a fundamental difference (at least for me). > You work for home buyers that need mortgages. You need to receive > mortgage instructions from the lender. The lender gives you two > options: > (a) use a proprietary platform that requires use of Internet Explorer > (no Edge, no Chrome, no Safari, no Firefox) and Adobe Reader. A > typical fee of $30/mortgage is charged to you/your client > (b) use a fax; for which you/your client cover your side of the expense > (receiving and, if necessary, printing). Very strange scenario if I think about my country. First: there is no such thing as faxing or emailing PDFs back and forth for signature. Such documents would have no legal value. A fax copy is not a document in legal sense; it's just an "image of a document", in similar sense as a photograph or photocopy of a document would be. It can be a kind of proof that a document exists (or existed), but it's not a document itself (and as every proof, can be questioned in court). And if you put a signature overlay from a different source onto a different PDF file it may even be considered fraud, because it's no more an "image of a document"; the image has been manipulated. Of course, you can fax (or scan and email) a signed paper document just to give the other party information that you signed it, but this is only an information; only an actual paper document is a legally valid document. So, legally valid documents can be signed only using two ways (of course unless there's a previous contract between parties in place, which may allow for different terms, eg. doing it online via website): a) physically on paper. No faxes, no scans, no PDFs etc. If you cannot meet with the other party in person to sign, you have to send the document via snail-mail. b) electronically (eg. in a PDF file), using a X.509 digital signature issued by one of government-approved Certificate Authorities. Obviously you cannot fax a digital signature :) As for "your" lender, such a lender would most probably quickly go out of business. No finance-related company here would think about charging for using their Internet platform for processing loan application. That would be a suicidal move. Nobody would borrow from them (unless you had no other option because nobody else would want to give you a loan) if they charged $30 just for use of Internet platform while the others aren't. One can just imagine how much are they charging extra for other things. And an Internet
Re: Preferred/maintained greylisting options?
> Greylisting has become pretty much useless. When I disabled it a > couple years ago, the spam levers did not increase by any measurable > amount. We now use just 3 RBLs and that seems to be a relatively > acceptable level of spam. Checking for %ge of messages that "return after defer" I see: WeekOf PctReturned -- --- 2020-04-30 22.1 2020-05-07 26.5 2020-05-14 21.2 2020-05-21 26.5
Re: noreply email technisch und für Empfänger zum Ausdruck bringen
Am 24.05.20 um 17:19 schrieb @lbutlr: On 23 May 2020, at 08:52, Thomas wrote: or The norm is to use an address along the lines you describe there. I use no-reply@. Emails to that address are accepted and discarded. Do not use a fake domain or someone else's domain, of course. You can certainly have the address be invalid so it generates a rejection, but which you chose is really just up to you. OK, I use now unkńown user NOREPLY NOREPLY Domain must be valid, otherwise lots of Email server will not accept: Sender address rejected: Domain not found (in reply to RCPT TO command)) Same as my server:) smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, thanks Thomas
Re: easiest way to reject/process emails based on Return Path
On Tue, 2020-05-19 at 11:38 +0200, Jaroslaw Rafa wrote: > As a non-lawyer, it is hard for me to understand what you're trying > to debate about. The legal issue is NOTICE. NOTICE is the fact that the recipient knew or *should have known* the content of the message. Let me know if you want me to expand on the concept of notice. > Even physical postal mail service does not give any guarantee that > the recipient has actually READ your mail. That is not of concern, neither for snail-mail, nor for fax, nor for internet-email. The three of them have done their job when they have delivered. After delivery, the responsibility (and the legal liability) lies with the recipient. The general rule is that spam is in the eye of the recipient: if you find my message to be irrelevant to you, I must accept your judgment. Except for some specific situations. For example, a debtor cannot say that a request to pay from a creditor is spam. It is a direct consequence of the debtor accepting a loan. This is where the concept of notice kicks in: the debtor should have known that he owes money, ignoring the payment request does not absolve the debtor from the consequences of not paying the debt. I had clients who learned this the hard way: they ignored the snail-mail letters from the bank. the bank repossessed their home, evicted them, and sold it, at great expense/loss to the idiots who ignored the letters. > If you have your OWN SERVER, a 250 reply to SMTP transaction is an > equivalent of confirming that the message has arrived into your > "mailbox". This is a conflation of the general case, and irrelevant to my concern. In the OWN SERVER case, the law will find that the recipient has willfully ignored the message and knew or should have known the message. > What's ethically doubtful in this? If it were a third party > who discarded the message - yes, that would be unethical > (and probably against the law as well). But if the recipient does it > him/herself - I can see no ethical or legal issue at all. if the third party is Gmail or Hotmail (and many more, no intention to single out those two services), then it is not even against the law, as the contract between the unaware user and the sophisticated "free" email provider stipulates that the email provider has no responsibility for delivering the message. Let me first expand on the legal issue, and then touch on the soft / ethical issue. In a previous message on this thread, on Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote: | > The legal term is *misrepresentation* | | It is not misrepresentation. The SMTP protocol definitions have | NEVER required the 250 reply to end-of-data to indicate actual | (much less final) delivery and has ALWAYS explicitly cautioned | against reliance in any way on the optional text part of any | server reply. A *misrepresentation* occurs when a person lies. SMTP is not a person. An MTA is not a person. A fax is not a person. They are merely devices that a person use to make the misrepresentation. The *LEGAL ISSUE* with an MTA or with a fax is product liability. The manufacturer of a fax device (or the operator of a fax server -- I have not owned a fax device since 2003) represents that its device or service complies with the CCITT standards (or whatever has followed since, the last time I have looked in depth at the protocols around faxes during a 1989 summer job when I programmed a software-fax), and failure to comply with the standard attracts a product liability suit. Software publishers for MTAs (and in general) exclude product liability with the licensing term that disclaims "implied warranties or conditions of merchantability and fitness for a particular purpose" (quoted text from the terms under which Postfix is licensed). Which basically says to the user: here is a knife, use it at your own risk. If the OWN SERVER sends a 250 and discards the message, the user is both recipient and operator. The law will find sufficient notice and the sender is protected. In the general case, the user is the MTA operator and is not the recipient. The user has caused the MTA to send a 250 and *misrepresented* to the sender that the message was delivered. The user has caused the message to be silently discarded, preventing the recipient from noticing the message. The user is liable for the damage caused by the lack of notice, except if said damage is disclaimed in the general terms and conditions of the service (see reference to "free" email services above). Unsurprisingly, free email services invariably have such disclaimer, preventing the recipient from making a damages claim against the operator. I believe that paid email services (from the same providers) do not have such disclaimer, and if they do, why would one want to be customer of their service? The *ETHICAL ISSUE*, and the reason why I do not want to send a 250 and discard the message in the conflated scenario: when I am the sender, and I am told 250,
Re: Preferred/maintained greylisting options?
Kris Deugau writes: > micah anderson wrote: >> Allen Coates writes: >>> The web page https://www.abuseat.org/faq.html (about half-way down the >>> page) >>> has an honest - and fairly recent - appraisal of a number of DNSBLs. >> >> Its a little outdated... >> >> For example: >> >> Invaluement DNSBL >> [Note: Commercial] ivmURI and ivmSIP are good solid and >> professionally operated lists. ivmURI is a URI (domain) DNSBL like >> SURBL or URIBL or DBL, with high effectiveness (comparable with >> DBL/URIBL/SURBL), extremely low false positives, and quick to >> list. ivmSIP is a IP-based DNSBL which is particularly good at >> catching "new" emitters. Its FP rate is quite low. Neither of which >> should be considered substitutes for Spamhaus Zen/Spamcop, but do >> complement them well. >> >> They no longer exist. > > Not sure where you're looking, but we have an active subscription for > Invaluement and the datafeed files all have timestamps within the last > ~10 minutes or so. > > https://www.invaluement.com/ ah, the link on https://www.abuseat.org/faq.html goes to: https://dnsbl.invaluement.com/ which is not a valid site. -- micah
Re: Connection cache limitations
Luca Fornasari: > "With Postfix versions < 3.4, the Postfix shared connection cache > cannot be used with TLS, because an open TLS connection can be reused > only in the process that creates it. For this reason, the Postfix > smtp(8) client historically always closed the connection after > completing an attempt to deliver mail over TLS." > Is that true also in case of relayhost? All SMTP deliveries. > Also I cannot find in the doc how many email transactions are > performed during an SMTP over TLS connection. Quoting from above: "the Postfix smtp(8) client historically always closed the connection after completing an attempt to deliver mail over TLS." That is one attempt per connection. With Postix 3.4 and later, connection reuse is determined by smtp_connection_reuse_count_limit (default: 0) smtp_connection_reuse_time_limit (default: 300s) Plus, connection reuse needs to be turned on for TLS. Wietse
Connection cache limitations
Scenario: I am managing a Postfix 2.10 installation acting as an hub for applications sending emails to the internet. The Postfix installation in turn uses a relayhost that is an A record resolving to n IP addresses; TLS to the relayhosts is negotiated opportunistically anyway it always succeeds. I suspect connection caching is not available as per http://www.postfix.org/CONNECTION_CACHE_README.html "With Postfix versions < 3.4, the Postfix shared connection cache cannot be used with TLS, because an open TLS connection can be reused only in the process that creates it. For this reason, the Postfix smtp(8) client historically always closed the connection after completing an attempt to deliver mail over TLS." Is that true also in case of relayhost? Also I cannot find in the doc how many email transactions are performed during an SMTP over TLS connection. Thanks Luca Fornasari
Re: Preferred/maintained greylisting options?
micah anderson wrote: Allen Coates writes: The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. Its a little outdated... For example: Invaluement DNSBL [Note: Commercial] ivmURI and ivmSIP are good solid and professionally operated lists. ivmURI is a URI (domain) DNSBL like SURBL or URIBL or DBL, with high effectiveness (comparable with DBL/URIBL/SURBL), extremely low false positives, and quick to list. ivmSIP is a IP-based DNSBL which is particularly good at catching "new" emitters. Its FP rate is quite low. Neither of which should be considered substitutes for Spamhaus Zen/Spamcop, but do complement them well. They no longer exist. Not sure where you're looking, but we have an active subscription for Invaluement and the datafeed files all have timestamps within the last ~10 minutes or so. https://www.invaluement.com/ They *are* strictly paid access; they do not have a free tier. -kgd
Re: noreply email technisch und für Empfänger zum Ausdruck bringen
Dnia 25.05.2020 o godz. 14:33:36 Thomas pisze: > > FAX is much better because FAX is same as letter and working > digital, nearly 100% yes or no. Email I did not know if it is > arrived, [...] What do you actually want to achieve? Because from your messages it's hard to understand what do you actually want. When you send an email and you get a 250 response, it means your message has been delivered (of course it does not mean the recipient has actually read it - it may have been put to spam, but you said you don't care about that; BTW. the same applies also for fax or paper letter; someone may receive it, but throw it immediately to trash without reading). 250 reply code is basically the same as fax confirmation - fax also doesn't give you any guarantee that anybody has actually read your message. If you get another reply, like 4xx or 5xx, that means your message hasn't been delivered. If you'd use a working return email address, you would receive rejection messages in case your message hasn't been delivered. Rejection messages are "negative confirmations", ie. you get them only when your message HASN'T been delivered. If you get nothing in return, you may assume your message has been delivered. If you explictly DON'T want to have a working return address, you decided yourself that you don't want these "negative confirmations". So you have to check logs, that's your only option. It's as simple as that. What else do you want? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Preferred/maintained greylisting options?
On 25 mai 2020, at 13:56, Michael wrote: > > I've found the Barracuda rbl to be very useful. > > https://www.barracudacentral.org/rbl I'm using paid spamhaus RBL (local zone file rsynched) for a very long time, at work, and we are very happy about it. I use complementary RBL also like fresh.spameatingmonkey.net for reject_rhsbl_sender, reject_rhsbl_client and reject_rhsbl_reverse_client and b.barracudacentral.org. I've had false positives with b.barracudacentral.org so I've had to add a permit clause to whitelist clients before the b.barracudacentral.org reject. For a month I've tested Abusix configured just after Spamhaus: it catched many spams that Spamhaus wouldn't block, including a cutting edge phishing campaign. It's a very effective RBL, but it's pricey too. They are open to negotiation though. I might replace Spamhaus with Abusix someday. patpro
Re: noreply email technisch und für Empfänger zum Ausdruck bringen
Am 24.05.20 um 17:19 schrieb @lbutlr: On 23 May 2020, at 08:52, Thomas wrote: or The norm is to use an address along the lines you describe there. I use no-reply@. Emails to that address are accepted and discarded. Do not use a fake domain or someone else's domain, of course. You can certainly have the address be invalid so it generates a rejection, but which you chose is really just up to you. Hi, my FAX did not have an valid FAX sender number, that is no problem. but I got an confirmation that my fax is arrived with date/time and content first page. Letter will send additional. Email I have to use an attachment. FAX is much better because FAX is same as letter and working digital, nearly 100% yes or no. Email I did not know if it is arrived, Automatic Email conformation is not working until today or did changed? Or is accepted that I look into my log file to find an 2XX confirmation. No. I will try using norp...@mydomian.tld <> I do not care if recipient think my email is SPAM, that is not my problem. I do not want have recipient Emails on my server, because then I have confirmed with 2XX that I have accepted the Email and I have the problem. 5XX is much better for me. If I send Friday 11:00 AM my FAX is arrived Friday! Letter will arrive Monday or Tuesday. Of course depends on business if FAX is "point of legal" arrived. Of course only used for business what is usual. It has needed lots of years that FAX is accepted as an way to send an letter with confirmation date/time/content arrived. I do not want that recipient can send me in 30 sec an Email. He should use letter and stamp if I want. If letter head has postage, FAX and Email I can think Email is working same as FAX. Iam not an profesionell and surprised that recipient might be throwing away my Emails or did not read:) Funny if used on an officel letter head:) Of course Iam using Email, but I have the possibilty on an upper level to accept Email to mistersm...@office123.com or I can stop Emails to this address with 5XX /etc/postfix/access_sender mistersm...@office123.com differentEmails Or stop an complete domain sending me Emails /etc/postfix/virtual office123 REJECT use letter and stamp But standard should be my sended Email could not rply and Email server of recipient is not trying to connect my Email server. Thomas
Re: Preferred/maintained greylisting options?
Hello,
> On 25 mai 2020, at 03:59, Vincent Pelletier wrote:
>
> On Fri, May 22, 2020 at 5:43 AM Ralph Seichter wrote:
>> Yeah, delays... Used to be people understood the difference between
>> asynchronous messaging (i.e. email) and instant messaging. Nowadays it
>> seems that no day goes by without somehing along these lines:
>>
>> "Hi. We have not seen you login using this browser, this IP address or
>> during this week. Therefore we have just sent you an email containing
>> a verification code, which will remain valid for 10 minutes."
>
> Personally, I've hacked together a mixed SPF check + greylist milter.
> If SPF check passes, the greylist is skipped, and any other result
> ("do not reject any mail" approach modulo greylisting) goes to greylist.
> The companies which send such emails are likely (in my experience)
> to have a properly setup SPF, so this solved these issues for me.
>
> I'm not planning on releasing the source, it's really an ugly milter, but
> I'm putting the idea out here - and maybe I'll learn it has already been
> done and properly implemented...
I've been using milter-greylist for a very long time, and it does natively
support for years a "nospf" config flag that will allow you to skip greylist
when SPF verification if good. You don't need to hack anything ;)
patpro
Re: Preferred/maintained greylisting options?
I've found the Barracuda rbl to be very useful. https://www.barracudacentral.org/rbl On 2020-05-25 3:21 am, Allen Coates wrote: On 24/05/2020 23:22, micah anderson wrote: We paid for access to spamhaus for a while, but they jacked up the prices and now its far too expensive even for their non-profit rate. What RBLs do people find to be effective now days? I was looking at SpamRats, which I did not know about before, but it looks decent. The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. The ones I use are listed there. Allen C
Re: Preferred/maintained greylisting options?
Allen Coates writes: > On 24/05/2020 23:22, micah anderson wrote: >> We paid for access to spamhaus for a while, but they jacked up the >> prices and now its far too expensive even for their non-profit rate. >> >> What RBLs do people find to be effective now days? I was looking at >> SpamRats, which I did not know about before, but it looks decent. > > > The web page https://www.abuseat.org/faq.html (about half-way down the page) > has an honest - and fairly recent - appraisal of a number of DNSBLs. Its a little outdated... For example: Invaluement DNSBL [Note: Commercial] ivmURI and ivmSIP are good solid and professionally operated lists. ivmURI is a URI (domain) DNSBL like SURBL or URIBL or DBL, with high effectiveness (comparable with DBL/URIBL/SURBL), extremely low false positives, and quick to list. ivmSIP is a IP-based DNSBL which is particularly good at catching "new" emitters. Its FP rate is quite low. Neither of which should be considered substitutes for Spamhaus Zen/Spamcop, but do complement them well. They no longer exist. SPEWS, TQMCube, ORDB, OSIRUS, MONKEYS, DSBL All of these lists have been decommissioned and should not be used. DO NOT USE. The spameatingmonkeys *does* exist. -- micah
Re: Preferred/maintained greylisting options?
On 24/05/2020 23:22, micah anderson wrote: > We paid for access to spamhaus for a while, but they jacked up the > prices and now its far too expensive even for their non-profit rate. > > What RBLs do people find to be effective now days? I was looking at > SpamRats, which I did not know about before, but it looks decent. The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. The ones I use are listed there. Allen C
Re: Uninstalling postgrey
On 24.05.20 21:04, Ian Evans wrote: Based on another thread here, I want to move to using postscreen/postwhite and ditch postgrey. Just want to make sure I don't bungle stopping postgrey. So... - edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" from smtpd_recipient_restrictions. - restart Postfix - purge the postgrey package. Then go about getting postscreen working. I'd set up postscreen before postgrey, that requires editing master.cf too. however, it's quite easy if you follow the docs. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux is like a teepee: no Windows, no Gates and an apache inside...
Re: Uninstalling postgrey
On Mon, 25 May 2020 at 02:06, Ian Evans wrote: > > Based on another thread here, I want to move to using postscreen/postwhite > and ditch postgrey. > > Just want to make sure I don't bungle stopping postgrey. > > So... > > - edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" from > smtpd_recipient_restrictions. > - restart Postfix > - purge the postgrey package. > > Then go about getting postscreen working. I suggest that you get postscreen (and maybe postwhite) working first. And before (or after) purging postgrey do: rm -rf /etc/postgrey. I can't try postwhite because it depends on spf-tools, which don't have install instructions for people who aren't git experts.
