On 2 July 2017 at 14:31, Dusan Obradovic <du...@euracks.net> wrote: > > > On Jun 9, 2017, at 21:45, Steve Jenkins <st...@stevejenkins.com> wrote: > > > > I've got a Postfix server hosting a lastname.org domain name for family > members. > > > > I use virtual aliasing to forward inbound mail for family members to > third-pary mail providers (mostly gmail, but a few yahoo and aol, too). > > > > I've also created user accounts on the server for a very small handful > of immediate family members (4 people) so they can authenticate (via TLS) > send email as firstn...@lastname.org (which is properly DKIM signed and > will pass an SPF check). > > > > I do not provide any mail storage or retrieval on the server (no POP or > IMAP) for any family members. > > > > This has worked fine for years, but now I'm starting to see warnings in > the Postfix log from Gmail, stating that the server is being rate-limited > because of unsolicited messages. I presume that Gmail is sensing SPAM being > sent to the @lastname.org accounts, which gets forwarded to the family > member's Gmail account. I don't do any spam checking or filtering on the > Postfix server. > > > > So my questions are: > > > > 1) What's the best way to forward family members' incoming mail to Gmail > (and other mailers)? > > > > 2) My Postscreen and main.cf sender restrictions are rejecting a fair > amount of inbound spam, but apparently not enough to keep Gmail happy. > > > > 3) Should I consider setting up SpamAssassin with some very low > thresholds to pick up the obvious stuff? > > > > Thanks in advance, > > > > Steve > > When forwarding without SRS - Sender Rewriting Scheme you'll need to > account for SPF failures.
True, but provided your own server is enforcing DMARC (e.g. using opendmarc) it is only a problem for legitimate incoming mails from a domain with p=reject DMARC policy and which are incorrectly DKIM-signed (or are unsigned), and thus depend on SPF (which is broken by relaying) for delivery. Fortunately such instances are rare. My (automated) solution in such a case is to rewrite the response code from the onward server's 550 5.7.1 to 250 2.0.0 and to forward the original email to the original recipient *as an attachment* with an explanatory cover message.
