Le 18/08/2011 14:53, Carlos Mennens a écrit : > Today I received a ticket for altering the way my Postfix server > handles mail and I don't understand it. The ticket / request is pasted > below: > > ********************************************** > According to RFC 4409 client mail submission to an email server is > supposed to use port 587. > Server to server SMTP relays are to use port 25. > When I am not at the office, I can't email via my work (Postfix) > account via my iphone or my residential internet because my ISP(s) > filter port 25 to only allow traffic to and from their mail servers. > They do however allow 587 anywhere per RFC 4409. > Additionally I can't email to the IDE with my gmail account, this is > becoming a real pain in the ass when I need to send emails with > attachments. > Just to send this email I am having to relay off my own server in California. > Can we please get the proper ports opened on the mail server? > > http://www.ietf.org/rfc/rfc4409.txt > ********************************************** > > Now my question is I just want to be sure I'm correct in assuming that > all mail servers send on port 25, correct? This user just is > requesting me to allow relay access from his phone carriers network or > home ISP which I'm not going to do since this is the reason I manage > webmail for users. Does the above request seem legit or strange? I > don't know enough about Postfix / mail & port 587 to know if this is a > legit request. > > Thanks for any clarification!
user request is legitimate. in the past, port 25 was used for all smtp traffic, be that "inbound" mail (MX service) or outbound mail. to fight zombie spam, ISPs are encouraged to block traffic to and from port 25 (the "from" part is less obvious: it has to do with "asymmetric" routing). so "real" users would either use thei ISP relay (not always acceptable) or use a different port, which is what the submission port (587) is for. note that you need to enforce authentication on this port. and if login/password is used, then you must establish a good policy (password strength if possible, password change, ...). you can also use certificates (even "software" certs, since zombie attackers are mostly after passwords).
