On 26 Oct 2016, at 11:45, /dev/rob0 wrote:
On Wed, Oct 26, 2016 at 02:13:37PM +0200, Julian Kippels wrote:
Oct 15 23:16:21 balder postfix/smtp[12174]: 5FDBC8002F90: host
ppmx1.its.rochester.edu[128.151.57.241] refused to talk to me: 554
ppmx1.its.rochester.edu ESMTP Blocked - see
https://support.proofpoint.com/dnsbl-lookup.cgi?ip=134.99.128.242
You're blocked in their firewall.
Not necessarily. MTAs can do this, both in fact and according to the
current relevant RFC.
This is not a legitimate place for
SMTP rejection, so Postfix doesn't see it as one.
RFC5321:
The SMTP protocol allows a server to formally reject a mail session
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220.
That is not a new specification in RFC5321; identical language was in
RFC2821.
The practical reason to treat 554 at connect as a likely transient error
is that it historically largely has been the result of temporary
breakage rather than intentional configuration. Despite its blessing in
the formal spec, it really isn't a rational behavior. It makes far more
sense to implement a truly intentional and permanent block based
absolutely on the client IP by simply not accepting the connection,
either in the lower layers of the network or by the MTA simply rejecting
the connection attempt. In this case the decision was supposedly based
on a DNSBL that present itself as "dynamic" so this is likely some sort
of config error.
