Re: 421 4.4.2 service timed out

2016-11-10 Thread Keith Williams 


That is exactly what it says, a service time out when you are sending 
email. You are probably on a very active server, a very bad/slow or busy 
connection.


How busy is your server? Do you have some network stats?


On 10/11/2016 21:54, Rob A wrote:

We are having issues sending emails with attachments over ~2 MB to some
recipients.  In the situations were we have an error, the remote server
responds with  "421 4.4.2 service timed out. (in reply to end of DATA
command)".

We are not having these issues with all recipients, but there are many
recipients to which we cannot send emails with attachments over ~2 MB.  We
can send emails with larger attachments to some recipients (gmail.com and
yahoo.com addresses in particular) with no issues.

Any help is appreciated.

- Rob

# Output of postconf -n

bounce_queue_lifetime = 2h
config_directory = /etc/postfix
debug_peer_list =
local_recipient_maps =
local_transport = error:local mail delivery is disabled
maximal_backoff_time = 20m
maximal_queue_lifetime = 2h
message_size_limit = 104857600
minimal_backoff_time = 10m
mydestination =
mydomain = myhome.com
myhostname = mail.$myorigin
mynetworks = 127.0.0.0/8 10.10.10.0/24 10.10.100.0/24
myorigin = $mydomain
queue_run_delay = 10m
relay_domains = $mydomain myhome.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname, check_helo_access
pcre:/etc/postfix/helo_access, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,
reject_non_fqdn_recipient, permit_mynetworks, check_client_access
hash:/etc/postfix/recipient_whitelist, check_recipient_access
hash:/etc/postfix/recipient_blacklist, reject_unauth_destination,
reject_rbl_client b.barracudacentral.org, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client
zombie.dnsbl.sorbs.net, reject_rbl_client nomail.rhsbl.sorbs.net,
reject_rbl_client bl.blocklist.de, permit
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/sender_blacklist, reject_non_fqdn_sender,
reject_unknown_sender_domain, permit
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual

# Here is the output from tcpdump
No. Time   SourceDestination
Protocol Length Info
  1 2016-11-08 17:32:22.658734 10.10.10.123  DDD.222.3.44
TCP  70 47372 > smtp [SYN] Seq=0 Win=29200 Len=0 MSS=1460
SACK_PERM=1 TSval=2863432 TSecr=0

Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: RealtekU_bd:b1:11 (52:54:00:bd:b1:11), Dst:
LexCompu_0b:09:35 (4c:02:89:0b:09:35)
Internet Protocol Version 4, Src: 10.10.10.123 (10.10.10.123), Dst:
DDD.222.3.44 (DDD.222.3.44)
Transmission Control Protocol, Src Port: 47372 (47372), Dst Port: smtp (25),
Seq: 0, Len: 0

No. Time   SourceDestination
Protocol Length Info
  2 2016-11-08 17:32:22.697919 DDD.222.3.44  10.10.10.123
TCP  70 smtp > 47372 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
SACK_PERM=1 TSval=989115275 TSecr=2863432

Frame 2: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: Dell_53:eb:0c (00:13:72:53:eb:0c), Dst: RealtekU_bd:b1:11
(52:54:00:bd:b1:11)
Internet Protocol Version 4, Src: DDD.222.3.44 (DDD.222.3.44), Dst:
10.10.10.123 (10.10.10.123)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 47372 (47372),
Seq: 0, Ack: 1, Len: 0

No. Time   SourceDestination
Protocol Length Info
  3 2016-11-08 17:32:22.698002 10.10.10.123  DDD.222.3.44
TCP  66 47372 > smtp [ACK] Seq=1 Ack=1 Win=29200 Len=0 TSval=2863442
TSecr=989115275

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: RealtekU_bd:b1:11 (52:54:00:bd:b1:11), Dst:
LexCompu_0b:09:35 (4c:02:89:0b:09:35)
Internet Protocol Version 4, Src: 10.10.10.123 (10.10.10.123), Dst:
DDD.222.3.44 (DDD.222.3.44)
Transmission Control Protocol, Src Port: 47372 (47372), Dst Port: smtp (25),
Seq: 1, Ack: 1, Len: 0

No. Time   SourceDestination
Protocol Length Info
  4 2016-11-08 17:32:22.750683 DDD.222.3.44  10.10.10.123
SMTP 167S: 220 AAA.mailsrvr.com ESMTP - VA Code Section 18.2-152.3:1
forbids sending spam through this system

Frame 4: 167 bytes on wire (1336 bits), 167 bytes captured (1336 bits)
Ethernet II, Src: Dell_53:eb:0c (00:13:72:53:eb:0c), Dst: RealtekU_bd:b1:11
(52:54:00:bd:b1:11)
Internet Protocol Version 4, Src: DDD.222.3.44 (DDD.222.3.44), Dst:
10.10.10.123 (10.10.10.123)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 47372 (47372),
Seq: 1, Ack: 1, Len: 101
Simple Mail Transfer Protocol

No. Time   SourceDestination
Protocol Length Info
  5 2016-11-08 17:32:22.750735

Re: Is my server mail account being attacted?

2016-10-20 Thread Keith Williams 

No wait... What?

This is no attack. Attack is when you try to break or enforce.. This is 
a probe, and from the probe we can deduce from the reported disconnect 
that 1. helo was tried, 2. no auth was attempted and 3, quit was used.


So a test for helo and quit? and no auth.

Someone is testing your IP and mail capibility.. perhaps>>



On 20/10/2016 22:20, Bill Cole wrote:

On 18 Oct 2016, at 20:45, Sebastian Nielsen wrote:

Its clear from the log, the attacker isn't even attemping to 
authenticate (0 attempts). The attacker hasn't propably not even 
realized he is connecting to a mail server.



No. There's a jumble there, but at least one is a lame "attack" of a 
sort. The only *Postfix* messages were:


Oct 19 07:55:27 mail postfix/smtpd[9929]: connect from 
unknown[216.15.186.126]
Oct 19 07:55:28 mail postfix/smtpd[9929]: disconnect from 
unknown[216.15.186.126] helo=1 auth=0/1 quit=1 commands=2/3


*THAT* client tried to authenticate and failed. It's a CBL-listed IP 
on a chronically abuse-friendly network.


The rest were all messages from Dovecot components, about failed SSL 
connections from a mix of IPs. Impossible to know what the reasons for 
those were without tracking down the person running the computer.

Re: User interactive verification

2016-08-16 Thread Keith Williams 

Hi Sean,

Thank you for your advise, your folder solution is brilliant and simple. 
Sometimes I tend to over think the problem.


That is going to work perfectly for my users.

Regards,


On 2016/08/16 10:24 PM, Sean Greenslade wrote:

I have a suggestion based on my own way of implementing an email system,
which may or may not work for you. Create a mail folder called
"blacklist," and have a mail delivery script that checks incoming mail
against the senders of mail in the directory. Then you can reject /
redirect / spam / whatever the messages, and the mail users can add or
remove entries from their personal blacklists by moving mails into or
out of that folder.

User interactive verification

2016-08-16 Thread Keith Williams 

Hi all,

I was wondering if someone might be able to point me in the right 
direction as my searches proved fruitless.


I am looking for a email verification system for postfix, but with a 
twist. Not referring to 
http://www.postfix.org/ADDRESS_VERIFICATION_README.html


The system that I am looking for should be able to include per user 
interaction. What I have in mind how it should work is the following:


- Email enters the system and checks if the sender's email address is 
already whitelisted for the recipient of the email.
- If not, a pre-email is sent to the recipient requesting if the sender 
is of the email is valid. Perhaps the pre-email would have 2 links 
(apache comes into play), or just replying to the MTA with approve or block.
- The sender is then either permanently whitelist/blacklisted for the 
recipient/user on the system.


Per user is required as some users might want emails from a 
i...@shopping.com and others not.


Normal anti-spam measures should still apply, just this extra automation 
so users can handle their own white/blacklisting from within their mail 
client without having to log into additional panels etc.


Any advice (or interest!) on such a system would be appreciated.

Best regards,

Keith Williams