SV: SSL Certificates

No. That Email copuldn't been authenticated In Gmail jargong, means you have to set up SPF, DKIM and DMARC records. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Henry Skickat: den 15 februari 2017 08:10 Till:

Re: Why no List-ID header in the postfix-users posts?

0]) by dns1.sebbe.eu (Postfix) with ESMTP id 323CB76024B for <postfix-users@postfix.org>; Sun, 12 Feb 2017 02:55:41 +0100 (CET) Date: Sun, 12 Feb 2017 02:55:39 +0100 From: Sebastian Nielsen <sebast...@sebbe.eu> To: postfix-users@postfix.org Message-ID: <3dfb9ae5-1bd8

Re: Why no List-ID header in the postfix-users posts?

I agree about the DKIM signing. I get regularly authentication failures (forensic reports) when posting to this list. Propably because my domain is set to require mandatory DKIM signing and postfix list server isn't. However, I don't think there should be any subject tags. smime.p7s

Re: The "from" header looks like paypal but it is coming from somewhere else. [signed]

edicer.co.uk> skrev: (9 februari 2017 12:11:11 CET) >On 9 Feb 2017 12:53, <li...@lazygranch.com> wrote: > >That is the mailchimp server. (Technically rocketsciencegroup.com) So >has >the email originator figured out some sort of unintended use of >mailchimp? > > > >

Re: The "from" header looks like paypal but it is coming from somewhere else. [signed]

The problem here is that DKIM isn't aligned to paypal.com Enforce strict DKIM alignment on sensitive domains like paypal smime.p7s Description: S/MIME Cryptographic Signature

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!] [invalid signature!]

ILE | grep "postfix/qmgr\[" | grep "from=" -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Christian Ro¨ßner Skickat: den 16 januari 2017 15:17 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: Postfix users <po

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!] [invalid signature!]

.@roessner-network-solutions.com] Skickat: den 16 januari 2017 15:17 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: Postfix users <postfix-users@postfix.org> Ämne: Re: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!] [invalid s

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!]

It do log from=. Default config from debian: root@linuxlite-desktop:/var/log# grep NOQUEUE syslog.1 Jan 15 11:12:37 linuxlite-desktop postfix/smtpd[31407]: NOQUEUE: reject: RCPT from unknown[202.12.83.69]: 554 5.7.1 : Sender address rejected: Access denied;

Re: SPF entries for IPv4 & IPv6

OFC you must specify both unless you have completely disabled sending of outgoing mail via IPv6. Per Thorsheim skrev: (2 januari 2017 14:16:04 CET) >If using IP addresses in SPF records, is it necessary to specify both >IPv4 & IPv6 addresses? Is there currently a risk of

SV: Stopping compromised accounts

This depends on how the accounts are compromised. First of, you should enforce so the MAIL FROM is locked to their account, eg they cannot use another MAIL FROM than they are authorized to use. Second, it then depends on how the accounts are compromised. You say "their local desktop using the

SV: SV: SV: SV: block emails which pretend to originate from my domain

Yeah. The OP presumably had his "permit_sasl_authenticated" both in sender restrictions and relay restrictions. Thats why I gave a example of sender restrictions where I also said that every instance of permit_sasl_authenticated need to be replaced (For example, if one is in recipient restrictions

SV: SV: SV: block emails which pretend to originate from my domain

ostfix-us...@postfix.org] För /dev/rob0 Skickat: den 19 november 2016 19:34 Till: postfix-users@postfix.org Ämne: Re: SV: SV: block emails which pretend to originate from my domain On Thu, Nov 17, 2016 at 05:31:43PM +0100, Sebastian Nielsen wrote: > The advantage with using

SV: SV: block emails which pretend to originate from my domain

inate from my domain On 11/17/16 09:16, Sebastian Nielsen wrote: > You have your permit_sasl_authenticated inside smtpd_sender_restrictions > right? > Replace that with "check_sender_access hash:/path/to/file" ...Right, never mind, reading too early in the morning. > In

SV: block emails which pretend to originate from my domain

15:10 Till: postfix-users@postfix.org Ämne: Re: block emails which pretend to originate from my domain On 11/17/16 04:47, Sebastian Nielsen wrote: > Put check_sender_access hash:/path/to/file INSTEAD of > permit_sasl_authenticated in global config. > > in "/path/to/file",

Re: block emails which pretend to originate from my domain

Don't forget postmap:ing /path/to/file, else it won't work. smime.p7s Description: S/MIME Cryptographic Signature

Re: block emails which pretend to originate from my domain

Put check_sender_access hash:/path/to/file INSTEAD of permit_sasl_authenticated in global config. in "/path/to/file", put mydomain.com permit_sasl_authenticated, reject This will accomplish 2 things: unauhenticated users can't spoof your domain when sending to you. Authenticated users cannot

Re: Blocking users sending spam

I would say that GeoIP would be the best. And those users that need to travel need to pre-request travelling access through a captcha-protected AND geoip restricted web interface prior to travelling. (but once opened, they can extend access out-of-country) And then they need to specify time

SV: Let's Encrypt + Postfix TLS + iOS Mail

You need to be more clear here. When you say Gmail account on port 587 I don’t entirely understand what you are doing. Are you using Gmail as upstream smarthost? This does not then have any bearing on what clients see or react to, as your server acts as a proxy to Gmail. If the iOS mail

SV: DKIM not verifying without signature

You can add "AlwaysAddARHeader yes" Then opendkim will always add a verification header even if no signature. There is also also the following options available: On-BadSignature On-Default On-DNSError On-InternalError On-KeyNotFound On-NoSignature On-Security On-SignatureError Which can

SV: (Semi OT) RBL shakedown

Agreed, they even list AS23456 , which is a reserved AS used for BGP32 routers to annouce themselves to BGP16 routers. (the BGP32 ASN is then embedded in the payload of the BGP16 packet, which result that when this BGP16 router then further annouce themselves to a BGP32 router, the real 32 bit ASN

SV: SV: Open relay

: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För /dev/rob0 Skickat: den 22 oktober 2016 18:29 Till: postfix-users@postfix.org Ämne: Re: SV: Open relay On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote: > Or even better: Accept the mail, but toss it a

SV: Open relay

Or even better: Accept the mail, but toss it away. Eg use, DISCARD instead. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Paul Schmehl Skickat: den 22 oktober 2016 18:20 Till: Paul van der Vlis ;

Route mails containing only digits in user parts differently

of course, sending to these adresses should be considered relay, eg if you aren't permitted to relay through the server, any mail to a adress whose user-part contains only digits, should be rejected, for obvious security reasons. Best regards, Sebastian Nielsen smime.p7s Description: S/MIME Cryptographic Signature

Re: Is my server mail account being attacted?

No, fail2ban would also block legitimate users where the user may have flaky connection and doing one or more connections and not authenticating. The SSL attempts for http could be blocked with fail2ban. The other SSL attempts attempting to negotiate a old version, may block legitimate users

Re: Is my server mail account being attacted?

Looks rather like a scanning attack (finding vulnerabilities). I think they are trying to do a SSL type of attack like HEARTBLEED but your server isn't vulnerable. Looks also like they are sending HTTP requests (encapsulated in SSL/TLS) to a mail server, which seems to be a extremely stupid bot

SV: Restriction question

can be misused. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Mark Holmes Skickat: den 18 oktober 2016 21:54 Till: 'Sebastian Nielsen' <sebast...@sebbe.eu>; postfix-users@postfix.org Ämne: RE: Restriction question

SV: said: 421-4.7.0 This message does not have authentication information

You need to set up either SPF or DKIM, so GMAIL can detect spoofed mail. I would recommend SPF, its easiest. Just add the following to your DNS: @ IN TXT ”v=spf1 ip4: -all” (repeat the ip4 command if you have multiple servers, ip6 is for IPv6) Or: @ IN TXT ”v=spf1 mx -all” If your

SV: TLD blocking revisited

ch more "damage" in time spent for the user deleting the crap from the inbox. But I agree, that if you get those "regular" spammers that doesn't pay attention to RFCs at all, then its better rejecting it. -Ursprungligt meddelande- Från: Jim Reid [mailto:j...@rfc1035.com] Sk

SV: TLD blocking revisited

I would really suggest using DISCARD instead of "500 This TLD sends spam - g e t lost.". Thus the spammer dosen't get to know he got stuck in a spam filter and can update their tools to bypass it. DISCARD accepts the mail but throws it into /dev/null -Ursprungligt meddelande- Från:

SV: TLD blocking revisited

Im using the following to block TLDs, but not in helo checks, im using sender checks instead: /\.bid$/ DISCARD /\.top$/ DISCARD /\.xyz$/ DISCARD /\.pro$/ DISCARD /\.date$/ DISCARD /\.faith$/ DISCARD /\.download$/ DISCARD DISCARD blocks the mail without telling the sender the mail was blocked so

SV: SV: advice on securing a transport

LazyGranch: I look it at the point of view of the server who are receiving the mail. So basically, the OP has some email adress like "webapprecei...@example.org" that receives mail and processes this automatically into a database. Only authorized users are allowed to send to this specifically

SV: advice on securing a transport

mails and do CRUD stuff with the database.‎" Normally we read our email from a delivery agent like dovecot, but this mail will, if I understand the objective, with be "machine" read. That step is where you want to enforce SPF and DKIM. Original Message From: Sebastian

SV: advice on securing a transport

There is possibility to use SPF or DKIM to ensure the sender is not spoofed. For this particular service, you can run your SPF and/or DKIM validator in mandatory mode, eg, a missing SPF record will be treated as -all, and a missing DKIM signature is treated as a invalid one. Then you can actually

SV: How to restrict encrypted email

The problem you got, is that the encrypted content has already travelled the amateur frequencies even if you block/reject the mail. Thus the rules are already broken, thus you should deal with those users in a "AUP" way even if the mail gets blocked. Better might be to block this in firewall then.

SV: Configuration for rate limited Amazon SES relay [invalid signature!]

I think Amazon will detect this type of behaviour, eg accepting unlimited rate, and then "squeezing" it through amazon's rate limit system. Its possible because there is timestamps and other information that can be used to deduce if a mail has been put through a automatic rate limiter to bypass

SV: SV: poor repution work arounds? standby smtp?

spambots and malware stealing and guessing submission accounts for the purpose of sending spam. Best regards, Sebastian Nielsen -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Voytek Skickat: den 6 juni 2016 15:21 Till: postfix-us

SV: poor repution work arounds? standby smtp?

First, most servers cache the blacklist lookup, so it will persist for 1-2 days. Second, the problem is that you will only get your backup server blacklisted/poorreputated aswell. I would suggest solving the underlying problem instead, so accounts is harder to compromise, by implementing a few

SV: Different SMTP AUTH options and credentials for different clients

You would need to use a firewall for this. Use master.cf to define 3 different SMTP servers, that implements the 3 different rulesets and different credentials files. So for example, you set up 3 servers, One at port 26 that allows relaying without authentication. One at port 27 that allows AUTH

SV: Telnet auth

Yeah, it do break forwarding where stupid mailservers (or more correctly, mailservers configured by stupid admins) just forward the mail verbatim, and even forge the MAIL FROM to the destination server. That is the thing that causes SPF to fail when for example: My server --> Receivers Company

SV: SV: SV: Telnet auth

[mailto:owner-postfix-us...@postfix.org] För Noel Jones Skickat: den 18 maj 2016 23:28 Till: postfix-users@postfix.org Ämne: Re: SV: SV: Telnet auth On 5/18/2016 3:46 PM, Sebastian Nielsen wrote: > It is actually possible to use multiple results when using the > built-in restriction co

SV: SV: Telnet auth

It is actually possible to use multiple results when using the built-in restriction commands (permit_sasl_authentication, permit_mynetworks, reject, etc) (Eg, words that can be used in the rules chain instead of "check_sender_access") Then they will be inserted in the rule chain just where the

SV: Telnet auth

Yes. Remove permit_sasl_authenticated and permit_mynetworks. Then add the following rule instead, immediately BEFORE reject_unauth_destination: check_sender_access hash:/etc/postfix/relay_auth Inside the file relay_auth, which must be postmap:ed, you have the following: yourdomain.com:

SV: domain rewrite/redirect [invalid signature!]

Simplest way is to add mail.example.com to your mydomains. Then mails both to t...@mail.example.com and t...@example.com will arrive to the account “test” on your server. Same is for example recommended to do with domain literals (IP

SV: Special method required for Gmail dkim/spf verification

I have noticed this aswell, when badly configured forwarding servers don't forward their mails correctly. For example, take a example that: someu...@somecorporation.com is forwarded to some.u...@somefreewebmail.com You send a mail to someu...@somecorporation.com Later on, you get a DSN (because

SV: Proposal: SMTP client policy protocol (for STS)

I would also suggest supporting standard pipes. Like smtp_check_tls_policy = pipe:/usr/sbin/some_script.pl Preferable, for performance, the script will be long-running in a loop and accept questions on and spit out responses on -Ursprungligt meddelande- Från:

SV: Thousands of login attempts

I would instead suggest the opposite way around, use whitelisting instead. Whitelisting can be done in many ways: 1: You can either whitelist your customer's IP ranges. So if one customer has Telia in Sweden, you tell your firewall to allow 95.196.0.0/14. And so on for every customer/user. 2:

SV: MAIL FROM validiity

SPF and DKIM is mail tools to prevent spoofing of non-local domains. OP was out after tools to prevent local spoofing. One is for example: 1: reject_sender_login_mismatch 2: Other is a check_sender_access table containing "yourdomain.com: permit_sasl_authenticated, reject". 3: Another one is

SV: MAIL FROM validiity

: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Pascal Maes Skickat: den 14 mars 2016 12:50 Till: postfix-users@postfix.org Ämne: Re: MAIL FROM validiity > Le 12 mars 2016 à 17:28, @lbutlr <krem...@kreme.com> a écrit : > > On Mar 10, 2016, at 10:1

SV: MAIL FROM validiity

Create a file containing the following (where yourdomain.com is the domain your authenticated users send from): yourdomain.com: permit_sasl_authenticated, reject postmap the file. Then use: smtpd_recipient_restrictions = ... check_sender_access hash:/path/to/file ...

SV: SV: Security: How to limit authentication attempts?

be dropped after a ban. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Kiss Gábor Skickat: den 21 februari 2016 12:11 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: postfix-users@postfix.org Ämne: Re: SV: Security: How to

SV: Security: How to limit authentication attempts?

To make sure fail2ban breaks the connection, you need to put the fail2ban rules BEFORE any "ESTABLISHED,RELATED" rule. Then it will simply drop the packets regardless of if the connection is in the firewall's state table or not. smime.p7s Description: S/MIME Cryptographic Signature

SV: SV: SV: SV: Blocking TLDs

-- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Robert Schetterer Skickat: den 20 februari 2016 13:49 Till: postfix-users@postfix.org Ämne: Re: SV: SV: SV: Blocking TLDs Am 20.02.2016 um 12:01 schrieb Sebastian Nielsen: > Why are you people so negative against

SV: SV: SV: Blocking TLDs

s@postfix.org Ämne: Re: SV: SV: Blocking TLDs On 2016-02-20 00:52, Sebastian Nielsen wrote: > 1: REJECT tells the spammer "Hey, your spam got stuck in the spam > filter. Wanna try again?". if thay do, so what ?, its not possible for spammers to make remote administoring on postfix this wou

SV: SV: access permissions 101

Skickat: den 20 februari 2016 10:26 Till: postfix-users@postfix.org Ämne: Re: SV: access permissions 101 On 20/02/16 02:05, Sebastian Nielsen wrote: > Everytime I need multiple processes to access the very same file and those > processes has interlocks that prevent them from running as the sam

SV: access permissions 101

le to just get things working? Its not like a list of banned spam domains is something super-sensitive. -Ursprungligt meddelande- Från: Jim Reid [mailto:j...@rfc1035.com] Skickat: den 20 februari 2016 01:40 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: postfix-users@postfix.

SV: SV: Blocking TLDs

wner-postfix-us...@postfix.org] För A. Schulze Skickat: den 19 februari 2016 23:52 Till: postfix-users@postfix.org Ämne: Re: SV: Blocking TLDs Sebastian Nielsen: > Then paste all the DISCARD lines into a new file called > /etc/postfix/banned_tlds (and also add some own TLDs there

SV: Blocking TLDs

: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org] Skickat: den 19 februari 2016 23:19 Till: 'Sebastian Nielsen' <sebast...@sebbe.eu>; postfix-users@postfix.org Ämne: RE: Blocking TLDs Just copy and passed the DISCARD contents into banned_tlds? From: owner-postfix-us...@postf

SV: Blocking TLDs

smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/banned_tlds banned_tlds: /\.bid$/ DISCARD /\.top$/ DISCARD /\.xyz$/ DISCARD /\.date$/ DISCARD /\.faith$/ DISCARD /\.download$/ DISCARD Problem solved. Från: owner-postfix-us...@postfix.org

SV: Can this sort of spam be easily and safely blocked in postfix [signed]

-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Sebastian Nielsen Skickat: den 15 februari 2016 10:53 Till: 'postfix users' <postfix-users@postfix.org> Ämne: SV: Can this sort of spam be easily and safely blocked in postfix [signed] Yes, there is a reason. If the

SV: Can this sort of spam be easily and safely blocked in postfix

Yes, there is a reason. If they have a large amount of virtualized servers set up using wildcarding, like: *.123.123.123.in-addr.arpa IN PTR mailservers.office365.com Its of course not possible to add the corresponding forward record, because that would create a pretty large forward zone,

Discard all emails containing the text "#364811"?

Is it anyway I can in postfix, use a simple rule to DISCARD all email containing the text " #364811"? (Its a HTML color being used in a lot (>95%) of spams currently arriving in my server, and that color do not change). smime.p7s Description: S/MIME Cryptographic Signature

SV: Deliver all mail from one domain to two servers [invalid signature!]

Try a recipient_bcc_maps using pcre: Eg, something like this: /^([^\@]*)\@yourdomain\.com$/ $1...@new.server.com (first part is "match anything that does not contain a @", second is a literal @, and the final part is the external domain that your border server receives mail on) (Note, test

SV: PCRE regex in header_checks ignored - why?

I would suggest use check_sender_access intead of header checks. Then you can reject based on MAIL FROM:, since apparently the hosts are using their e**. hostname in MAIL FROM. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För

SV: PCRE regex in header_checks ignored - why?

nsure, use REJECT instead). Best regards, Sebastian Nielsen -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Sebastian Wolfgarten Skickat: den 31 januari 2016 14:03 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: postfix-u

SV: Adding a noreply address

I would suggest against this, since there is a risk that servers aren't supporting this, and might deny the mail, discard it (send it to /dev/null, which I do with obvious spam), quarantine it or sort it to the end user's spam folder. Its better to set up a nore...@yourdomain.tld adress set to

SV: 53% of Postfix servers are black-listed (DNSBL)

itch to a new domain, but DISCARD works perfectly, the spammer won't notice the mail got rejected). Best regards, Sebastian Nielsen -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För sb Skickat: den 29 december 2015 13:02 Till:

SV: allow by IP?

You could use smtpd_client_restrictions = check_client_access cidr:/etc/postfix/access , and then use DUNNO For each allowed IP/subnet (note the "cidr" db type) This will pass on the restriction to next stack. Then you finalize with 0.0.0.0/0 REJECT I would suggest putting check_client_access in

SV: Sanitizing email sent from webapp

Now I want to know what you mean with "potential source of spam". If you are afraid of the site getting hacked, theres nothing you can do, as with "local postfix", I assume both postfix and the website runs off the same machine. Regardless of which settings you do on the postfix, a attacker can

SV: non-existent users submitting email qmgr as localhost

Then you have some local process that is compromised. Areas to check: Do you have a password reminder sending service? Do you have other automated email facilies? Check if some user on your server has became rogue Check if some process on the server are abusing sendmail Do you have a mailing

Re: postfix and multiple TLS certificates (SNI support?)

The certificate is normally validated against the MX name, not recipient domain. Example: emailservice1.com MX smtp1.example.org emailservice2.com MX smtp1.example.org Certificate is issued to smtp1.example.org Also even if you use SNI, imagine you send a mail to a user at emailservice1 AND

Re: postfix and multiple TLS certificates (SNI support?)

ere is the problem, and why there is a need to use the MX identity to tie the certificate to the server. To protect against modified MX data, DNSSEC has to be used instead. -Ursprungligt meddelande- From: Michael Ströder Sent: Tuesday, December 15, 2015 10:51 AM To: Sebastian Niels

SV: Is this a correct way to define PCRE lists?

: list before, but now I noticed they started spamming from certain TLD so I had to change into a pcre:. Best regards, Sebastian Nielsen -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Bill Shirley Skickat: den 13 december 2015 05

Is this a correct way to define PCRE lists?

I have a check_sender_access to weed out spam from spam domains. The check_sender_access is a pcre: list. And the pcre list is: /mediablueinc.cf$/i DISCARD /mediablueinc.com$/i DISCARD /mediablueinc.ga$/i DISCARD /abstreeltg.eu$/i DISCARD /\.top$/i DISCARD (Yeah, the .top

Re: Conditional Greylisting

I think he is out after doing a temporary fail after the DATA stage, thus avoiding the chicken and egg problem. -Ursprungligt meddelande- From: Wietse Venema Sent: Friday, September 18, 2015 7:50 PM To: Postfix users Subject: Re: Conditional Greylisting Bruce Marriner: I'd like to

Re: Forward rejected by yahoo

right about the real MAIL FROM that is set to "Return-Path: <owner-postfix-us...@postfix.org>" -Ursprungligt meddelande- From: Wietse Venema Sent: Friday, September 18, 2015 7:43 PM To: Postfix users Subject: Re: Forward rejected by yahoo Sebastian Nielsen: Yeah, all

Re: Forward rejected by yahoo

Thats exactly what im talking about, this DMARC Strict Identity Alignment. If a host only publishes a SPF record (no DKIM record), and sets up DMARC with Strict Identity Alignment, then you will need to rewrite or encapsulate the From: & MAIL FROM adress on any forwarded email to match your own

Re: Forward rejected by yahoo

to encapsulate email like you press "Forward" in your mail client. -Ursprungligt meddelande- From: Benny Pedersen Sent: Friday, September 18, 2015 6:23 PM To: Sebastian Nielsen ; postfix-users@postfix.org Subject: Re: Forward rejected by yahoo On September 18, 2015 4:40:52

Re: Forward rejected by yahoo

No. SPF is designed to be secure, eg you cannot add some header to bypass the authentication, then every phisher would add such a header. What you need to do, is to rewrite the FROM adress or encapsulate the email. Rewriting FROM adress can be as simple as rewriting yourn...@yahoo.com to

Re: Forward rejected by yahoo

Neofita Sent: Thursday, September 17, 2015 8:12 PM To: Sebastian Nielsen Cc: postfix-users@postfix.org Subject: Re: Forward rejected by yahoo Thank you very much for the fast reply. I was looking on sieve or postfix and I do not find how I can do it. Since I believe that will be the best way

Re: Forward rejected by yahoo

Pedersen Sent: Thursday, September 17, 2015 11:26 PM To: postfix-users@postfix.org Subject: Re: Forward rejected by yahoo Sebastian Nielsen skrev den 2015-09-17 19:51: Then you host a own SPF record. no no no no and no SPF is not From: body header do you think about SenderID ? sid-milter

Re: keeping off brute force password attempts

My suggestion is instead extending the logic to prevent bruteforce instead. For example: If you run a webhosting company, use geoIP to disable logins to accounts that do not originate from the same country as their payment method. Since this rule are set up account-wise, you can still easily

Problem filtering broken PGP mail with body_checks

Im trying to filter broken PGP mail into usable mail with body checks. I have selected to use pcre: when defining body_checks. The problem is that certain PGP useragents, inserts a \r charachter, a tab, space, or any other whitespace char immediately before or after the “-BEGIN PGP

Re: Problem filtering broken PGP mail with body_checks

Yep. On top of that: ([^-]*) means any charachter except for -, so it shouldn't match any -, and thus $2 cannot contain the charachter "-" at all. I suspect that postfix in some way matches the whole message in once, and when the REPLACE word is given, the whole message, even including parts

Re: SPF and forwarding

No. Thats whats SPF is designed to prevent. Else every phisher would claim they forwarded the email, to bypass the whole SPF security system. There is two options here, except for disabling forwarding altogether and require gmail owners to fetch instead: Either, you replace the MAIL FROM and

Re: Question about DSN

As the subcodes say that transformation was required for delivery, it sounds like the mail was converted across formats, or content was omitted. This can happen if a server decides to strip all attachments or the mail did contain something unparseable that the server decided to pass along

Re: encrypt incoming emails with my public gpg key

I would suggest using Ciphermail / Djigzo for this. But I think you are solving your problem in a very incorrect way. Since the hosting company do have access to the VM, they could easy listen on the memory before the mail is encrypted, just after it has been decrypted by the TLS handler. If

Re: encrypt incoming emails with my public gpg key

to the hosting company. B: Change hosting company to a more trusted one. -Ursprungligt meddelande- From: Thomas Keller Sent: Wednesday, June 03, 2015 1:32 AM To: postfix-users@postfix.org Subject: Re: encrypt incoming emails with my public gpg key On 2015-06-03 01:16, Sebastian Nielsen

Re: Need advice from SPF/DKIM/DMARC experts

I would suggest explicity null:ing the SPF signature instead of passing it, for list mail. This is done with v=spf1 ?all A null SPF signature is same as no signature at all (same as if the SPF record didnt exist at all), which will pass your mail into your mailsystem, but the mail will not be

Re: problem with spam

I suspect any of your authenticated users are compromised, eg that a dictionary-attacking or brute-forcing bot managed to figure out the password for one of your accounts. I had authentication enabled on my server once, and you know, the logs were HUGE with 'bots' trying to authenticate

Re: problem with spam

down to the customer’s billing country, or employ 2FA authentication. From: Christos Chatzaras Sent: Sunday, May 24, 2015 1:01 PM To: Sebastian Nielsen Cc: postfix-users@postfix.org Subject: Re: problem with spam I do shared hosting, so users should be able to use any ISP to connect. postconf

Re: problem with spam

Are you entirely sure that no user credentials are hacked? Note that a dictionary-attacked or bruteforced password is undetectable, and could have happened months ago. Eg, a bot could have cracked the password, saved it into a database, and then the owner of that bot sold the accounts to a

Re: proof-of-work principle applied to mail sending protocol(s) - spams

system to enforce different delay periods for different hashcash bit levels, so even weak hashcashes are accepted partially. -Ursprungligt meddelande- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:31 AM To: Sebastian Nielsen ; postfix-users@postfix.org Subject: RE: proof

Re: proof-of-work principle applied to mail sending protocol(s) - spams

IT do already exist: http://www.hashcash.org/ Im already using it. See this mail, you find this header: X-Hashcash: 1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb Thats a proof-of-work system with hashcash. Im currently have a module in my

Re: Blocking compromised accounts (outgoing spam) and auth cracking

I think you are approaching this problem from the wrong end. Instead of blocking compromised accounts, make sure they cannot be compromised. For example: Configure your server to only accept authentication from valid IPs, for example company internal ones, or implement geoIP blocking so if

Re: Blocking compromised accounts (outgoing spam) and auth cracking

on that computer, and also will make cellphone mail completely unusable. Quoting Sebastian Nielsen sebast...@sebbe.eu: I think you are approaching this problem from the wrong end. Instead of blocking compromised accounts, make sure they cannot be compromised. For example: Configure your server to only

Re: per-user attachment blocking?

I would say its better to strip unauthorized attachments instead of blocking the whole message. A notice could be appended to message informing about the stripped attach. This because some email clients/MTAs insert their own attachments, and user cannot control this. The attachments in many

Re: per-user attachment blocking?

could either blacklist those reckless users that always clicks on greeting cards they get in email, or whitelist those good users which does maintain a good computer hygiene, thus not inflicting normal email communication. Best regards, Sebastian Nielsen smime.p7s Description: S/MIME

Re: port 25 465 and 587 confusion.

IMHO I find it better to only allow submission from trusted nets. Better to disable authentication completely, and completely disable mail submission (relaying) from the outside. Thus closing 587 completely. 465 can be good to allow old (or misconfigured) SMTPS servers to send incoming mail to

Re: port 25 465 and 587 confusion.

What I meant is that if your users are on a dynamic IP from a “outside” net, you can allow that net *in combination* with authentication. Thus, you will both need to be from the correct net, but also have a valid username and password. For example, lets say you have a internal company network

Re: Add header with original IP?

, Sebastian Nielsen wrote: How can I in postfix add a header with the original client IP (like “X-Original-IP”), such as, it cannot be forged, eg any incoming mail will have such headers stripped out, before Postfix adds its own. The intention of this header is to use it at a later processing step

  1   2   >