REJECT and save a copy of spam?
I'm configuring Postfix with SpamAssassin, using Spampd as a before-queue filter. I put "/^X-Spam-Flag: YES/ REJECT Spam detected" in /etc/postfix/header_checks, and that works (spam is rejected during SMTP as desired). However, it would be nice to _also_ keep a copy of the rejected messages somewhere for later analysis. Either deliver them to a special local user, hold in the queue, or whatever else is convenient. Is there an easy way to do this? I guess I could modify Spampd to save a copy of spam messages, but I was hoping there might be a way to configure Postfix to do this. If it matters, this is Postfix 2.6.6 on CentOS 6. Thanks. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: REJECT and save a copy of spam?
Once upon a time, Wietse Venema said: > But this matters only if you really want to give a REJECT response > to the remote SMTP client. I would prefer to do that for this particular setup. This is a low-traffic domain, mostly just forwarding to other domains; there are a couple of mailing lists and a ticket system; no mail gets normal local delivery. Nobody would normally be checking a spam box, so any messages that hit would effectively disappear. In the old setup (sendmail+mimedefang+SA), it has been useful that "spam" is rejected so that legit senders get a notice, and that the message gets saved (so I can review when somebody complains). Thanks; I guess I'll take a look at amavis. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: REJECT and save a copy of spam?
Once upon a time, Wietse Venema said: > Postfix supports Milter too. There are some differences but it might > just work. Oh yeah, I know that (I just wrote a milter for some servers at work running postfix). I was trying to avoid the extra overhead (and config management work) of mimedefang/amavis since I was just looking for basic spam blocking. Thanks. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Cleaning out certain 4xx-errors
Once upon a time, Wietse Venema said: > Maybe PLESK has an option to make "mailbox full" a hard error (to be > honest, Postfix's own "mailbox full" action is not configurable). Unfortunately, no, it isn't. Plesk uses a milter to check delivery status during SMTP (which is nice, since that way it doesn't queue and cause back-scatter), but only returns a temporary error for over quota. Worse, it doesn't check until the end of DATA, so if any one recipient is over quota, the message is rejected (so you really don't want to turn a Plesk over-quota message into a permanent error, at least for messages with multiple recipients). I wrote a milter for our Plesk servers to check quota at RCPT TO time instead (and return a permanent error for over-quota) to fix the bad behavior. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Cleaning out certain 4xx-errors
Once upon a time, /dev/rob0 said: > On Sat, Sep 15, 2012 at 06:50:38PM -0500, Chris Adams wrote: > > I wrote a milter for our Plesk servers to check quota at RCPT TO > > time instead (and return a permanent error for over-quota) to fix > > the bad behavior. > > Unfortunately that only replaces one potential problem with another. > You're relying on SIZE in the MAIL command, which might be wrong or > might be omitted. The only sure way to know the actual size of the > mail is to receive the DATA. I've found it to be a "good enough" solution. My checker takes the SIZE argument from MAIL FROM; if it isn't there, it assumes the largest message the server allows. It also adds a little to the size to allow for local headers (local Received: line, From_ header if mbox, etc.). This means that if the remote system doesn't set SIZE, it is possible for some small messages to be rejected that could have just fit under the quota. Almost all legitimate servers set SIZE; the only place I typically don't see it is from clients (and IIRC some do set it, but not from Microsoft). This also doesn't handle multiple messages come in at a time (especially if one is a large message from a slow remote system). > P.S.: I complied with your Reply-To: and sent the Cc:. It will fail > SPF, if you're checking that. That's not me; that's the list. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Cleaning out certain 4xx-errors
Once upon a time, Wietse Venema said: > Chris Adams: > > > P.S.: I complied with your Reply-To: and sent the Cc:. It will fail > > > SPF, if you're checking that. > > > > That's not me; that's the list. > > I think he refers to this: > > Mail-Followup-To: Chris Adams , > Postfix users > > This sits among other headers that were added by your Mutt/1.4.2.2i > mail reader. Ah, that looks like a bug in mutt. It isn't supposed to put the sender's (my) address in there for configured mailing lists (the idea is to prefer replies to the list without a direct CC). Still not sure what that would have to do with SPF though. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: postscreen dnsbl weighting with new(est) spamhaus return codes -- experiences/data?
Once upon a time, PGNd said: > On quick investigation, @ spamhaus now says > (http://www.spamhaus.org/news/article/713/) return codes have changed: Those are dbl response codes, not zen. You are mixing the two up, but they are very different. -- Chris Adams
relay access denied question
Hello all, I recently rebuilt a server for use with Mailman and Postfix. I have the server running, Mailman and Postfix installed. I am using Postfix 2.10.1. I copied the main.cf file over from the old server to the new server. When I post a message to one of the Mailman lists, I encounter an error related to Postfix and I can't quite figure out what setting in main.cf is causing this. It looks like all messages are being handled this way. I am wondering what is different in this new setup that would cause this. May 3 16:59:58 mailmanserver postfix/smtpd[18060]: NOQUEUE: reject: RCPT from localhost[::1]: 454 4.7.1 : Relay access denied; from= to= proto=ESMTP helo= I can provide output of postconf -n if requested. Many thanks.
Problem with smtpd_sasl_local_domain
I'm setting up Postfix+Dovecot on CentOS 7 (prefer to use the OS-provided versions, Postfix 2.10.1 and Dovecot 2.2.10). I need to handle SMTP AUTH for a couple of different domains where the customer doesn't want to make their users change from "username" to "usern...@example.com". I have tried doing this with different listeners on different IPs in master.cf, like: 10.1.1.2:25 inet n - n - 150 smtpd -o mydomain=example.com -o mynetworks=$mynet,cidr:/etc/postfix/mynetworks-example.com -o smtpd_sasl_local_domain=example.com That did not work, because Postfix doesn't appear to do anything with the realm, verified both by process tracing and looking at the source code. The Postfix Cyrus SASL code passes the realm, but the Postfix Dovecot SASL code only references it in a log entry (this appears to be the case even with the latest Postfix 3.1 snapshot). Am I missing something? Is there another way to do this? -- Chris Adams
Re: Problem with smtpd_sasl_local_domain
Once upon a time, Wietse Venema said: > Chris Adams: > > I'm setting up Postfix+Dovecot on CentOS 7 (prefer to use the > > OS-provided versions, Postfix 2.10.1 and Dovecot 2.2.10). I need to > > handle SMTP AUTH for a couple of different domains where the customer > > doesn't want to make their users change from "username" to > > "usern...@example.com". > > > > I have tried doing this with different listeners on different IPs in > > master.cf, like: > > > > 10.1.1.2:25 inet n - n - 150 smtpd > > -o mydomain=example.com > > -o mynetworks=$mynet,cidr:/etc/postfix/mynetworks-example.com > > -o smtpd_sasl_local_domain=example.com > > > > That did not work, because Postfix doesn't appear to do anything with > > the realm, verified both by process tracing and looking at the source > > code. The Postfix Cyrus SASL code passes the realm, but the Postfix > > Dovecot SASL code only references it in a log entry (this appears to be > > the case even with the latest Postfix 3.1 snapshot). > > You mean: Dovecot SASL logs but otherwise ignores the realm? In > that case, the question is better asked on the Dovecot mailing list. No, I meant what I said: it is Postfix that logs but otherwise ignores the realm in the Dovecot SASL code path. In the Postfix source, src/xsasl/xsasl_dovecot_server.c, in the xsasl_dovecot_server_create() function, if args->user_realm is set, it gets logged (if verbose logging is enabled). It is not otherwise referenced in the Postfix code that talks to Dovecot. -- Chris Adams
Re: port 25 465 and 587 confusion.
Once upon a time, Muhammad Yousuf Khan said: > now the confusion part is my concept. does port 25 and 465 work together > like FTP. port 21 and 20. like 1 port is for negotiate and another port is > for data? Port 25 is tradtiotional SMTP, aimed at server<->server communications now (and blocked by some consumer ISPs to reduce spam). It starts in the clear but can support STARTTLS to switch to encrypted communication. Port 587 is the "submission" port for SMTP. It works the same as port 25 (including clear communications and STARTTLS support), but is intended for client<->server communication for initial message submission. It should require SMTP AUTH (so only authenticated mail can be submitted). Port 465 was an early (non-standard) SSL-wrapped SMTP port. All communication is encrypted (similar to port 443 for HTTP). This was never an IANA-assigned use, and not that many things support it. Its use is deprecated, but MS Outlook (at least some versions) only support SSL-wrapped SMTP on port 465 (they don't handle the standard way of connecting to 587 and then issuing STARTTLS). -- Chris Adams
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
Once upon a time, Scott Kitterman said: > Great. Feel free to throw RFC 7208 Section 3.4 (Record Size) at them. The > SHOULD fit in a UDP packet is there for a reason. I see your RFC and raise you RFC 6891. "[f]it in a UDP packet" does not mean 512 bytes. -- Chris Adams
Re: Postfix + Courier or Dovecot?
Once upon a time, Eric Broch said: > that courier chokes on large mailboxes, but I never experienced that. It > always performed well for me. I recently switched an install of about 55,000 mailboxes (mostly telco/ISP customers) from Courier to Dovecot. The mail spool is on a backend accessed over NFS; the NFS network traffic dropped significantly (from around 300 megabits per second to about 20 megabits per second) after the switch. Our backend has an SSD read cache to (mostly) keep up with the load with Courier, and now with Dovecot, the SSD is essentially unused (the working set fits in the storage array RAM cache). Depending on your access patterns, Dovecot indexing can be a huge win. Also, Dovecot management is far superior. For example, we have mailbox quotas, which with Courier were just stored in a file in the Maildir. That file had to be regenerated periodically (scanning the whole mailbox), and there was no quick way to check the quota status (it took reading 55,000 files). Dovecot can store quotas in a database, so checking them now is one SELECT (that takes a fraction of a second) away. -- Chris Adams
