SPAM dyke is working great but I am also getting false positives from my clients SPF records.
Back to the NAT issue. spandyke is testing SPF records against it’s local internal IP and failing to send the traffic. Mail administrators are not keen to adding non routable IP addresses to their SPF allow lists because anyone can forge this IP through a personal NAT. So back to the NAT question. Would there be a way to tell spamdyke that it’s local ip is really the outside routable IP of the NAT ? On Mar 10, 2014, at 1:20 PM, Eric Shubert <[email protected]> wrote: > FWIW, I set up my servers to authenticate using a "relay" account when > sending emails for logwatch, cron and such. They all use the same account. I > haven't bothered setting up any restrictions regarding turning off imap and > pop3, nor doing anything about receiving email for that account. For handling > inadvertent messages to this account, I suppose I could either forward them > somewhere, give the account 0 quota, or put that address in the > /var/qmail/control/badmailto (and badmailfrom I suppose) files. > > At some point in time I suppose it might be nice for qmailadmin to have an > option "relay-only" for accounts which would set things up appropriately for > such accounts. Don't hold your breath on this though. ;) > > Anyone? > > -- > -Eric 'shubes' > > On 03/10/2014 04:07 AM, Scot Needy wrote: >> Just wanted to sound off the list as I would have figured this to be a >> common requirement that has been solved many times over. >> >> >> On Mar 10, 2014, at 5:24 AM, Eric Shubert <[email protected]> wrote: >> >>> On 03/09/2014 08:01 PM, Scot Needy wrote: >>>> Yes, I could, but I was really hoping to avoid managing psudo users as >>>> employees come and go from support here as well as AD. >>>> >>>> A single common account and password seems to be the best way to handle >>>> this One password to change when an employee leaves. >>>> >>>> That account would only be used for sending. I would need to block pop >>>> access and prevent the mailbox from storing mail. >>>> >>> >>> That sounds practical to me. >>> So what's the problem? >>> >>> -- >>> -Eric 'shubes' >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
