Re: implementing offline/maintenance mode, with SMTP reply?
On 10/16/20 11:54 AM, Viktor Dukhovni wrote:
If the custom 4XX response is not a hard requirement, the simplest
solution is:
main.cf:
# To defer all email, change to: lunchtime = y
lunchtime =
smtpd_recipient_restrictions =
${lunchtime?defer_if_permit}
...
Which will still reject invalid recipients, ... and only defer what
you'd otherwise accept.
hadn't thought to defer.
this should work nicely. thx.
tho, s/lunchtime/cocktails/ might be needed.
If you really must have a custom 4XX response, then you can use:
main.cf:
# To defer all email, change to: lunchtime = y
lunchtime =
smtpd_client_restrictions =
${lunchtime?check_client_access static:{450 4.3.2 Scheduled
downtime, come back later}}
...
Note that sites that do sender-address-verification (does anyone still
do that?) may then tempfail your outbound mail, during the downtime and
likely for some time after after you restore service.
noted.
unfortunately plenty of financial institutions do.
one fail-to-deliver and they toggle user prefs back to snail-mail -- AND send a "we
were unable to deliver to your email" _letter_.
the avalanche of dead-tree propectuses roll nicely into firelogs ...
address verify probe cache not refreshing on new user/alias add'n ?
i've set up two postfix instances on 2 separate machines
frontend
backend
'backend' gets user data via postfixadmin/sqlite3 DB
i've setup address verification between the instances
on mail receipt @ 'frontend', a verify probe is sent to 'backend'.
if 'exists', then mail is sent frontend->backend; otherwise, rejected.
it works as intended.
except -- updates to user DBs at backend aren't being made available promptly.
if I add a mail alias at backend, via postfix admin, and immediately try to
send to 'frontend' @ that address, it fails the verify probe.
restarting/reloading the 'backend' postfix doesn't fix the probe fail.
but,
rm -f /var/lib/postfix/{verify,postscreen}_cache.lmdb
postfix reload
atm, here
postconf -n | egrep "address_verify"
address_verify_cache_cleanup_interval = 12h
address_verify_map = lmdb:${data_dir}/verify_cache
address_verify_poll_count = ${stress?{1}:{3}}
address_verify_sender = pr...@verify.mx.example.net
address_verify_sender_ttl = 28657s
notably,
address_verify_sender_ttl = 28657s
is changed from default
address_verify_sender_ttl = 0s
per docs, i'd originally set this, way back when, to "avoid problems with senders that use
greylisting" and "To defeat address harvesting ..."
re-reading now, i'm not so sure.
(1) _is_ the likely cause of the verify probe fail due to my config, above? or
am i looking in the wrong place?
(2) beyond possibly causing the probe cache issue, are there particular reasons
_not_ to set
address_verify_sender = pr...@verify.mx.example.net
address_verify_sender_ttl = 28657s
?
Re: Accessing the sending user from a canonical(5) table
Demi M. Obenour: > Should I submit another patch? In addition to adding > local_sender_login_maps, I have fixed what appeared to be a bug in > the current postdrop and sendmail commands: root and $mail_owner were > not automatically allowed to submit mail. Since this is inconsistent > with similar checks elsewhere, I believe it is unintentional. No. I am working on a quality implementation, and that takes more time than 'code that works'. More patches are not needed. BTW I realized that I swapped the semantics of smtpd_sender_login_maps (a mapping from sender address to the login names that are allowed to use that sender address) when we were discussing the postdrop feature (a mapping from login name to the sender addresses that the login name is allowed to use). If we stick with that model, then I think that the feature should be renamed to local_login_sender_maps. Wietse
Re: address verify probe cache not refreshing on new user/alias add'n ?
PGNet Dev: > i've set up two postfix instances on 2 separate machines > > frontend > backend > > 'backend' gets user data via postfixadmin/sqlite3 DB > > i've setup address verification between the instances > > on mail receipt @ 'frontend', a verify probe is sent to 'backend'. > if 'exists', then mail is sent frontend->backend; otherwise, rejected. > > it works as intended. > > except -- updates to user DBs at backend aren't being made available promptly. > > if I add a mail alias at backend, via postfix admin, and immediately try to > send to 'frontend' @ that address, it fails the verify probe. > > restarting/reloading the 'backend' postfix doesn't fix the probe fail. postconf | grep address_verify_negative Wietse
Re: Mail server recently became an open relay
Rich Wales: > > Why do you believe that your server is an open relay, as in, it > > will forward messages FROM spammers TO remote destinations. > > Wietse > > Because it *is* accepting messages from outsiders (spammers) and is > using my server to relay those messages to remote destinations. It was > (and still is) my understanding that such messages should be rejected by > Postfix during the SMTP dialogue, with an error to the client saying > relay access is denied -- though I assume I inadvertently either failed > to enable this check or have somehow broken it. Show evidence (logging) and turn of verbose logging. Wietse
Re: possible bottlenecks
On 10/17/20 1:23 AM, Viktor Dukhovni wrote: >> On Oct 17, 2020, at 3:09 AM, Demi M. Obenour wrote: >> >>> The practical limit to the deferred queue size is therefore ~2 days of >>> throughput, and depends heavily on the per-delivery latency. If >>> delivery failures are slow (tarpitting or otherwise slow destinations) >>> the impact is greater. >> >> Can the latency problems be worked around by increasing concurrency? > > Yes, so unsurprisingly, Postfix amortises latency via carefully managed > concurrency. > >> My understanding is that Postfix might have problems at very high >> concurrency due to using one process per connection, whereas some >> other servers are event-driven and can handle thousands of connections >> without using too much memory. > > Postfix reuses processes for multiple deliveries, so process creation > is effectively amortised. SMTP delivery being a rather expensive operation > (DNS lookups, connection setup, TLS handshakes, ...) the fractional (becase > shared across multiple deliveries) cost of process creation is dwarfed by > the actual SMTP transaction costs. > > On modern hardware (anything built in the last ~2 decades), you can run > thousands of concurrent SMTP delivery agents, without any difficulty, > their executables are loaded only once, and per connection memory utilisation > is modest. You run out of remote sites' willingness to receive your email > long before you run out of local capacity to send it. > > The event driven design mostly just makes those other servers more complex, > and more prone to security bugs. Postfix 3.4 and later grudgingly do some > event-driven work because TLS connection reuse with OpenSSL is not possible > out-of-process. So the tlsproxy(8) process context switches between multiple > TLS connections, but the rest of the SMTP delivery agent is one connection > per process and performs just fine. The architecture is however more robust > and secure. Good point. I have wondered if something like s2n would be a better choice, although I would probably use the OpenBSD Postfix packages built against LibreSSL. > Postfix is not an HTTP server handling tens to hundreds of thousands of > requests > per second, and does not benefit from the optimisations needed for those kinds > of workloads. Premature optimisations that sacrifice robustness and security > for little gain are not part of the design. I had not considered that, but you are correct. Email really is a much lower volume service than HTTP. If Postfix needed to handle hundreds of thousands of requests per second and concurrent connections, the process-per-connection model would obviously not work. But it does not need to handle that much load, so the simpler approach is better. Since Postfix is written in C, that simpler approach is to use one process per connection. If one is Google or Microsoft and need to process hundreds of millions of messages per day, then Postfix might not work. But if one needs to handle that much mail, then one can probably afford to write a bespoke MTA. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Forward mail and obey SPF and DKIM
Thank you all. This is how I fixed it (after Bill Cole's email): I needed to substitute envelope (MAIL FROM:) to match my address, but the message (along with it's headers) shouldn't be touched. sender_canonical_classes = envelope_sender # Only change envelope, not body sender_canonical_maps = regexp:/etc/postfix/sender_canonical_map # In this file I change envelope address to my domain. Google is now perfectly happy with both SPF and DKIM. Shouldn't we add this recipe to the official postfix documentation? On Mon, Sep 14, 2020 at 4:31 PM IL Ka wrote: > Hello. > I have postfix running on linux box. > > I setup OpenDKIM with both smtpd and non_smtp milters. > I also set my address in DNS as permitted IP for SPF. > > So far, so good. > > But I want all my mail to be forwarded to gmail. > > Some user sends me email from user@some_sender_domain. > > If I use .forward or alias, then postfix doesn't change "From" header, > so gmail believes email was sent from @some_sender_domain. > This domain doesn't have my box IP as permitted in DNS, so SPF failed. > > I can change header using headers_check. But then DKIM signature > would be broken because some_sender_domain signed email and I changed it. > > It seems that I need to: > * Change headers > * Sign email with my DKIM > * Forward it to gmail > > But milters are not applied on forwarded emails because they aren't > locally generated (or I failed to configure it correctly?) > > I can fix it using custom script that reads my local email > and sends it to gmail. > > But how can I do that with postfix? > > Ilya. >
Re: Accessing the sending user from a canonical(5) table
On 10/17/20 11:34 AM, Wietse Venema wrote: > Demi M. Obenour: >> Should I submit another patch? In addition to adding >> local_sender_login_maps, I have fixed what appeared to be a bug in >> the current postdrop and sendmail commands: root and $mail_owner were >> not automatically allowed to submit mail. Since this is inconsistent >> with similar checks elsewhere, I believe it is unintentional. > > No. I am working on a quality implementation, and that takes more > time than 'code that works'. More patches are not needed. Indeed it does. If I may ask, is there any way I could have made my patch better? I would like to know so that I can write better code in the future. > BTW I realized that I swapped the semantics of smtpd_sender_login_maps > (a mapping from sender address to the login names that are allowed > to use that sender address) when we were discussing the postdrop > feature (a mapping from login name to the sender addresses that the > login name is allowed to use). > > If we stick with that model, then I think that the feature should be > renamed to local_login_sender_maps. I agree, although I wonder if it is better to be consistent and change the semantics to match those of smtpd_sender_login_maps. local_login_sender_maps was easier to implement and seemed more intuitive, but it is less consistent than local_sender_login_maps, which can in some cases be set as local_sender_login_maps = $smtpd_sender_login_maps in main.cf. > Wietse Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: rbl check debug
Just FYI, GMail marked this mail as spam. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: possible bottlenecks
On Sat, Oct 17, 2020 at 02:05:57PM -0400, Demi M. Obenour wrote: > > Postfix 3.4 and later grudgingly do some event-driven work because > > TLS connection reuse with OpenSSL is not possible out-of-process. > > So the tlsproxy(8) process context switches between multiple TLS > > connections, but the rest of the SMTP delivery agent is one > > connection per process and performs just fine. The architecture is > > however more robust and secure. > > Good point. I have wondered if something like s2n would be a better > choice, although I would probably use the OpenBSD Postfix packages > built against LibreSSL. Postfix does not support LibreSSL, and LibreSSL does not make it possible to move SSL connections between processes, it is just a stale fork of OpenSSL. There's no advantage in using LibreSSL and Postfix depends on features of the real OpenSSL. > If one is Google or Microsoft and need to process hundreds of millions > of messages per day, then Postfix might not work. But if one needs > to handle that much mail, then one can probably afford to write a > bespoke MTA. IIRC Hotmail originally ran on Postfix, sendming and receiving email scales horizontally, just field more hardware as needed. But that was some time ago, and by now I am sure that they did replace it with something built inhouse. The thing that really needs custom scaling is the IMAP and webmail frontends, they surely have interesting storage management designs to support O(1 billion) users with O(1Gb) of email each. -- Viktor.
Re: possible bottlenecks
At 17 October, 2020 Demi M. Obenour wrote: > > Postfix is not an HTTP server handling tens to hundreds of thousands of > > requests > > per second, and does not benefit from the optimisations needed for those > > kinds > > of workloads. Premature optimisations that sacrifice robustness and > > security > > for little gain are not part of the design. > > If one is Google or Microsoft and need to process hundreds of millions > of messages per day, then Postfix might not work. But if one needs > to handle that much mail, then one can probably afford to write a > bespoke MTA. A decade ago I helped create and run a mailbox hoster with a few million active accounts. We were nothing compared to gmail/hotmail, but we ran our border MTAs using postfix (with custom smtp content filters and custom LMTP services). My memory is rusty, but given the amount of spam we consumed, we definitely were doing 10s-100s of millions of messages per day (on the inbound side). Postfix did great -- our choke point was storage IOops being saturated by spam that no one would ultimately read, which is annoying but the truth of life. I no longer work in email, but I do work at a fairly large $MEGACORP and I was discussing something the other day with a coworker: When you're sitting on the internet with a service that needs to suport downtime, heavy load, etc., then having a service that fully supports RFCs is really important because you can't be taking postmaster@ emails from rando operators because you're doing something dumb. But once you're dealing with internal services, it's all custom code, because you can just message the engineer responsible for whichever subservice is acting up and sort it out asap. As such things tend to be much more narrow focused in implementation and written for narrowly scoped perf metrics in mind and are less robust (feature wise) than software like postfix.
Re: Accessing the sending user from a canonical(5) table
Demi M. Obenour: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > On 10/17/20 11:34 AM, Wietse Venema wrote: > > Demi M. Obenour: > >> Should I submit another patch? In addition to adding > >> local_sender_login_maps, I have fixed what appeared to be a bug in > >> the current postdrop and sendmail commands: root and $mail_owner were > >> not automatically allowed to submit mail. Since this is inconsistent > >> with similar checks elsewhere, I believe it is unintentional. > > > > No. I am working on a quality implementation, and that takes more > > time than 'code that works'. More patches are not needed. > > Indeed it does. If I may ask, is there any way I could have made my > patch better? I would like to know so that I can write better code > in the future. Mudge (member of the former L0pht group) said that he trusted my code becauuse it was dumb (he may have used a different word such as 'brain-dead', it is a while ago). Wietse
Re: Accessing the sending user from a canonical(5) table
Demi M. Obenour: > > BTW I realized that I swapped the semantics of smtpd_sender_login_maps > > (a mapping from sender address to the login names that are allowed > > to use that sender address) when we were discussing the postdrop > > feature (a mapping from login name to the sender addresses that the > > login name is allowed to use). > > > > If we stick with that model, then I think that the feature should be > > renamed to local_login_sender_maps. > > I agree, although I wonder if it is better to be consistent and > change the semantics to match those of smtpd_sender_login_maps. > local_login_sender_maps was easier to implement and seemed more > intuitive, but it is less consistent than local_sender_login_maps, > which can in some cases be set as > > local_sender_login_maps = $smtpd_sender_login_maps This is not obviously right. In fact, I could argue for the opposite: local_login_sender_maps = $smtpd_login_sender_maps smtpd_sender_login_maps pre-dates the Postfix submission services (submission + smtps) by three years. It solved a problem for an SMTP server that receives authenticated and unauthenticated messages on the same port. In that setting, the sender address had to be the search key for policy lookup. In contrast, postdrop always knows a user ID; there is no legitimate way to invoke postdrop anonymously. With the Postfix submission services, SMTP submission has become more similar to postdrop submission: Postfix always knows a user identity, thus the user identity can become the search key for policy lookup. For the port 25 MTA-to-MTA service one can then reject all mail from a remote site that claims to be from a local user. Wietse
Re: Accessing the sending user from a canonical(5) table
Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze: > For the port > 25 MTA-to-MTA service one can then reject all mail from a remote > site that claims to be from a local user. That's not a good idea. Assume domain.com is configured that way and some user on a completely different domain (us...@site.net) forwards their mail to us...@domain.com. Then what happens if some otheru...@domain.com sends mail to us...@site.net ? One large email provider in Poland was once configured that way (or maybe still is?). That provider was domain.com from this example, and I was at that time administering a mail server at a university that was site.net from this example. Many people forwarded their university email to private email acccounts, some of them being at domain.com. This caused a lot of trouble for us. -- 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: Accessing the sending user from a canonical(5) table
Jaroslaw Rafa: > Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze: > > For the port > > 25 MTA-to-MTA service one can then reject all mail from a remote > > site that claims to be from a local user. > > That's not a good idea. Assume domain.com is configured that way and some > user on a completely different domain (us...@site.net) forwards their mail > to us...@domain.com. Then what happens if some otheru...@domain.com sends > mail to us...@site.net ? [historical scenario omitted] Exactly the scanario that SPF and the like are supposed to prevent. Wietse
Re: Accessing the sending user from a canonical(5) table
On 10/17/20 6:42 PM, Wietse Venema wrote: > Jaroslaw Rafa: >> Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze: >>> For the port >>> 25 MTA-to-MTA service one can then reject all mail from a remote >>> site that claims to be from a local user. >> >> That's not a good idea. Assume domain.com is configured that way and some >> user on a completely different domain (us...@site.net) forwards their mail >> to us...@domain.com. Then what happens if some otheru...@domain.com sends >> mail to us...@site.net ? > > [historical scenario omitted] > > Exactly the scanario that SPF and the like are supposed to prevent. > > Wietse To elaborate, my understanding is that site.net should use MAIL FROM:, but leave the body unchanged. domain.com will then accept the message, as it is from an IP in site.net's SPF record, and DKIM ignores the envelope. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
pass vs unix in master.cf
Hello. What is the difference between these two types? Thank you. Ilya.
Re: Accessing the sending user from a canonical(5) table
On 10/17/20 6:25 PM, Wietse Venema wrote: > Demi M. Obenour: >>> BTW I realized that I swapped the semantics of smtpd_sender_login_maps >>> (a mapping from sender address to the login names that are allowed >>> to use that sender address) when we were discussing the postdrop >>> feature (a mapping from login name to the sender addresses that the >>> login name is allowed to use). >>> >>> If we stick with that model, then I think that the feature should be >>> renamed to local_login_sender_maps. >> >> I agree, although I wonder if it is better to be consistent and >> change the semantics to match those of smtpd_sender_login_maps. >> local_login_sender_maps was easier to implement and seemed more >> intuitive, but it is less consistent than local_sender_login_maps, >> which can in some cases be set as >> >> local_sender_login_maps = $smtpd_sender_login_maps > > This is not obviously right. In fact, I could argue for the opposite: > > local_login_sender_maps = $smtpd_login_sender_maps > > smtpd_sender_login_maps pre-dates the Postfix submission services > (submission + smtps) by three years. It solved a problem for an > SMTP server that receives authenticated and unauthenticated messages > on the same port. In that setting, the sender address had to be the > search key for policy lookup. > > In contrast, postdrop always knows a user ID; there is no legitimate > way to invoke postdrop anonymously. With the Postfix submission > services, SMTP submission has become more similar to postdrop > submission: Postfix always knows a user identity, thus the user > identity can become the search key for policy lookup. For the port > 25 MTA-to-MTA service one can then reject all mail from a remote > site that claims to be from a local user. > > Wietse I agree. local_login_sender_maps is far, *far* more intuitive. In my test instance (which uses my own patch, pending the incorporation of this into a release), I use the equivalent of the following: main.cf: local_login_sender_maps = pcre:/etc/postfix/senders /etc/postfix/senders: /^([A-Za-z_][A-Za-z0-9_.-]*)$/ $1, $1@localhost Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: pass vs unix in master.cf
On 17 Oct 2020, at 20:19, IL Ka wrote: > Hello. > > What is the difference between these two types? > Thank you. > > Ilya. You can get this from 'man 5 master': unix The service listens on a UNIX-domain stream socket and is accessible for local clients only. [...] pass The service listens on a UNIX-domain stream socket, and is accessible to local clients only. It receivesone open connection (file descriptor passing) per connection request. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Mail server recently became an open relay
> /Show evidence (logging) and turn of verbose logging. Wietse/
OK, here is the message header for one of the spam e-mails (which did
not get deleted during my mass cleanup efforts because a copy was saved
in my amavisd-new quarantine database):
X-Envelope-From:
X-Envelope-To:
X-Envelope-To-Blocked:
X-Quarantine-ID:
X-Spam-Flag: YES
X-Spam-Score: 5.488
X-Spam-Level: *
X-Spam-Status: Yes, score=5.488 tag=x tag2=4.5 kill=4.5
tests=[ALL_TRUSTED=-1,
BAYES_00=-0.8, BAYES_00_RAZOR=0.8, FSL_BULK_SIG=0.001,
HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_HTML_ONLY=1,
RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=3, SUBJ_ALL_CAPS=0.5]
autolearn=disabled
Received: from memoryalpha.richw.org ([127.0.0.1])
by localhost (memoryalpha.richw.org [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id D0t9j6VORyNH for ;
Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
Received: from [154.91.34.144] (localhost [127.0.0.1])
by memoryalpha.richw.org (Postfix) with ESMTP id 4CC2vp5WmFz87Jy
for ; Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
From: ScotiaInfoAlerts Communications
Content-Type: text/html
To: andrea_ma...@yahoo.ca
Content-Transfer-Encoding: 7bit
X-Read: MailingV.4371434NJ
Subject: CONFIRMATION REQUIRED - CUSTOMER ID: SS437143
Message-Id: <4cc2vp5wmfz8...@memoryalpha.richw.org>
Date: Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
Note that the chronologically last "Received:" line says the message was
received from 154.91.34.144 -- an IP address with no hostname, in a
range assigned (according to WHOIS) to Hong Kong.
I'm not sure what the parenthesized reference to "(localhost
[127.0.0.1])" in this "Received:" line means. Does this mean that the
client host falsely identified itself with "HELO localhost"?
Now, here are the lines in my mail log corresponding to this message:
Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from
[127.0.0.1]:52138 to [127.0.0.1]:25
Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: WHITELISTED
[127.0.0.1]:52138
Oct 15 14:48:06 memoryalpha postfix/smtpd[6414]: connect from
localhost[127.0.0.1]
Oct 15 14:48:06 memoryalpha postfix/smtpd[6414]: 4CC2vp5WmFz87Jy:
client=localhost[127.0.0.1]
Oct 15 14:48:06 memoryalpha postfix/cleanup[7158]: 4CC2vp5WmFz87Jy:
message-id=<4cc2vp5wmfz8...@memoryalpha.richw.org>
Oct 15 14:48:06 memoryalpha postfix/qmgr[26090]: 4CC2vp5WmFz87Jy:
from=, size=9292,
nrcpt=1 (queue active)
Oct 15 14:48:08 memoryalpha amavis[8375]: (08375-11) Blocked SPAM
{DiscardedOpenRelay,Quarantined}, [127.0.0.1]:52138
->
, quarantine: D0t9j6VORyNH, Queue-ID:
4CC2vp5WmFz87Jy, Message-ID:
<4cc2vp5wmfz8...@memoryalpha.richw.org>, mail_id: D0t9j6VORyNH,
Hits: 5.488, size: 9276, 1290 ms
Oct 15 14:48:08 memoryalpha postfix/smtp[8703]: 4CC2vp5WmFz87Jy:
to=, relay=127.0.0.1[127.0.0.1]:10024,
delay=1.5, delays=0.19/0/0/1.3, dsn=2.7.0, status=sent (250 2.7.0
Ok, discarded, id=08375-11 - spam)
(plus some more amavis-specific log lines which I assume people here
don't care about).
Note here that the "client=" line (first line in the above) gives the
sending host as "localhost[127.0.0.1]". I know that Postfix connects to
amavisd-new via [127.0.0.1]:10024, so I can understand references to
this IP address in and after the "amavis[8375]" log line. But why does
the very first line (smtpd[6414], before any amavis processing) have
localhost as the client?
If my server is getting confused and thinks the message in question
originally came from localhost, I can easily understand why the open
relay checks are being skipped, since my main.cf file includes
127.0.0.0/8 amongst the "mynetworks" values.
So, am I doing something wrong that is allowing spammers to say "HELO
localhost" and get away with it? Or is something else causing my
Postfix to think the e-mail came inbound from localhost even though it
didn't?
Other, valid e-mail coming into and delivered via this server retain the
sending host's identity, btw, and are not rewritten to claim they came
from localhost.
Rich Wales
ri...@richw.org
Re: Mail server recently became an open relay
Sorry, when I said "chronologically last 'Received:' line" in my earlier e-mail, I meant to say "chronologically first (physically last)". Mea culpa. Rich Wales ri...@richw.org
Re: Mail server recently became an open relay
On Sat, Oct 17, 2020 at 08:41:25PM -0700, Rich Wales wrote: > Received: from memoryalpha.richw.org ([127.0.0.1]) > by localhost (memoryalpha.richw.org [127.0.0.1]) (amavisd-new, port > 10024) > with ESMTP id D0t9j6VORyNH for ; > Thu, 15 Oct 2020 14:48:06 -0700 (PDT) > Received: from [154.91.34.144] (localhost [127.0.0.1]) > by memoryalpha.richw.org (Postfix) with ESMTP id 4CC2vp5WmFz87Jy > for ; Thu, 15 Oct 2020 14:48:06 -0700 (PDT) > From: ScotiaInfoAlerts Communications > > Message-Id: <4cc2vp5wmfz8...@memoryalpha.richw.org> > > Note that the chronologically last "Received:" line says the message was > received from 154.91.34.144 -- an IP address with no hostname, in a > range assigned (according to WHOIS) to Hong Kong. No, it says no such thing. It says the EHLO name was [154.91.34.144], the client IP was however 127.0.0.1. It seems you have some sort of proxy or NAT in place that masks the real external IP address, making all connections appear to originate from 127.0.0.1. That would sure explain your spam innundation problem. > I'm not sure what the parenthesized reference to "(localhost > [127.0.0.1])" in this "Received:" line means. Does this mean that the > client host falsely identified itself with "HELO localhost"? No, the other way around. > Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from > [127.0.0.1]:52138 to [127.0.0.1]:25 Same NAT or proxy issue. -- Viktor.
Re: Mail server recently became an open relay
> No, it says no such thing. It says the EHLO name was [154.91.34.144], > the client IP was however 127.0.0.1. It seems you have some sort of > proxy or NAT in place that masks the real external IP address, making > all connections appear to originate from 127.0.0.1. That would sure > explain your spam innundation problem. Thanks. I was actually thinking something of the sort myself -- my server is indeed behind a separate firewall appliance. However, other e-mail (such as your recent reply to my inquiry) is NOT exhibiting this same NAT/proxy addressing problem. The relevant "Received:" line in my copy of your reply says the following (with line wrapping to make it legible in an ASCII environment): Received: from english-breakfast.cloud9.net (english-breakfast.cloud9.net [168.100.1.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by memoryalpha.richw.org (Postfix) with ESMTPS id 4CDQt72CNxz7t88 for ; Sat, 17 Oct 2020 20:51:27 -0700 (PDT) Your e-mail (along with lots and lots of valid e-mail) appears to be entering my server via exactly the same NAT/proxy path as the spam did. I'll continue searching for any possible security hole on my firewall appliance, though. Rich Wales ri...@richw.org
Re: Mail server recently became an open relay
On Sat, Oct 17, 2020 at 09:14:50PM -0700, Rich Wales wrote: > Thanks. I was actually thinking something of the sort myself -- my > server is indeed behind a separate firewall appliance. > > However, other e-mail (such as your recent reply to my inquiry) is NOT > exhibiting this same NAT/proxy addressing problem. The relevant > "Received:" line in my copy of your reply says the following (with line > wrapping to make it legible in an ASCII environment): Well, that shows that a proxy is the more likely scenario, some process listening on a non-loopback IP that passes SMTP connections through to 127.0.0.1, or a NAT rule in your iptables... > I'll continue searching for any possible security hole on my firewall > appliance, though. The firewall appliance (if a separate device) cannot make connections appear to originate from 127.0.0.1, only something running on your machine itself can do that. So not much point looking there. -- Viktor.
