Postfix timeout after data MTU size question

[Joseph Thibeault]

We use postfix as a mail queue / sending service in one of our
applications. This application generates emails with PDF attachments. Some
of the emails with PDFs get sent fine, but others seem to cause a "timeout
after DATA" error.

Through reading online, I've seen answers such as adjusting the MTU size on
the network interface, etc. None of these solutions have worked. Has anyone
had this happen, do you have any suggestions to fix it?

Thank you.

Re: TLD blocking revisited

[@lbutlr]

On Tue Sep 20 2016 18:40:17 Sebastian Nielsen    said:
> 
> 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

The problem is that DISCARD accepts the mail. That is the server has to accept 
the data connection and receive the data.

And there is no evidence that spammers are doing anything other than blasting 
out, not paying the slightest attention to what is accepted or rejected.

I see IPs that have been hitting postscreen for weeks and weeks with no change 
in the number of connection attempts.

Also, this gives me a very specific string to check for to see who is being 
rejected.

DISCARD vs REJECT (Was: Re: TLD blocking revisited)

[Bill Cole]

On 20 Sep 2016, at 20:40, Sebastian Nielsen wrote:

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.


Note that in this specific case of junk TLDs, the tool (low-cost 
domains) is critical to that class of spammer's business model.



DISCARD accepts the mail but throws it into /dev/null


The debate over this theory of spammer behavior has been going on for at 
least 20 years and in that time I've never seen convincing evidence that 
it is more true than an alternative theory that targets which seem to 
accept spam for delivery (i.e. DISCARD) attract more spam because 
spammers think they are verified as good targets and peddle their lists 
of verified deliverable addresses to each other, expanding the number of 
senders aiming at the apparently unfiltered address. If that behavior 
dominates, you still get morphing spam making it past content filtering 
because you have more variety of senders.


I have very noisy data collected over 15 years in a smallish spam-heavy 
domain which suggests that spam sinks (which simply accept and discard 
all their mail) and spam traps (which feed all their mail into local 
anti-spam measures) both attract more spam over time at a slightly 
higher growth rate than aggregate mail or spam for normal addresses in 
the same domain, but it's not a dramatic or uniform difference. 
Conversely, dead addresses that reject everything tend to get less mail 
aimed at them over the long term. In this case, normal users whose mail 
is either explicitly rejected in SMTP or delivered to their Inbox make 
up the noisiest subset; attempted spam generally gets worse over time 
but not always, and delivered spam (false negatives) can go either way.


The main conclusion I've reached from that long-term close examination 
of a small sample and shorter, shallower analyses of much larger systems 
is that there are no grand universal rules of spam that can apply 
everywhere to everyone. No one who gets a significant amount of spam 
aimed at them gets exactly the same spam as anyone else. Some spammers 
work hard at filter evasion, others do not. Some of those who work very 
hard at it do so with chronically and ridiculously poor results, at 
least against *some* common filtering strategies. The balance of 
competing spammer behavioral theories that form the basis of the REJECT 
vs. DISCARD argument is close enough overall to be a matter for 
subjective judgment on any particular mail system, but I think that as a 
practical matter there are 2 concrete issues that argue for REJECT in 
all cases where it isn't a recipe for significant backscatter:


1. No anti-spam measures are perfect. If you accept and discard mail 
that your anti-spam measures deem to be spam, then when they get that 
judgment wrong and toss out mail you actually would rather have 
delivered, it may never be noticed as a technical failure by anyone. 
Internet email is consciously designed to notify senders explicitly of 
delivery failures, and using DISCARD violates that design.


2. The most effective spam exclusion tactics in a mail system that uses 
a "defense in depth" model are ones which can detect spam at or before 
the RCPT command(s), allowing the MTA to reject spam it never actually 
receives. This spares the MTA from using pointless bandwidth and (more 
significantly in most cases) from maintaining a session for typically an 
order of magnitude longer than necessary, just to pipe message data to 
/dev/null.

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[robert . wolfe]

On 2016-09-21 10:54, Alex Hall wrote:


I may have phrased it wrong. Here's the line from the log:

Sep 21 10:44:07 server postfix/smtp[3623]: A710260D2F:
to=, relay=smtp.mandrillapp.com
[3][52.6.223.177]:25, delay=0.25, delays=0.01/0.01/0.19/0.04,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DCD3326817)


Then you have nothing to worry about.

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Noel Jones]

That log entry says the message was successfully delivered to your
relayhost, and is normal.  From that point, it's the relayhost's
responsibility to either deliver the message or return it if it's
not deliverable.

The next line in the log probably says queueid A710260D2F removed,
which is also normal.


  -- Noel Jones


On 9/21/2016 10:54 AM, Alex Hall wrote:
> I may have phrased it wrong. Here's the line from the log:
> 
> Sep 21 10:44:07 server postfix/smtp[3623]: A710260D2F:
> to=>,
> relay=smtp.mandrillapp.com
> [52.6.223.177]:25, delay=0.25,
> delays=0.01/0.01/0.19/0.04, dsn=2.0.0, status=sent (250 2.0.0 Ok:
> queued as DCD3326817)
> 
> 
> On Wed, Sep 21, 2016 at 11:50 AM, Wietse Venema
> > wrote:
> 
> Alex Hall:
> > Thanks everyone. I removed domain.com  and
> local.domain.com  from
> > mydestinations, and set relay_domains = domain.com
> . Suddenly, everything
> > started to work! My logs say that outgoing emails have a
> status of 252.0.0,
> > in case that's anything I should worry about?
> 
> Yes, you should worry about your eye sight. The '252.0.0' is bogus.
> 
> Wietse
> 
> 
> 
> 
> -- 
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com 

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Alex Hall]

I may have phrased it wrong. Here's the line from the log:

Sep 21 10:44:07 server postfix/smtp[3623]: A710260D2F: to=<
otheru...@domain.com>, relay=smtp.mandrillapp.com[52.6.223.177]:25,
delay=0.25, delays=0.01/0.01/0.19/0.04, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as DCD3326817)


On Wed, Sep 21, 2016 at 11:50 AM, Wietse Venema 
wrote:

> Alex Hall:
> > Thanks everyone. I removed domain.com and local.domain.com from
> > mydestinations, and set relay_domains = domain.com. Suddenly, everything
> > started to work! My logs say that outgoing emails have a status of
> 252.0.0,
> > in case that's anything I should worry about?
>
> Yes, you should worry about your eye sight. The '252.0.0' is bogus.
>
> Wietse
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Wietse Venema]

Alex Hall:
> Thanks everyone. I removed domain.com and local.domain.com from
> mydestinations, and set relay_domains = domain.com. Suddenly, everything
> started to work! My logs say that outgoing emails have a status of 252.0.0,
> in case that's anything I should worry about?

Yes, you should worry about your eye sight. The '252.0.0' is bogus.

Wietse

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Alex Hall]

Thanks everyone. I removed domain.com and local.domain.com from
mydestinations, and set relay_domains = domain.com. Suddenly, everything
started to work! My logs say that outgoing emails have a status of 252.0.0,
in case that's anything I should worry about?

On Wed, Sep 21, 2016 at 10:02 AM, Noel Jones  wrote:

> On 9/21/2016 8:55 AM, Fazzina, Angelo wrote:
> > I think this is the issue ?
> >
> >
> >
> > mynetworks = 127.0.0.0/8, [::1]/128
> >
> >
>
> No, unrelated.
>
>
>   -- Noel Jones
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: cosmetics: authentication success not logged

[Wietse Venema]

A. Schulze:
> 
> A. Schulze:
> 
> > Am 18.09.2016 um 14:39 schrieb Wietse Venema:
> >> As in the patch below.
> 
> Hello Wietse,
> 
> there are multiple places where such loglines are written:

Those are irrelevant, because they either happen after smtpd has
already logged the sasl user name, or because there will never be
a sasl user name (in the case of postscreen or local submission).

Wietse

Re: TLD blocking revisited

[Wietse Venema]

James Reynolds:
> I use check_sender_access and DISCARD to throw away about 1500-4000
> messages a day from .top domains (which is about the volume of my
> legit email).  I looked into it and most of them are registered
> to namecheap.com, which appears to sell the names for for $.98
> each.  I did a little research into Namecheap's reputation and I
> found one thread calling them friendly to spammers.

If you have reasons to believe that a certain DNS server is hosting
spammer domains, you can use check_client_ns_access, check_helo_ns_access
and check_sender_ns_access to block present future spam.

It helped me to block a persistent spammer who was constantly changing
domain names, but who kept using the same DNS server.

Wietse

Re: cosmetics: authentication success not logged

[A. Schulze]

A. Schulze:


Am 18.09.2016 um 14:39 schrieb Wietse Venema:

As in the patch below.


Hello Wietse,

there are multiple places where such loglines are written:

$ find . -name '*.c' | xargs grep helo=
./src/cleanup/cleanup_message.c: 
vstring_sprintf_append(state->temp1, " helo=<%s>", attr);
./src/cleanup/cleanup_milter.c: vstring_sprintf_append(state->temp1, "  
helo=<%s>", attr);
./src/cleanup/cleanup_milter.c: vstring_sprintf_append(state->temp1, "  
helo=<%s>", attr);
./src/postscreen/postscreen_smtpd.c: "from=<%s>, to=<%s>,  
proto=%s, helo=<%s>",
./src/smtpd/smtpd.c:vstring_sprintf_append(buf, " helo=<%s>",  
state->helo_name);
./src/smtpd/smtpd_check.c:  vstring_sprintf_append(buf, "  
helo=<%s>", state->helo_name);


You suggested to patch src/smtpd/smtpd.c but I've to patch  
src/smtpd/smtpd_check.c

Could you say something about the conditions where each code path is active?

Andreas

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Noel Jones]

On 9/21/2016 8:55 AM, Fazzina, Angelo wrote:
> I think this is the issue ?
> 
>  
> 
> mynetworks = 127.0.0.0/8, [::1]/128
> 
>  

No, unrelated.


  -- Noel Jones

RE: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Fazzina, Angelo]

Forget what I said, you said this
I'm setting up Request Tracker for internal use, which requires a Linux system 
to run
So Mynetworks is likely fine.

I agree with Noel Jones.
-ALF


-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG-Linux/ M
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Noel Jones
Sent: Wednesday, September 21, 2016 9:57 AM
To: postfix-users@postfix.org
Subject: Re: Moved Postfix to new server; Gmail now silently dropping messages 
sent from it

On 9/21/2016 8:42 AM, Alex Hall wrote:
> I just sent a test message to my work address. The log is below.
> Following that, I'll post postconf -n. Obviously, I've changed the
> server name to just 'server' and our domain to 'domain.com
> '. After I send this, I'm going to enable
> debug-level logging and see what that tells me, if anything. I'm
> hoping something will jump out from the below outputs, though.
> 
> Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0
> from=
> Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29:
> message-id=<20160921132306.0869e60...@server.domain.com
> >
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29:
> from=>, size=320, nrcpt=1
> (queue active)
> Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29:
> to=>, relay=local,
> delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to
> command: procmail -a "$EXTENSION")
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed

Your mail was delivered locally because you list your domain in
mydestination.

To deliver your domain remotely, list it in relay_domains.  List
valid recipients in relay_recipients_maps.

http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/STANDARD_CONFIGURATION_README.html




  -- Noel Jones



> 
> 
> postconf -n:
> 
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> inet_interfaces = all
> mailbox_command = procmail -a "$EXTENSION"
> mailbox_size_limit = 0
> mydestination = domain.com , localhost.domain.com
> , localhost
> mydomain = domain.com 
> myhostname = server.domain.com 
> mynetworks = 127.0.0.0/8 , [::1]/128
> myorigin = /etc/mailname
> readme_directory = no
> recipient_delimiter = +
> relayhost = [smtp.mandrillapp.com ]
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
> smtp_sasl_security_options = noanonymous
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_relay_restrictions = permit_mynetworks
> permit_sasl_authenticated defer_unauth_destination
> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_use_tls = yes
> 
> 
> On Tue, Sep 20, 2016 at 5:42 PM, rightkicktech.gmail.com
>   > wrote:
> 
> Hi Alex,
> 
> You should be able to see more details in /var/log/mail.log.
> postfix is pretty verbose in the logs. Try sending a test mail
> and observe the log file. Revert with the relevant entry to see
> what happened.
> 
> 
> On September 21, 2016 12:30:27 AM EEST, Alex Hall
> > wrote:
> 
> Hello list,
> A very quick intro first. I work for a company that uses all
> virtual servers, a change we recently adopted. I'm setting
> up Request Tracker for internal use, which requires a Linux
> system to run. Thus, I'm learning about Linux and all of
> RT's required packages at the same time. I'm comfortable on
> the command line, and know the basics of Bash, but I'm no
> expert. I'm running Debian 8, Postfix, Fetchmail, and
> Request Tracker, all with the latest updates as of today.
> Our company uses Google Apps to manage mail for our domain,
> so my address (ah...@domain.com )
> is essentially a Gmail address. That'll be important in a
> minute.
> 
> Now, to why I'm sending this email. To make sure RT was
> going to work, I set it up on a Digital Ocean server, also
> Debian, and was able to get things working pretty easily.
> The bit that matters here is that I was able to get Postfix
> working; it would send out emails as Request 

Re: TLD blocking revisited

[James Reynolds]

I use check_sender_access and DISCARD to throw away about 1500-4000 messages a 
day from .top domains (which is about the volume of my legit email).  I looked 
into it and most of them are registered to namecheap.com, which appears to sell 
the names for for $.98 each.  I did a little research into Namecheap's 
reputation and I found one thread calling them friendly to spammers.

https://www.webhostingtalk.com/showthread.php?t=700628=4

Not sure what to think about it.

James Reynolds

On Sep 21, 2016, at 2:31 AM, Allen Coates  wrote:

> 
> On 21/09/16 02:35, Jim Reid wrote:
> 
>> Spammers generally don’t pay that level of attention to SMTP responses, far 
>> less fine-tune their address lists and tools. These morons just find a 
>> victim host or botnet to blast out crap to a bazillion email addresses, not 
>> caring if any of them work or not or if their spam makes it as far as 
>> getting presented to a human victim. 
> 
> I will second that.  One of my "callers"  -  blocked by iptables   - 
> has been sending me a couple of packets an hour since 11 August.  
> 
> Allen C
> 

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Noel Jones]

On 9/21/2016 8:42 AM, Alex Hall wrote:
> I just sent a test message to my work address. The log is below.
> Following that, I'll post postconf -n. Obviously, I've changed the
> server name to just 'server' and our domain to 'domain.com
> '. After I send this, I'm going to enable
> debug-level logging and see what that tells me, if anything. I'm
> hoping something will jump out from the below outputs, though.
> 
> Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0
> from=
> Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29:
> message-id=<20160921132306.0869e60...@server.domain.com
> >
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29:
> from=>, size=320, nrcpt=1
> (queue active)
> Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29:
> to=>, relay=local,
> delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to
> command: procmail -a "$EXTENSION")
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed

Your mail was delivered locally because you list your domain in
mydestination.

To deliver your domain remotely, list it in relay_domains.  List
valid recipients in relay_recipients_maps.

http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/STANDARD_CONFIGURATION_README.html




  -- Noel Jones



> 
> 
> postconf -n:
> 
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> inet_interfaces = all
> mailbox_command = procmail -a "$EXTENSION"
> mailbox_size_limit = 0
> mydestination = domain.com , localhost.domain.com
> , localhost
> mydomain = domain.com 
> myhostname = server.domain.com 
> mynetworks = 127.0.0.0/8 , [::1]/128
> myorigin = /etc/mailname
> readme_directory = no
> recipient_delimiter = +
> relayhost = [smtp.mandrillapp.com ]
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
> smtp_sasl_security_options = noanonymous
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_relay_restrictions = permit_mynetworks
> permit_sasl_authenticated defer_unauth_destination
> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_use_tls = yes
> 
> 
> On Tue, Sep 20, 2016 at 5:42 PM, rightkicktech.gmail.com
>   > wrote:
> 
> Hi Alex,
> 
> You should be able to see more details in /var/log/mail.log.
> postfix is pretty verbose in the logs. Try sending a test mail
> and observe the log file. Revert with the relevant entry to see
> what happened.
> 
> 
> On September 21, 2016 12:30:27 AM EEST, Alex Hall
> > wrote:
> 
> Hello list,
> A very quick intro first. I work for a company that uses all
> virtual servers, a change we recently adopted. I'm setting
> up Request Tracker for internal use, which requires a Linux
> system to run. Thus, I'm learning about Linux and all of
> RT's required packages at the same time. I'm comfortable on
> the command line, and know the basics of Bash, but I'm no
> expert. I'm running Debian 8, Postfix, Fetchmail, and
> Request Tracker, all with the latest updates as of today.
> Our company uses Google Apps to manage mail for our domain,
> so my address (ah...@domain.com )
> is essentially a Gmail address. That'll be important in a
> minute.
> 
> Now, to why I'm sending this email. To make sure RT was
> going to work, I set it up on a Digital Ocean server, also
> Debian, and was able to get things working pretty easily.
> The bit that matters here is that I was able to get Postfix
> working; it would send out emails as Request Tracker told it
> to, and everyone received them with no problem. Since that
> worked, my boss told me to move it to a virtual server on
> our network, which I did. That was two weeks ago, and since
> that move, not one email has been received by anyone in the
> company from that server.
> 
> From all I can tell, Postfix is doing it right: it sends the
> emails, and so long as the recipient is *not* @domain.com
> , the message is delivered. If it *is*
> @domain.com , the message silently
> 

RE: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Fazzina, Angelo]

I think this is the issue ?

mynetworks = 127.0.0.0/8, [::1]/128





-Angelo Fazzina
Operating Systems Programmer / Analyst
University of Connecticut,  UITS, SSG-Linux/ M
860-486-9075

From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Alex Hall
Sent: Wednesday, September 21, 2016 9:53 AM
To: postfix-users@postfix.org
Subject: Re: Moved Postfix to new server; Gmail now silently dropping messages 
sent from it

On Wed, Sep 21, 2016 at 9:45 AM, Ralf Hildebrandt 
> wrote:
The mail was delivered locally.
Wasn't your issue with gmail?
Yes, but I hoped that some obscure message in the log might indicate the 
problem Gmail had, or else that my configuration would reveal some obvious 
thing I have to do for Gmail to trust my messages. I'm only guessing that trust 
is the problem, as I don't know how to get Gmail to show me the actual error(s) 
it's encountering.

On Wed, Sep 21, 2016 at 9:45 AM, Ralf Hildebrandt 
> wrote:
* Alex Hall >:
> I just sent a test message to my work address. The log is below. Following
> that, I'll post postconf -n. Obviously, I've changed the server name to
> just 'server' and our domain to 'domain.com'. After I send 
> this, I'm going
> to enable debug-level logging and see what that tells me, if anything. I'm
> hoping something will jump out from the below outputs, though.
>
> Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0 from=
> Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29: 
> message-id=<20160921132306.0869e60...@server.domain.com>
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: 
> from=>, size=320, nrcpt=1 (queue 
> active)
> Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29: 
> to=>, relay=local, delay=0.02, 
> delays=0.01/0/0/0, dsn=2.0.0, status=sent
> (delivered to command: procmail -a "$EXTENSION")
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed

The mail was delivered locally.
Wasn't your issue with gmail?

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein



--
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Alex Hall]

On Wed, Sep 21, 2016 at 9:45 AM, Ralf Hildebrandt  wrote:
The mail was delivered locally.
Wasn't your issue with gmail?

Yes, but I hoped that some obscure message in the log might indicate the
problem Gmail had, or else that my configuration would reveal some obvious
thing I have to do for Gmail to trust my messages. I'm only guessing that
trust is the problem, as I don't know how to get Gmail to show me the
actual error(s) it's encountering.

On Wed, Sep 21, 2016 at 9:45 AM, Ralf Hildebrandt  wrote:

> * Alex Hall :
> > I just sent a test message to my work address. The log is below.
> Following
> > that, I'll post postconf -n. Obviously, I've changed the server name to
> > just 'server' and our domain to 'domain.com'. After I send this, I'm
> going
> > to enable debug-level logging and see what that tells me, if anything.
> I'm
> > hoping something will jump out from the below outputs, though.
> >
> > Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0
> from=
> > Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29: message-id=<
> 20160921132306.0869e60...@server.domain.com>
> > Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: from=<
> r...@domain.com>, size=320, nrcpt=1 (queue active)
> > Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29: to=<
> ah...@domain.com>, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0,
> status=sent
> > (delivered to command: procmail -a "$EXTENSION")
> > Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed
>
> The mail was delivered locally.
> Wasn't your issue with gmail?
>
> --
> [*] sys4 AG
>
> http://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG, 80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Ralf Hildebrandt]

* Alex Hall :
> I just sent a test message to my work address. The log is below. Following
> that, I'll post postconf -n. Obviously, I've changed the server name to
> just 'server' and our domain to 'domain.com'. After I send this, I'm going
> to enable debug-level logging and see what that tells me, if anything. I'm
> hoping something will jump out from the below outputs, though.
> 
> Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0 from=
> Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29: 
> message-id=<20160921132306.0869e60...@server.domain.com>
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: 
> from=, size=320, nrcpt=1 (queue active)
> Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29: 
> to=, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, 
> status=sent
> (delivered to command: procmail -a "$EXTENSION")
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed

The mail was delivered locally.
Wasn't your issue with gmail?

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Alex Hall]

I just sent a test message to my work address. The log is below. Following
that, I'll post postconf -n. Obviously, I've changed the server name to
just 'server' and our domain to 'domain.com'. After I send this, I'm going
to enable debug-level logging and see what that tells me, if anything. I'm
hoping something will jump out from the below outputs, though.

Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0 from=
Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29: message-id=<
20160921132306.0869e60...@server.domain.com>
Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: from=,
size=320, nrcpt=1 (queue active)
Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29: to=,
relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent
(delivered to command: procmail -a "$EXTENSION")
Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed


postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = domain.com, localhost.domain.com, localhost
mydomain = domain.com
myhostname = server.domain.com
mynetworks = 127.0.0.0/8, [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = [smtp.mandrillapp.com]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes


On Tue, Sep 20, 2016 at 5:42 PM, rightkicktech.gmail.com <
rightkickt...@gmail.com> wrote:

> Hi Alex,
>
> You should be able to see more details in /var/log/mail.log. postfix is
> pretty verbose in the logs. Try sending a test mail and observe the log
> file. Revert with the relevant entry to see what happened.
>
>
> On September 21, 2016 12:30:27 AM EEST, Alex Hall 
> wrote:
>>
>> Hello list,
>> A very quick intro first. I work for a company that uses all virtual
>> servers, a change we recently adopted. I'm setting up Request Tracker for
>> internal use, which requires a Linux system to run. Thus, I'm learning
>> about Linux and all of RT's required packages at the same time. I'm
>> comfortable on the command line, and know the basics of Bash, but I'm no
>> expert. I'm running Debian 8, Postfix, Fetchmail, and Request Tracker, all
>> with the latest updates as of today. Our company uses Google Apps to manage
>> mail for our domain, so my address (ah...@domain.com) is essentially a
>> Gmail address. That'll be important in a minute.
>>
>> Now, to why I'm sending this email. To make sure RT was going to work, I
>> set it up on a Digital Ocean server, also Debian, and was able to get
>> things working pretty easily. The bit that matters here is that I was able
>> to get Postfix working; it would send out emails as Request Tracker told it
>> to, and everyone received them with no problem. Since that worked, my boss
>> told me to move it to a virtual server on our network, which I did. That
>> was two weeks ago, and since that move, not one email has been received by
>> anyone in the company from that server.
>>
>> From all I can tell, Postfix is doing it right: it sends the emails, and
>> so long as the recipient is *not* @domain.com, the message is delivered.
>> If it *is* @domain.com, the message silently disappears. This holds true
>> whether I use Gmail or Mandrill as the relay for Postfix--non-company
>> addresses work, company ones do not. The Mandrill logs seem to indicate
>> that my messages lack a sender, which suggests that my envelope may be
>> malformed, thus causing Gmail to flip out when it sees them.
>>
>> What I hope people on this list can offer are suggestions regarding what
>> I can do to fix this. Why my Digital Ocean server worked perfectly, and my
>> internal, virtual server doesn't is the biggest mystery. I don't know how
>> to tell Postfix to let me see the full details of outgoing messages so I
>> can examine them. Oh, speaking of outgoing messages, RT isn't the only one
>> whose messages run into this problem. The following command encounters it,
>> too, despite my extra headers:
>>
>> echo "test" | mail -s "test" -a "from: Postfix "
>> -a "reply-to: Postfix " ah...@domain.com
>>
>> My server seems to have the right name, too. The result of 'hostname' is
>> 'myServerName', and 'hostname -f' is 'myservern...@domain.com'. I have
>> no aliases set up, but 

Re: TLD blocking revisited

[Allen Coates]

On 21/09/16 02:35, Jim Reid wrote:

> Spammers generally don’t pay that level of attention to SMTP responses, far 
> less fine-tune their address lists and tools. These morons just find a victim 
> host or botnet to blast out crap to a bazillion email addresses, not caring 
> if any of them work or not or if their spam makes it as far as getting 
> presented to a human victim. 

I will second that.  One of my "callers"  -  blocked by iptables   - 
has been sending me a couple of packets an hour since 11 August.  

Allen C